Add support in libratbag for a subset of gaming keyboards #172
Comments
|
@ohaessler is probably interested in this too and has a Razor Ornata chroma IIRC. As said before, I am also more then happy to help implementing. |
|
I would love to get support for mechanical (gaming) keyboards available as stated above. I would be happy to test with the Razer Ornata Chroma. By the way, there is a Razer project already ongoing https://terrycain.github.io/razer-drivers/ (unfortunately it is not building on my RHEL 7.3) |
Thanks! Amended the first comment. |
|
tbh, the more I think about it, the more I don't like forking it off. For the bits we need, libratbag already has the boilerplate. Adding device type capabilities is trivial, we should be able to find a semantic that works here (especially because we're dealing with only a few devices, not the same variety that e.g. libinput deals with). we should also really look into hooking some of the other projects up as backends. If the code already exists, talking to those may be a quick way to figure out what API we want. Also CC-ing @Hjdskes, he's currently working on the piper redesign |
|
I have studied the older Corsair protocol (the USB protocol, not the HID one used by ckb). I could write a driver for it if USB support was added in libratbag. By the way, the picture of the "K70" is actually a "K70 RGB", they have different protocol and capabilities. All devices I know with this protocol don't have per-key LED settings. There is a global brightness setting and the K40 has a per-profile color setting.
The K40 has animations but I don't understand them very well. I think the breathing animation is managed by the hardware (but maybe it needs to be started by a command), but the cycle color one needs commands to be sent at regular interval. But adding software managed effects feels like going very far from the initial hardware oriented configuration, it would be a huge change. If you were going this way, would you also add software remapping and macros? I personally think it would be simpler to keep ratbagd for hardware configuration and leave the LED control to another daemon (protocol specific or generic). Generic software remapping and macros already exists in other applications. |
Agree. There are at least a couple of issues:
|
Isn't the Corsair a HID keyboard? It seems unlikely that you need raw USB support for it. Also, raw USB support means unbinding the keyboard from the kernel, which is not very compatible with the configuration tool we want to have in libratbag.
Damn. I had a good reason to buy a K70, and now I don't know if the one I should be looking at is the RGB or not. Regarding libratbag development, which Corsair keyboard do you own?
Looking at the K70 RGB product page, I read: http://www.corsair.com/en-gb/landing/k70-rgb So I guess the recent ones have per-key LCD lighting.
OK. I was also asking because there was one thing we do not support in libratbag for the mouse: we do not read the incoming events and notify users when profile/setting changes when a button is pressed on the mouse.
I also think software remapping and macro is going to be a pain. We would need to filter out the given button (remapping it in the kernel to something useless for instance), and then inject the software macros. Doable but not sure we want to go this path. Having a separate daemon is entirely doable too. libratbag could still have all the entry points, and we will just have a separate daemon |
|
found these two, couldn't resist to ask: do we want those in libratbag too??
|
|
I have a G610, and I’ve been looking at https://github.com/MatMoul/g810-led (command-line only). It seems to me like it makes some sense to have support for keyboards in libratbag, if only because at least in the Logitech case the protocol is so similar (to the extent that fwupd gets thoroughly confused). |
Standard keyboard stuff uses HID. But other features use vendor-specific USB control transfer with the device, not with an interface, so it can actually be used without unbinding the kernel driver. My notes on the protocol are available here.
I own a K90. If I am not too confused, for Corsair's mechanical keyboards, you have the first generation with K60 and K90, later improved as K70 and K95, and then the RGB versions. What I know from the later generations comes from ckb. ckb mainly supports the RGB versions with a protocol using HID reports, but it also has some code for the non-RGB version with USB control transfer that are similar to those for the K90. In addition to my K90, I also got some USB captures from users of the K40 (non mechanical, with RGB leds, 6 macro keys). From these two devices, I can tell that they have similar protocols but not exactly compatible ones. I expect the same from the K70/K95: some commands in common, others changed or added. From Corsair website, it looks like the K70 does have per-key lighting:
|
I originally designed the internal APIs and structures of razercfg with the idea in mind for keyboard support to be added, but I never added an actual driver backend for any keyboard. |
|
Thanks. Updated the first post. |
|
fwiw, we can talk to a dbus daemon from within libratbag. Technically it's no problem, at least in the development stages. It gets a bit trickier when we say "this is the final implementation" but to make things work initially, the dbus dependency is not an issue. The biggest issue here may be the need for a event loop, which given libratbag's fairly static approach so far doesn't yet exist. I'm still strongly against software mappings. libratbag was originally intended to only apply to devices that can store configuration in the hardware, for anything else it's in the wrong position. Given a wayland-y future, the compositor is in the right place for arbitrary mappings but we don't need to care about the hardware for those. How fast is the LED update rate for these things? Is there some interactivity involved and/or possible? e.g. pressing one key changes the LEDs (and shifts the key mappings or so). If so, I'm not sure if libratbag in it's current design is interactive enough... |
|
I just received the K70 LUX RGB today. Thanks to ckb-next, I was able to test it under Linux and have a good idea of the capabilities of the hardware (I could have done that by looking at the code, but having actual hardware is better). Few notes:
After a quick talk with @whot this morning, we decided to not invest too much in reverse engineering the protocols, and rely on the other projects to do the hard work. In other words, we will create a ckb-next-driver that just talks to ckb-daemon. In the same way, we will probably re-use the razor-drivers and roccat (libgamingear) daemon/drivers by talking to those projects over dbus. This should help us adding a lot more devices for free and extend the community of developers by relying on those other projects. |
This makes code that just checks for general abilities easier to write, the specific thing we can do (e.g. switch profiles) is expressed as separate bit. This is an ABI break Related to libratbag#172 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes code that just checks for general abilities easier to write, the specific thing we can do (e.g. switch profiles) is expressed as separate bit. This is an ABI break Related to #172 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
Hello there, I have reverse-engineered a Cyborg V7 keyboard, nothing much to see here, as the macro keys configuration are handled in software, and the illumination is set via hardware keys. There is however an interesting sound level indicator that can be easily driven via USB. Adding the core functionality in the daemon could also provide some interesting visual effects. Regarding software mappings, I agree that the daemon is not the place to handle them, however, I think that a protocol to set them via libratbag (or libinput) could be devised, to have all the configuration in a single place). Of course, this requires further discussion, and is not the main topic here. |
|
Hello, Right now, I provide a cli tool for one-shot manipulation and a session service that plays animations in reaction to Xwindow events. What's still lacking is a DBus interface to allow programs to interact with the service in a richer way than updating their window title. I don't know much about libratbag, but I stumbled upon this ticket and wondered whether there'd be some potential in joining effort. I like the idea of a unified API covering more than just one vendor. |
|
@spectras Ideally, we'd have the hardware bits in libratbag and exposed via dbus, then you can write the dbus service interfaces as you wish on top of that. Duplicating the hardware effort is what we're trying to avoid. Problem is, we haven't really had any time yet to start with this :( |
|
@whot Okay, may I weigh in on some of the questions then? First a bit of background: what I have done with keyleds encompasses those problems/tasks
From there, I am wondering what the scope of libratbag would be, if it included keyboard support.
So… “do we need to have a daemon running for the animations?”: Depends. Logitech keyboard includes an animation controller, but it can only do very basic stuff. Namely, it has a set of 5 whole-keyboard animations and that's it. Anything more clever requires a deamon to update keyboard states several times per second. It's worth noting some keyboards have the animation controller but lack the per-key RGB API. “if ratbagd is running, what happens when ratbag-command is called?” I hit this very issue. Two options there: either the cli detects that the daemon is running and does its jobs through the daemon API, or some of its features are disabled/pointless. “Are non-RGB and RGB LEDs handled the same way?” Yes for Logitech keyboards. It depends on the specific device, but for monochromatic keyboards either a single channel or the maximum value of the three channels is used. Same holds for keyboards with limited intensity resolution, for instance those with 4 levels of intensity will map them to [0, 63][64, 127][128, 191][192, 255]. “How fast is the LED update rate for these things?” Tests I did with the G410 show it can handle about 50 updates per second with firmware 101.2.14. It used to be much slower, this firmware version specifically was aimed at improving its reaction time. “Is there some interactivity involved and/or possible? e.g. pressing one key changes the LEDs (and shifts the key mappings or so)” Kinda answered that one in the first question. There is nothing built-in for this. Interactivity involves a daemon listening to the events it wants to react to. Want to react to keypresses? Have to mess with Xinput. Want to react to change in keyboard layout? Have to mess with kbd driver. The fact that the control endpoint is seen as an entirely different device makes it a hassle. As for the architecture: I am concerned that a low-level approach is not well suited to DBus. DBus calls are slow and costly. Any program animating the keyboard needs to update all keys at the very least ten times per second while keeping resource use to a minimum. And have relatively accurate timing while doing so. I would strive for a rich daemon with native plugins, and limiting DBus communication to RGB-key-aware programs sending high-level status updates (that is "player is now team A" as opposed to "set key A to blue, and key B to blue and key C to blue and… wait we're now .05s later, set key A to darkger blue and…"). Let the relevant plugin react to updates as it sees fit. |
|
I don't have a lot of answers here, at least not precise ones. First: libratbag is first and foremost a configuration utility, and a generic one at that. We may need a daemon to support some features but in the interest of keeping things maintainable we've been cutting down on the features we are willing to expose. In other words, ratbagd's DBus api will provide for some RGB led configuration, but if you're looking at a free-for-all RGB interface that supports animations etc, I don't think this will happen, at least not anytime soon. We do however try to make the backends separated enough that at least someone else could use those to access the device protocol. Because ideally we want the device protocol in one repository only and we're happy to make this easier to use (see also liblur in libratbag) RGB vs non-RGB - in libratbag best solved by exposing the bit-depth in some way and abstract the rest away in the driver. As for the update rate - I think for the basic things libratbag will expose (static, breathing, blinking) the update rate doesn't matter too much. regarding interactivity: there's some thought on listening to key events from within ratbagd. Presumably this could mean adding notifications about key events or adding triggers. No idea yet how exactly this would work though.
Indeed, this is the configuration approach libratbag chose. It will be sufficient for basic things but not for everything. The list of very basic things can be extended by adding some IFTTT-like triggers but again - no idea how (and whether this is in the scope).
This paragraph makes two things obvious: one is that we don't actually know what exactly we need to do because we're not really users of those devices. but the other thing is also: there are a lot of things we could do but we're explicitly not doing them. if you've been around during the wobbly windows craze 10 years ago you may remember that it was great for showing off but the practical benefit was nil while introducing maintenance difficulties. So we do err on the side of "yes, this is a common and valid use-case so let's support it" over implementing stuff that may or may never get used. |
|
To be fair, mine was a special offer, I went for a correct mechanical keyboard at discounted price. Only discovered the RGB keys when I opened the box. I totally agree with you: the RGB keys thing is bound to stay a gadget. It's fancy but doesn't serve any actual purpose. Any UI complex enough to warrant using keyboard's lights to convey information will require the user to maintain focus on the screen, making keyboard lights plain useless but for showing off. I understand the focus on productivity features in libratbag. I'll stay around, ping me if/when you start designing RGB support, I'll be happy to give a hand. And probably I'll look into dropping my own logitech protocol implementation, focusing on the session service and delegating device abstraction to libratbag eventually. |
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: libratbag/libratbag#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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# coded and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# coded and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# coded and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
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: libratbag/libratbag#172 This commit adds the following new KEY_ defines for this: KEY_MACRO1 - KEY_MACRO30. KEY_MACRO_RECORD_START/-STOP, KEY_MACRO_PRESET_CYCLE, KEY_MACRO_PRESET1 - KEY_MACRO_PRESET3, KEY_KBD_LCD_MENU1 - KEY_KBD_LCD_MENU5. 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: libratbag/libratbag#172 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- Changes in v3: - Add a big comment explaining why we need the KEY_MACRO# codes and that they MUST NOT be used for keys which have a defined meaning - Start the codes at 0x290 instead of 0x280 to leave some extra space for adding new codes after KEY_ONSCREEN_KEYBOARD (0x278) - s/KEY_LCD_MENU/KEY_KBD_LCD_MENU/
|
#874 adds support for HID++ 2.0 keyboards. The only internal API change I had to do was adjusting an assert to allow devices to not have any resolutions. I then added support for the Logitech G915 (#875) and the G513 (#876). I also have a G815 but not here right now, so I can't test, however I expect it to work out of the box with #875. |
|
@FFY00 I've got a G613 if you need testing with that model. |
|
Sure, you can build #876 and add a |
|
Well, this has been merged and released so closing. |
[CC @whot @jwrdegoede @cvuchener @phomes @tolga9009 @mbuesch @skitt @ogay @xnlcasad -- add more people if you believe they are interested in]
After a long thinking, I am finally starting to believe we should probably envision the fact of supporting keyboards too. I know we shut down the idea multiple times, and that's why I'd like to have an open discussion about it.
I am thinking of gearing myself with a G910 from Logitech and a K70 RGB from Corsair to have at least 2 vendors. @gicmo has access to a Razer Blade (not sure from how long), so this would give us 3 vendors.
To start the discussion, I think we should first do a little state of the art and define what we want to support for keyboards. I personally don't want to open too much the thing, so I would say we should not support more than what we support in mice nowadays:
Devices
The 3 keyboards I am looking at are rather similar (images are not hosted here, so they may drop):
G910 keyboard:
K70 RGB keyboard:
Razer Blade laptop:
(note that each LED can be individually lit up, even if it's not shown here).
Functionalities
Macro keys
Most mechanical keyboards have macro keys available. We currently support macro in libratbag, and for Logitech devices, the protocol is the same. So it shouldn't be much of an issue to add macro keys.
Not all keys can be mapped on all keyboards, so we might export only 5 keys for a full keyboard. It looks like the K70 can remap any key, I haven't checked on the other vendor products.
(RGB) LED individual lighting
Looking at this picture, it seems that we can individually light up each key.
This should be easily doable in libratbag because the LED are exported individually.
Note that the Razer Blade Pro 2017 has a specific lighting around the touchpad:
(RGB) LED grouped effect
We can apply a global effect to the keyboard (color wave, star light, ripple, etc...)
Not sure how to handle this, but this is something to consider.
Profiles
I think those keyboards handle profiles, so should we.
Other features we do not want to support (to be discussed)
An external LCD as a touchpad
Yeah, we probably don't want to go there.
Others?
Existing open source projects
Corsair
https://github.com/mattanger/ckb-next
I really like the design of the UI :)
Roccat
https://sourceforge.net/projects/roccat/
The UI is IMO less polished than ckb-next. Still, it's there and there is existing code for it.
Razer (razercfg)
https://github.com/mbuesch/razer
Does it support keyboards?Edit: from @mbuesch :
Razer (razer-drivers)
https://terrycain.github.io/razer-drivers/
Support different UI, for instance:
https://github.com/lah7/polychromatic
https://github.com/GabMus/razerCommander
https://github.com/z3ntu/RazerGenie
Keyleds
https://github.com/keyleds/keyleds
It supports both compiled plugins and scripted animations (in LUA) and can react to keypresses and desktop events such as current window changing title. It does not need root access.
Logitech (g810-led)
https://github.com/MatMoul/g810-led
CLI only
Others?
Feel free to add more link to other projects
Technical discussion
Should we support keyboards in libratbag or fork the project?
Regarding forking the project, I already been suggested libwasd as for the name :)
Forking would be cleaner. But OTOH, a lot of the boilerplate is already there in libratbag, so maybe forking is not so good.
Instead of forking, should we have a middle ground?
Like having in a low level library the drivers, the protocols, and the objects. And have 2 separate libraries
libratbagandlibcrazykeyboard(or any other name) that are just thin wrappers around the low level one to provide the differences we want in the API (keyvsbuttonfor instance).If we add keyboards in libratbag, what are the impacts?
Differentiating mice from keyboards
From a technical point of view, nothing in libratbag express that a device is a mouse.
We have capabilities, so we could describe a mouse or a keyboard by its capabilities.
The visual is shown through SVG, so we don't need to differentiate a LED on a mouse from one on a keyboard.
However, I have a feeling we want to have a different UI for keyboards than mice, so we might need a type telling keyboard/mouse/touchpad/trackball/etc...
ratbag-commandThe CLI output is going to be interesting (106 macros to redefine, the same amount of LEDs), but given
ratbag-commandshould not be used outside from developers (hmm...) we should be able to find a way.Redefining capabilities
We should probably group capabilities by hundreds, as in
libinput:This will break ABI, but we don't care yet. We can just bump the soname.
Do we need to have a daemon running for the animations?
We have
ratbagd, yes, but do we need to have it running for the animations of the LEDs to be working? If so, then we should probably take this into account to some level (ifratbagdis running, what happens whenratbag-commandis called?)Are non-RGB and RGB LEDs handled the same way?
Not an issue for mice, but I have no ideas for the keyboards.
We should precisely define our targets
Currently libratbag doesn't export what type of devices it supports, and which common features we want to support. This is all describe in the API, but we should probably have some central place of saying: "we can support this and this feature from this keyboard, but the rest needs to be handled in a specific project".
Discussion
feel free to add comments and concerns
The text was updated successfully, but these errors were encountered: