-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for G915 #25
Comments
thank you for this report, please disable the I am pretty sure that the G915 needs a different disable sequence and the one from the G910 will not work. |
Commenting out lines 53 and 54 did not fix it. In the gif you have showing how to contribute a keyboard, when you are pressing the g keys and getting byte codes displayed, you are typing G1 and then pressing G1, typing G2 then pressing it etc, but I am unable to actually type any letters, every button I press just reads out the two byte codes. I am also unable to press control-c for that reason, and if I use my mouse to close the console window, the keyboard does not work at all and the wireless adapter must be unplugged and plugged back in (keyboard power off does not work) for the keyboard to start working again. How were you finding the byte codes for disableGKeys? I can send you the output of pressing any button. |
Here is the output from the furthest I was able to get. the keys were pressed in the order: G1 through G5, M1through M3, MR, Mediakeys Back, Pause, Forward, Mute, Volume up and down but I forget which was first. Pressing any other key on the keyboard will just result in more byte codes. python3 src/newDeviceDebugger.py DEBUG: Searching for keyboard... |
thanks a lot for this information, that is very useful. Would you mind posting your output of the From the looks of it, the keyboard seems to use the same USB endpoint for the G-keys and the "regular" keys, which would really suck (and explain why your keyboard becomes unusable when you run the script since it unhooks the kernel driver). All the other keyboards use two separate endpoints which allows me to use the Linux kernel driver for the normal keys and hook keyboard-center into the G-keys endpoint.
By reverse engineering the Windows driver. |
No problem, and thank you for the software! I'm glad I can help.
The default G-key mappings in the Logitech software on a windows machine are just standard F1-F5 keys. There are options for commands like alt-tab and stuff, and things like mouse button clicks, but there is nothing that is outside of the standard keyboard and mouse buttons as far as I can tell. Maybe you could make use of the extended F keys, like F13+, as those are able to be mapped to the G keys, and most people would never use those anyways? |
This page has a lot of useful information about the G915. There are multiple endpoints, and can work in wired vs wireless and stuff, something in this guys debugging efforts for another program may help with this? |
sadly the discussion in keyleds is not very useful for me, since they are trying to control the LEDs, which all keyboards use a different USB endpoint for afaik. IIRC when you plug you keyboard in directly via USB, then it should behave the same as a G815, but something is really weird in your output. Can you please double check that your USB ID for the G915 is
All Logitech keyboards with GKeys have a default mapping, which for most of them is towards the FKeys (aka G1 maps to F1 etc). In order to do that, I need to send a specific command to the keyboard using the There is sadly no other way, I cannot map G1-G5 to F13-F20, because the keyboard will ignore any command as long as the default mapping is active. One additional problem with the wireless keyboards like the G915 is, that (as it seems like) the detach kernel driver command does actually detach the driver for the USB receiver and not the keyboard itself rendering the keyboard unusable. I would really love to implement support for as much keyboards as possible, but I can only do that when either someone tells me the byte commands I need to send to the keyboard or by getting my hands on one. Sadly G915 is a very expensive keyboard. |
Thanks for the long explanation. Now some of it makes more sense. We worked on the G910 recently. I'm having serious issues, just haven't wanted to heap-on more problems. Once it starts working it works consistently and well. But getting it to work after having booted to Windows, then back to Linux Mint, has occasionally taken a lot of time and fooling around. Sometimes I just give up. Those steps include powering-off everything - even the mobo at the power supply, unplugging the keyboard, and reinstalling Keyboard Center. Many times that doesn't work. Restarting Keyboard Center multiple times works, sometimes. Last night that didn't. So I watched a movie and 2-3 hours later another single restart of the KC service worked. Weird. It's a little embarrassing given I've been working hardware and software since 1976. Cannot find a consistent technique or combination that makes any sense. I would like to contribute a new wired Logitech G910 Orion Spark to your project. |
@Corionis thanks a ton for you offer I highly appreciate it. I have not forgotten you and your issue with the G910. That being said, I cannot accept your offer since I actually can get my hands on a G910 by borrowing it. I sadly didn't find the time to work on it yet :(. As for the G915, that is a way harder problem to solve, because I currently don't know how I can access the raw data coming from the USB receiver without detaching the entire device. |
Alright. Glad there's a way. We'll figure it out over time. (I deleted the post with my email address). |
It seems like the program Solaar might have figured something out here. They have the ability to divert G keys, and to receive G key presses as G1 etc and not what they are mapped to, and this works for the 915. Solaar also displays information for both the lightspeed adapter and the keyboard itself.
I'll try things plugged in soon as well to see if that makes a difference. |
oh thanks for the output, so the USB ID is for the receiver, which makes a lot of sense and sadly also means that my current approach will not work.
Solaar is a very good idea, I did not think about that. I will have to check out how those guys are doing it. |
@BrandonR541 does the G915 map G1 to F1 etc by default? (Or any other key for that matter or do the G-keys just do "nothing"?) |
Yes, the default mapping for the G915 is G1 to F1 etc. They can be set to "disabled" though. |
This is the same output as my last post, but with the keyboard plugged in and not using the wireless adapter.
|
how do you disable that? Does Solaar offer a function for that? |
thank you for the lsusb output, this is what I originally expected to see with keyboard center should be able to work with the keyboard in the plugged in state |
G key Disable InfoThe G keys can be set to "Disabled" through the Logitech software on a windows machine.
The Solaar rules are where you can set macros and shortcuts and stuff through a condition evaluations and actions. The conditions include key-presses, where it treats each G key as its own special thing, and not what it is set to such as F1 etc. The only other information I see is when you set a condition to keypress a G key, it also shows a code - G1 is 1001 G2 is 1002 etc. Other special things like Brightness Down is 00C7 Crown is 4600, stuff like that. Wired Mode InformationWith the keyboard plugged in and the device id set properly, this is the output:
With lines 53 and 54 commented out again, this is what I get:
Note: |
@BrandonR541 thanks for the output, I updated the debugger scipt, could you please pull the repo and run the the debugger script again with elevated permissions (aka sudo)? I think the error you are seeing in the first output is because of lacking permissions, because you don't have the udev rules set. |
After running the new version, I am still getting errors, with and without sudo.
I also tried commenting out the same lines as before again (now 117 and 118) but that did not change anything. Is there something I should add to udev rules? running evtest shows the G915 as several devices, and each one has a different set of keys and stuff. Could those outputs be useful?
|
The broken pipe error and
If you run as sudo you don't need any udev rules.
Sadly not really, because all keyboards have multiple event groups for a specific group of keys, so this is expected. Could you tell me your python and kernel version pls? |
Would it help to try running on a clean install, like a live usb? I could also give you remote access in that case if it would help |
so weird, both your Python and Kernel version are supported, so I really wonder why those errors are happening. I will check how Solaar is talking to the keyboard, maybe I can learn something from that. If I cannot get my hands on a G915, then remote access to a linux VM / live system would be a great alternative. Sadly I don't think I will have time for that any time soon though. :( |
I have installed a lot of stuff trying different keyboard mapping and led things, so maybe there is a conflict somewhere, I'll try things out on a fresh install at some point just in case. No worries about the timeline, I'm not in a rush, but yeah at some point in the future if you think remote access could help just let me know. I also have a windows machine if there is anything else that would be helpful on there. Thanks for all the effort to make this work, I really appreciate it, and thanks for creating the software regardless of getting the G915 to work! |
I am trying to setup a Logitech G915 Lightspeed keyboard. When I run newDeviceDebugger, it ends of failing and hanging, and the keyboard becomes non-operational until the wireless usb adapter is removed and reinserted. I believe it is a problem with the disableGKeys line, the byte code provided in the script for the G910 does not work, and I do not know where to find the proper code to add to the script. Below the terminal output from running newDeviceDebugger:
sudo python3 src/newDeviceDebugger.py
DEBUG: Searching for keyboard...
DEBUG: Keyboard found! :)
DEBUG: requesting USB endpoint...
DEBUG: check and detach kernel driver if active
INFO: starting service...
/home/brandon/Desktop/keyboard-center/src/newDeviceDebugger.py:122: DeprecationWarning: There is no current event loop
evLoop = asyncio.get_event_loop()
DEBUG: Using selector: EpollSelector
DEBUG: Connection using HIDAPI...
DEBUG: Sending sequence to disable G keys
ERROR: Task exception was never retrieved
future: <Task finished name='Task-1' coro=<usbListener() done, defined at /home/brandon/Desktop/keyboard-center/src/newDeviceDebugger.py:48> exception=HIDException('Broken pipe')>
Traceback (most recent call last):
File "/home/brandon/Desktop/keyboard-center/src/newDeviceDebugger.py", line 58, in usbListener
await disableGkeyMapping(disableGKeys)
File "/home/brandon/Desktop/keyboard-center/src/newDeviceDebugger.py", line 45, in disableGkeyMapping
hdev.write(data)
File "/home/brandon/Desktop/keyboard-center/src/lib/hid.py", line 163, in write
return self.__hidcall(hidapi.hid_write, self.__dev, data, len(data))
File "/home/brandon/Desktop/keyboard-center/src/lib/hid.py", line 154, in __hidcall
raise HIDException(err)
lib.hid.HIDException: Broken pipe
The text was updated successfully, but these errors were encountered: