This refactors the KEYMAPS(...) macro and factors out
a header and footer portion that are now define as individual
macros START_KEYMAPS and END_KEYMAPS. The original
KEYMAPS(...) macro now relies on the newly defined macros.
The newly introduced macros enable keymap definitions that
allow for macro definitions between the start and end part
which is not possible inside the KEYMAPS(...) macro invocation.
Signed-off-by: Florian Fleissner <florian.fleissner@inpartik.de>
There were a few minor problems in the way Consumer `Key` objects were
constructed (using `CONSUMER_KEY()`). First, no masking of the high
bits was being done, so it was possible to create a "Consumer" key
with the `RESERVED` bit set (e.g. `Key_Transparent`), or the
`SWITCH_TO_KEYMAP` bit (in fact, any `Key` value with both the
`SYNTHETIC` and `IS_CONSUMER` bits set was possible).
This change fixes these potential problems by setting the six bits
taht could conflict to zero. When we need to have special behavior
based on those bits, this can change.
There were a few minor problems in the way Consumer `Key` objects were
constructed (using `CONSUMER_KEY()`). First, no masking of the high
bits was being done, so it was possible to create a "Consumer" key
with the `RESERVED` bit set (e.g. `Key_Transparent`), or the
`SWITCH_TO_KEYMAP` bit (in fact, any `Key` value with both the
`SYNTHETIC` and `IS_CONSUMER` bits set was possible).
Second, the high six bits of the raw `Key` value should always be
`010010` (`SYNTHETIC | IS_CONSUMER`), as Consumer keys don't have any
flags. The macro should really only take one argument: a 16-bit
integer keycode value. The `HID_TYPE_*` constants really shouldn't be
used at all in defining the keys in key_defs_consumer.h, because
setting those bits could potentially cause a key to be misidentified
by some plugin.
This change fixes these potential problems by ignoring the `flags`
parameter, masking the high six bits of the `code` supplied, and
setting those high six bits to the correct value.
For some of our single-parameter constructors, we _want_ to have implicit
conversions, because that makes the code more readable. Mark these up for
cpplint to ignore.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Florian Fleissner
Jesse Vincent
Michael Richters
Gergely Nagy
Gergely Nagy