| Message ID | 20190821205937.4929-2-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Input + HID: Add support for extra keys and LEDs on Logitech "G" series keyboards | expand |
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@redhat.com> > --- > 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.
Hi Dmitry, On 22-08-19 20:06, Dmitry Torokhov wrote: > 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. Right, these new codes are for key which are intended to be user programmable, they have no icon on them / no defined meaning. They come with markings like G1-G18 (for the Logitech _G_aming series), but they have no meaning and under Windows they do not function at all without host side software turning them intro macro keys. Other keyboards have markings like e.g. S1 - S30 for the Microsoft _S_idewinder series, again the intended use for these keys is use as macro keys configured through host side software... Do you want me to add a big fat comment to the next version spelling this out extra explicitly ? >> BugLink: https://github.com/libratbag/libratbag/issues/172 >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> 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? KEY_KBD_LCD_MENUn works for me, I will change to this for v3 of the patchset. > I also wonder if we could move it down by 16 to start with 0x290? This > will give us more buffer for new keycodes. Sure, will do for v3. Regards, Hans
On Thu, Aug 22, 2019 at 10:14:31PM +0200, Hans de Goede wrote: > Hi Dmitry, > > On 22-08-19 20:06, Dmitry Torokhov wrote: > > 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. > > Right, these new codes are for key which are intended to be user programmable, > they have no icon on them / no defined meaning. They come with markings > like G1-G18 (for the Logitech _G_aming series), but they have no meaning and > under Windows they do not function at all without host side software turning > them intro macro keys. Other keyboards have markings like e.g. S1 - S30 for > the Microsoft _S_idewinder series, again the intended use for these keys is > use as macro keys configured through host side software... > > Do you want me to add a big fat comment to the next version spelling this > out extra explicitly ? Yes please. Thanks.
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 +#define KEY_LCD_MENU2 0x281 +#define KEY_LCD_MENU3 0x282 +#define KEY_LCD_MENU4 0x283 +#define KEY_LCD_MENU5 0x284 + +/* Macro preset selection and recording keys, typically found on gaming kbds */ +#define KEY_MACRO_RECORD_START 0x288 +#define KEY_MACRO_RECORD_STOP 0x289 +#define KEY_MACRO_PRESET_CYCLE 0x28a +#define KEY_MACRO_PRESET1 0x28b +#define KEY_MACRO_PRESET2 0x28c +#define KEY_MACRO_PRESET3 0x28d + +/* Gaming "macro" (macros handled in software/userspace) keys on gaming kbds */ +#define KEY_MACRO1 0x290 +#define KEY_MACRO2 0x291 +#define KEY_MACRO3 0x292 +#define KEY_MACRO4 0x293 +#define KEY_MACRO5 0x294 +#define KEY_MACRO6 0x295 +#define KEY_MACRO7 0x296 +#define KEY_MACRO8 0x297 +#define KEY_MACRO9 0x298 +#define KEY_MACRO10 0x299 +#define KEY_MACRO11 0x29a +#define KEY_MACRO12 0x29b +#define KEY_MACRO13 0x29c +#define KEY_MACRO14 0x29d +#define KEY_MACRO15 0x29e +#define KEY_MACRO16 0x29f +#define KEY_MACRO17 0x2a0 +#define KEY_MACRO18 0x2a1 +#define KEY_MACRO19 0x2a2 +#define KEY_MACRO20 0x2a3 +#define KEY_MACRO21 0x2a4 +#define KEY_MACRO22 0x2a5 +#define KEY_MACRO23 0x2a6 +#define KEY_MACRO24 0x2a7 +#define KEY_MACRO25 0x2a8 +#define KEY_MACRO26 0x2a9 +#define KEY_MACRO27 0x2aa +#define KEY_MACRO28 0x2ab +#define KEY_MACRO29 0x2ac +#define KEY_MACRO30 0x2ad + +/* Note: 0x2ae - 0x2bf are served to extend the MACRO keys if necessary */ + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1
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. BugLink: https://github.com/libratbag/libratbag/issues/172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- include/uapi/linux/input-event-codes.h | 54 ++++++++++++++++++++++++++ 1 file changed, 54 insertions(+)