Macro keys not exposed to system
migmolrod opened this issue · comments
I have a Logitech G710+ and using KDE Neon (a mix between long-term stable Ubuntu and latest cutting-edge KDE).
While the macro recording works flawlessly, it seems that the G* keys are not directly exposed to the system itself, thus I can't bind my macro keys to shell commands, windows actions, etc in KDE System Settings -> Shortcuts -> Custom Shortcuts.
The only workaround is to record an unused bizarre combination of keys (Ctrl + Shift + Meta + Alt + whatever) with the built-in macro recorder and then bind that combination as trigger to our actions, right? Is there an option or way to expose extra keys to the system?
I was using https://github.com/boombatower/logitech-g710-linux-driver and keys where directly 'bindable' in KDE System Settings -> Shortcuts -> Custom Shortcuts (even with M* keys as modifiers).
I came here to try this for the convenience of having a service instead of a kernel module (plus I had some troubles with some windows ignoring macro keys). Does that difference in the approach (service vs module) have to do something with those macro keys not working the way I expect?
Thank you for the bug report!
Exposing keys to the system is indeed a kernel driver's job, but it should work with sidewinderd aswell. In its default configuration, sidewinderd "clears" any kind of key event codes from the G- and M-Keys (which usually emit numbers "1" to "6" on G710), so you have a clean starting point.
However, I can't think of a reason, why e.g. binding some kind of placeholder keys like F13 - F24 to the macro keys and use them within KDE System Settings -> Shortcuts -> Custom Shortcuts shouldn't work. The keys get directly injected into /dev/input/uinput (aka the standard way of doing it, to my knowledge), which should be usable and bindable in all sorts of applications, including in the KDE shortcut menu you mentioned.
Note: you can manually edit the macro configuration files instead of live recording, if you want to bind single keys to them. This will also work for keys, which are not physically available on your keyboard (and therefore cannot be live recorded), like KEY_F24 for example.
If this doesn't work - either due to changes to the underlying software / drivers I'm unaware of or simply it never worked to begin with - it shouldn't be a big deal to fix / configure it.
Which KDE version and Linux kernel are you using?
However, I can't think of a reason, why e.g. binding some kind of placeholder keys like F13 - F24 to the macro keys and use them within KDE System Settings -> Shortcuts -> Custom Shortcuts shouldn't work.
OK, I didn't know that was even possible XD. That approach is good enough for me if I'm able to do it.
In terminal, plasmashell --version and uname -r say respectively:
plasmashell 5.15.4
4.15.0-48-generic
So how can I tell the kernel 'hey, consider this G1 key as an F13 key'? With new rules in /etc/udev/rules.d/whatever.rules?
Right now all I've tried was running sudo evtest (without sudo, there were no available devices) and this appears:
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: Power Button
/dev/input/event1: Power Button
/dev/input/event2: Video Bus
/dev/input/event3: Logitech Logitech G710 Keyboard
/dev/input/event4: Logitech Logitech G710 Keyboard
/dev/input/event5: USB OPTICAL MOUSE
/dev/input/event6: HDA Intel PCH Rear Mic
/dev/input/event7: HDA Intel PCH Front Mic
/dev/input/event8: HDA Intel PCH Line
/dev/input/event9: HDA Intel PCH Line Out
/dev/input/event10: HDA Intel HDMI HDMI/DP,pcm=3
/dev/input/event11: HDA Intel HDMI HDMI/DP,pcm=7
/dev/input/event12: HDA Intel HDMI HDMI/DP,pcm=8
/dev/input/event13: HDA Intel HDMI HDMI/DP,pcm=9
/dev/input/event14: HDA Intel HDMI HDMI/DP,pcm=10
/dev/input/event15: Sidewinderd
Select the device event number [0-15]:
I tried 3, 4 and 15 and none of them are recognizing G* and M* keys apparently.
Nevermind, I'm stupid. I was overthinking it even when you made it so clear XD It's a matter of telling sidewinderd 'hey, G1 = F13' and then in KDE shortcuts, F13 should be available.
I'll try it and if it works, consider this closed.
Okay, I've looked into this. E.g. binding KEY_PROG1 to a key and then binding it to a shortcut within the application works for me (tested with gnome-terminal). It looks like not every key I've randomly tested is working though: KEY_F24 didn't work for me, eventhough it's configured in https://github.com/tolga9009/sidewinderd/blob/master/src/core/virtual_input.cpp. KEY_F18 worked though. Theoretically, all keys specified within those lines in the virtual_input.cpp file should work.
The procedure is as the following and requires manual editing:
- Record a single keypress on your desired macro key
- Go to sidewinderd configuration folder (usually
/home/<user>/.local/share/sidewinderd - Go into desired profile_[1-3]
- Open up s[1-6].xml file, whereas the number corresponds to your macro key
- Look up desired keycode number in https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h. I suggest
KEY_PROG[1-4]for the beginning, which are the keycodes 148, 149, 202 and 203. - Replace the number within
<KeyEvent>123</KeyEvent>with your desired keycode - The keyboard should now emit your configured keycode to the system, once the key is pressed.
- (Optional) Remove
<DelayEvent>123</DelayEvent>, if you don't need key hold down
Yes. Your step by step is what I was trying while you were writing it, apparently XD But I'm using F13-F24 (codes 183-194) instead
That covers all G keys for M1 and M2 profiles. For M3 I'll use those 4 you say (KEY_PROG#) and which other 2 do you recommend to avoid 'conflicts' or that are actually designed for this purpose?
Edit: you're right, some of the F keys don't work. While F13-F18 all work great, some of the others seem to be hardcoded to 'Microphone toggle', 'Volume toggle', 'Touchpad toggle' and similar functions. And F24 does not work at all for me either.
Actually, now I understand, those are the default bindings when using boombatower kernel module/driver.
I'll close this as I consider this as 'solved'. All I need to do now is fine tune. Tyvm tolga9009