Add support for G915 (libusb only) #267
Conversation
|
Thanks for the "PR", I'll test that ... It's sure that libusb will be needed for the g915 ... As the "g810-led" package is part of Debian main, I cannot validate the "PR" until I have run some tests. But that would be too cool to have a solution for that damn G915. |
|
@MatMoul I wonder why g810-led doesn't work with G915 when hidapi is used. |
|
@MatMoul I see where the hidapi issue may be coming from. You're using |
|
@MatMoul I've added support for G915 in hidapi mode. Unfortunately I don't have any way to test if this breaks support for other keyboards, but from the information I've gathered from different projects, everything should still work. |
|
The code look fine but I am having some problems. FYI, I tested with HIDAPI and LIBUSB. I started by testing with the USB cable without success ... I have also tested old keyboards and some key is no longer defined in a single call of g810-led. It's a good start but there is still some work to do for this damn G915. |
|
@MatMoul I've mentioned it in the PR that only wireless mode is implemented. It can be done for wired mode too, but without Logitech feature detection it'll add even mode switch cases. Regarding the profile resets, it's the on board node interfering. To get rid of it first switch the keyboard in the software mode. You should have then the full control of the keyboard without resets. I've also noticed that not always all the keys are set on the first run. I don't know why but I thought that this is G915 specific. Have you compared the behaviour with and without my changes on these older keyboards? Also for me this issue goes away when keyboard is in software mode. |
|
This is almost working for me. I just got a new g915tkl and I had to edit c541 to c545 in the udev rule and Keyboard.h and then built with libusb, installed, re-plugged the lightspeed dongle to invoke the udev rule. When I ran And, nothing else seems to work. For instance This current color pattern is none of the 13 built-ins (light+0 - light+9, Fn+M1 - Fn+M3), and I've never used the windows ghub software yet (no windows partition on this machine), so this pattern definitely came from g915-led somehow. And it was un-expected but not unwelcome just to be clear. It's mercifully static which is a huge improvement over the unstoppable flashing/breathing circus it was doing before. Even if I never get it to do anythijng else, this is good enough to live with! So thank you for that at least. Whoa, I just noticed dmesg/syslog is continuously spamming: Watching |
|
I guess what's going on is, the udev rule is successfully applying /etc/g810-led/profile many times per second forever, which would explain both why my lights changed on their own, and why I can't seem to change them with other commands ? |
|
I removed the RUN action from the udev rules and re-plugged the receiver, and udev is not spamming syslog, it just reacted to the plug event, set the permissions, and stopped like normal. And now g915-led commands work as documented, except as already noted, the action is unreliable. "-a 888800" for instance changed most keys yellow, but left a random scattering of keys turned off. So, that's already been noted, just saying me too on that one. |
|
Not a random scattering. Repeated re-running of the same -a 888800 command always leaves the same set of keys dark: |
|
When I run But the profile applied by -p filename only lasts until 60 seconds after being left idle. |
|
The same command in the udev rule does not exit with 2, at least not from the normal user's interactive environment, which is not the same as the environment that the udev command runs in. I thought maybe it was because the sample profile includes key groups that this keyboard doesn't have, but that doesn't seem to hurt anything. |
|
I think now I have this working as well as promised. I think that disabling on-board-mode must be disabling idle timeout altogether, which means the battery will die in a number of hours instead of months, but it is what it is. Since the g915-led commands are working, maybe I can insert commands into the desktop environment or systemd to restore on-board mode so that the on-board power management resumes, which probably puts the mcu and radio to sleep more than just shutting off the lights. And then issue other commands to disable on-board mode again when waking from sleep or lock screen etc. Anyway, aside from the udev rule and the different usb device id number for my dongle, this is working for me more or less as documented by yawor. Thank you. |
|
Hi, I built this branch (in libusb mode) and I can control the colors nicely on my G915, however it seems that I cannot put the keyboard into software mode. It tried running: and the command appears to succeed, but my keyboard shortly thereafter reverts to the color cycling. Am I doing something wrong? Thanks |
I've added implementation for G915. It works only with libusb (I don't know how to make it work with hidraw).
Also it's only for wireless connection. It won't work if keyboard is also connected to PC via USB cable.
g810-led has a lot of assumptions regarding the communication with keyboards, like interface and endpoint numbers in libusb mode or HID++ 2.0 target id (the second byte in the data packet sent to the keyboard). Because of that I had to make some changes here and there to make the code compatible with G915.
G815 and G915 are actually quite similar. They use the same protocol, but third byte in the data (feature index) is different because of different number of API features available in both models, so the numbers are shifted. Also the target id (second byte) must be set to 0x01 in wireless mode to talk to the keyboard because target 0xFF means the receiver itself.
It should also be possible to support G915 in wired mode, but like in case of G815 vs G915, the feature indexes are also different for G915 over cable so it would require additional work.