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@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?
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
