Hi Hans, On Wed, Aug 21, 2019 at 10:59:31PM +0200, Hans de Goede wrote: > Various keyboards have macro keys, which are intended to have user > programmable actions / key-sequences bound to them. In some cases these > macro keys are actually programmable in hardware, but more often they > basically are just extra keys and the playback of the key-sequence is done > by software running on the host. > > One example of keyboards with macro-keys are various "internet" / "office" > keyboards have a set of so-called "Smart Keys", typically a set of 4 keys > labeled "[A]" - "[D]". > > Another example are gaming keyboards, such as the Logitech G15 Gaming > keyboard, which has 18 "G"aming keys labeled "G1" to G18", 3 keys to select > macro presets labeled "M1" - "M3" and a key to start recording a macro > called "MR" note that even though there us a record key everything is > handled in sw on the host. > > Besides macro keys the G15 (and other gaming keyboards) also has a buildin > LCD panel where the contents are controlled by the host. There are 5 keys > directly below the LCD intended for controlling a menu shown on the LCD. > > The Microsoft SideWinder X6 keyboard is another gaming keyboard example, > this keyboard has 30 "S"idewinder keys and a key to cycle through > macro-presets. > > After discussion between various involved userspace people we've come to > the conclusion that since these are all really just extra keys we should > simply treat them as such and give them their own event-codes, see: > https://github.com/libratbag/libratbag/issues/172 > > This commit adds the following new KEY_ defines for this: > > KEY_LCD_MENU1 - KEY_LCD_MENU5, KEY_MACRO_RECORD, KEY_MACRO_PRESET_CYCLE, > KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_MACRO1 - KEY_MACRO30. > > The defines leave room for adding some more LCD-menu, preset or macro keys, > the maximum values above are based on the maximum values to support all > currently known internet, office and gaming keyboards. I must say that I am not too hot on having these in the keys space, with the exception of KEY_MACRO_RECORD_* as we were trying to allow userspace consumers to know what keys are supposed to mean, instead of just blanked "programmable" keys. Still, we have the BTN_TRIGGER_HAPPY. I guess as long as we do not try to use the new range for keys that have a defined meaning but lack their own button code it is OK. > > BugLink: https://github.com/libratbag/libratbag/issues/172 > Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> > --- > include/uapi/linux/input-event-codes.h | 54 ++++++++++++++++++++++++++ > 1 file changed, 54 insertions(+) > > diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h > index 85387c76c24f..80df3a6d6bcb 100644 > --- a/include/uapi/linux/input-event-codes.h > +++ b/include/uapi/linux/input-event-codes.h > @@ -650,6 +650,60 @@ > #define KEY_DATA 0x277 > #define KEY_ONSCREEN_KEYBOARD 0x278 > > +/* > + * Some keyboards have a buildin LCD panel where the contents are controlled > + * by the host. Often these have a number of keys directly below the LCD > + * intended for controlling a menu shown on the LCD. These keys often don't > + * have any labelling so we just name them KEY_LCD_MENU# > + */ > +#define KEY_LCD_MENU1 0x280 KEY_KBD_LCD_MENUn to show that it is supposed to control the LCD *on* the keyboard? I also wonder if we could move it down by 16 to start with 0x290? This will give us more buffer for new keycodes. Thanks. -- Dmitry
