I’ve been continuing to pull the threads that I find in the code, and I’m starting to wonder why the KeyboardioScanner repository is separate from the Kaleidoscope-Hardware-Model01 repository, rather than being a part of it. @algernon, can you explain it to me?
Because it can be used separately, as in by a different keyboard. Perhaps its name is not the best, as it suggests it is tied to the Keyboardio, while it is not. It implements a particular way to do scanning and other things, but can be re-used by other hardware plugins, too.
(Raise currently uses a fork, but we could easily merge the two and support both keyboards. I’ll get there, eventually.)
1 Like
Thanks for the answer. I guess that makes sense, though it does make it difficult to follow code in Kaleidoscope-Hardware-Model01, because some of its data structures are defined in a different repository.
Does KeyboardioScanner require the same hardware for the key scanners that are used in the Model01? I’m still not sure where the code for those resides.
no. it just requires the same protocol.
It’s not uncommon for code that uses an API to require a library that exports the API. arguably, we should have methods to keep the data structures private.
I started by (re-)examining Kaleidoscope-Hardware-Model01, and noticing that it did not, on its own, provide the whole API offered by Kaleidoscope-Hardware. It wasn’t the KeyboardioScanner API that I was looking at.
I haven’t worked out the details yet, but it seems to me that it would make more sense to use the same mechanism for making a module swappable in both this case and on the HID side, which seems to be going in a very different direction.
That’s a reasonable point, but a different thread 
There may be C++ reasons it’s not plausible, but i’m not sure either way at this point. It’d be nice to have consistent patterns.
1 Like