- Remove the concept of "mcus". With only one target platform
(CircuitPython), it no longer makes a bunch of sense and has been kept
around for "what if" reasons, complicating our import chains and eating
up RAM for pointless subclasses. If you're a `board`, you derive from
`KeyboardConfig`. If you're a handwire, the user will derive from
`KeyboardConfig`. The end. As part of this, `kmk.hid` was refactored
heavily to emphasize that CircuitPython is our only supported HID stack,
with stubs for future HID implementations (`USB_HID` becomes
`AbstractHID`, probably only usable for testing purposes,
`CircuitPython_USB_HID` becomes `USBHID`, and `BLEHID` is added with an
immediate `NotImplementedError` on instantiation)
- `KeyboardConfig` can now take a HID type at runtime. The NRF52840
boards will happily run in either configuration once CircuitPython
support is in place, and a completely separate `mcu` subclass for each
mode made no sense. This also potentially allows runtime *swaps* of HID
driver down the line, but no code has been added to this effect. The
default, and only functional value, for this is `HIDModes.USB`
- Most consts have been moved to more logical homes - often, the main
or, often only, component that uses them. `DiodeOrientation` moved to
`kmk.matrix`, and anything HID-related moved to `kmk.hid`
The thumb cluster maps a little goofy and I'd like to clean up the
keymap here - it's ENTIRELY NOT OBVIOUS how this works right now. Using
this keymap as an example, the physical layout of my thumb cluster is
actually:
Far left: Left
Next to the right: Right
Bottom right: Shift
Top right: MO(2)
You can see what this maps to in code, and it's not at all intuitive.
`swap_indicies`, which we already support, is useless here because,
unlike the Planck/Klaranck, these aren't 1:1 key swaps, but an entirely
custom mapping of columns. This will require something like QMK's
solution to fully custom (or at least partially custom) keymaps at a
core level, and isn't something I feel like tackling tonight
necessarily.
This brings this naming into consistency with both fellow consts in the
same file (ex. LeaderMode is singular) as well as the variables in which
the consts are usually used (usually a `Firmware.unicode_mode` attribute
in a keymap).
This took a bit of brain surgery to firmware.py that deserves its own
commit message beyond the default merge commit message - tl;dr though,
it appears to work fine.
This allows leader sequences to "time out" rather than requiring an
Enter keypress to end.
This also rolls back some unnecessary changes from #72 to the matrix
scanner for performance reasons.
In theory we can use this in the future for Tap Dance support (#40)
Resolves#1Resolves#37
Resolves#70, Resolves#67
Still needs some regression testing in general, and a definite
regression is that rotary encoders are no longer (for the immediate time
being) supported.
Moves to a much simpler internal state tracking system, and FAR lighter
matrix scan.
Removes MicroPython support entirely.
This also cleans up some weird potentially-buggy logic paths within the
ModifierKeycode creation and handling. I can now press a free-floating
HYPER in my keymap and see the appropriate codes in `xev` for press and
release events.
Quote taken straight from the docstring of get_pin:
>Cross-platform method to find a pin by string.
>
>The pin definitions are platform-dependent, but this provides
>a way to say "I'm using pin D20" without rolling a D20 and
>having to actually learn MicroPython/CircuitPython and the
>differences in how they handle pinouts.
>
>This also makes the keymap sanity checker actually work for
>CircuitPython boards, since it's not possible in CPY to
>define a module stub for `board` that uses Passthrough
>natively (which is how the MicroPython stub worked originally)
This does a bunch of crazy stuff:
- The ability to set a unicode mode (right now only Linux+ibus or
MacOS-RALT) in the keymap. This will be changeable at runtime soon, to
allow a single keyboard to be able to send table flips and whatever
other crazy stuff on any OS the board is plugged into (something that's
not currently doable on QMK, so yay us?)
- As part of the above, there is now just one user-facing macro for
unicode codepoint submission,
`kmk.common.macros.unicode.unicode_sequence`. Users should never use the
platform-specific macros, partly because they just outright won't work.
There's all sorts of fun stuff in these methods now, thank goodness
MicroPython supports the `yield from` construct.
- Keycode (these should really be renamed Keysym or something) objects
that are intended to not be pressed, or not be released. Right now these
properties are completely ignored if not part of a macro, and it's
probably sane to keep it that way. This was necessary to support MacOS's
"hold RALT while typing the codepoint characters" flow.
- Other refactor-y bits, like moving macro support to `kmk/common`
rather than sitting at the top level of the tree. One day `kmk/common`
may make sense to surface at top level `kmk/`, but that's a discussion
for another day.
