Under Windows, we use an input method that requires a registry edit, mention
that in the README, and describe how to do it.
Fixes#1031.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When there are different input methods available on Linux (Chinese, Japanese,
etc), using the numpad is more reliable than the number row. As both work,
rather than making it configurable, just switch to numpad on Linux.
Fixes#1064.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To account for non-qwerty host-side layouts, we want to be able to easily set
the last part of the sequence used to start Unicode input on Linux. The newly
introduced `Unicode.setLinuxKey(Key_S)` function does just that.
Fixes#1063.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To allow us to use any other HID than KeyboardioHID, the base device _must_ use
something else (practically, the Base HID), otherwise we'll get a compile error
when building on a platform that KeyboardioHID does not support, even if we do
not use KeyboardioHID. We get that error, because the base class references it
anyway.
As such, lets use the base HID as default, and adjust all users of KeyboardioHID
to explicitly set that: Virtual, Dygma Raise, and ATmega32U4Keyboard. Everything
else derives from the last one, so they're covered with just the change to
ATmega32U4Keyboard.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If `HID_BOOT_PROTOCOL` is undefined, define it ourselves (the value is set by
the USB standard, so we can do that). This allows compiling the base class
without KeyboardioHID, letting our HID base driver be completely independent of
it.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This function is completely unused, and should not have been exposed to begin
with. Neither in the base class, nor in specific implementations.
The `getReport()` method ties us to a specific report datatype, both in name,
and in shape. That's not something we want, we'd rather have the base class be
HID-library agnostic, which it can't be with `getReport()` present.
Luckily, the function is completely unused, and as such, is safe to remove
without deprecation.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of doing the stop in the base class, delegate it to the specific
implementation. Do this to avoid depending on the exact shape and layout of the
mouse report within the base class.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We do not need to redefine `new` on STM32, as it is included in the standard
library, and defining it ourselves would lead to linking errors.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This is a guide to writing a Kaleidoscope plugin, more or less written as a
tutorial. It is (obviously) incomplete, but even in its partially-complete
state, it's still probably useful.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Other parts of Kaleidoscope require the NKRO and Boot keyboard classes to have
an `isKeyPressed()` method, which our base classes did not provide - until now.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The `layer_state_` bitfield is no longer necessary now that we have
activation-order layers. Removing it reduces clutter and saves a modicum of
PROGMEM & RAM.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
OneShot keys should apply to all the key events generated by a Macros key, not
just the first one, even if the Macros key is injected by TapDance.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
If multiple events are processed in a single cycle, we want a OneShot key whose
release is triggered by the first one to only affect that key, and not
subsequent ones. For example, if we tap `OSM(LeftShift)`, then `TD(0)`, then
`Key_X`, the OneShot shift should only apply to the output of the TapDance key,
not the `x`.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
This event handler is useful for plugins that need to react to events, but
should wait until after those events are fully processed before doing so. This
is useful for OneShot, which needs to keep keys active until after events that
trigger their release. The `afterEachCycle()` hook is unfortunately
insufficient for this purpose, because the same event could trigger multiple
plugins (e.g. TapDance & OneShot) to resolve events, and the OneShot should
apply only to the first ensuing report.
Signed-off-by: Michael Richters <gedankenexperimenter@gmail.com>
Jesse Vincent
Gergely Nagy
Jesse Vincent
Gergely Nagy
Michael Richters