Logitech G710 no sidewinderd playback
aldevel opened this issue · comments
It seems, everything works but there is no playback. Sidewinderd service starts at login, all of the led lights up, record seems to be working.
I use the latest sidewinderd from https://github.com/tolga9009/sidewinderd
I didn't change anything exept the user in /etc/sidewinderd.conf.
There is no encrypted user's directory.
When sidewinderd driver uninstalled, G key works as number.
I use Debian Stretch (testing).
Here are the locations of the files on my system just to show, I didn't reconfigure anything:
/etc/sidewinderd.conf
/etc/systemd/system/multi-user.target.wants/sidewinderd.service
/home/user/.local/share/sidewinderd
/usr/local/bin/sidewinderd
/usr/local/lib/systemd/system/sidewinderd.service
Let me know how should I solve this issue or if there is any ongoing bug related to this problem.
Thanks for this great driver.
Hi there!
Just adjusting the user should be enough, usually. When you record a macro, does the program create .xml files in one of the subfolders in /home/user/.local/share/sidewinderd?
Also, I would recommend starting sidewinderd (sudo sidewinderd) from a commandline and debugging with the commandline output. It should print any errors.
Cheers,
Tolga
Hello,
thanks for the prompt response. Yes, it's create *.xml files at the location.
The sidewinderd open and record process seems like this (sudo sidewinderd):
Started sidewinderd.
Found device: 046d:c24d
Keyboard Constructor
getFeatureReport(6) returned: 6 10
getFeatureReport(6) returned: 6 0
getFeatureReport(6) returned: 6 0
getFeatureReport(6) returned: 6 0
getFeatureReport(6) returned: 6 0
Found device: 046d:c24d
Found device: 046d:c24d
getFeatureReport(6) returned: 6 10
getFeatureReport(6) returned: 6 90
Start Macro Recording on /dev/input/event0
getFeatureReport(6) returned: 6 90
Exit Macro Recording
The *.xml file in profile_1 folder seems like this if I record a on M1 and G1 for example:
<Macro>
<KeyBoardEvent Down="1">30</KeyBoardEvent>
<DelayEvent>82</DelayEvent>
<KeyBoardEvent Down="0">30</KeyBoardEvent>
</Macro>
Okay, the .xml file looks good to me. We had a similar issue #3, maybe it's related. Are you using latest master branch, or are you using 0.3.1?
/dev/input/event0 looks very suspicous. I would ask you to remove any USB peripherals (if possible) and try it again. The driver probably looks out for the wrong /dev/input/event* file. This is the case, when there are more than 1 keyboard device attached to your system. This may be a Logitech unified receiver, or something else.
I will not be able to look into it until 16th August, I'm on vacation. But after that, I'm sure we can get it fixed. The udev code for device discovery needs an overhaul anyways :)!
I'm sure it's a great driver already so I'm glad you're still deal with issues like this. Thanks for your advises, I'll try some things until you come back. Have a fun vacation!
I will work on this issue today. I also have a spare system for installing Debian Stretch, so we're talking the same language.
I would ask you to run sudo sidewinderd in a terminal again and post me the console output, while you're trying to playback a recorded macro.
Thanks for your efforts, actually the output for sidewinderd start and recording still the same what I reported above in my second comment. I use the latest downloadable master sidewinderd branch.
I was able to reproduce the error under Debian Stretch. Also, the G710+ is not working under my native Arch Linux install aswell - it immediately starts recording macro, without choosing a key.
My SideWinder X4 code is in a better shape - but I've spotted errors there aswell. When pressing a non-assigned macro key, nothing should happen. However, non-assigned macro keys trigger a macro play event.
Now that I'm able to reproduce the errors, fixing them should be straightforward. I will keep you up-to-date on this issue. Thanks for reporting!
Okay, found the culprit. The problem was inside LogitechG710::getInput(). There are a few issues coming together and causing these issues.
First, our poll() call waits for TIMEOUT amount of time, which is set to 5 seconds, before it skips the current loop. Upon each skip, LogitechG710::getInput() makes KeyData::KeyType::Macro out of it with index 0, eventhough it doesn't exist. Also, it should be KeyData::KeyType::Unknown. We need to fix this problem in vendor and in core. core should filter out key index 0 and vendor shouldn't send out key index 0 in the first place. I have a proposed fix for the latter in branch issue16.
Second, even if poll() doesn't timeout, we still set keyData.type to Macro for invalid events, instead of Unknown. Fixing should be identical to the information above. I have successfully tested this under Arch Linux, testing Debian Stretch now.
Update: Debian Stretch also works for me. Please test branch issue16. I will work on core changes and fix the other keyboards. They should suffer from similar issues.
Awesome! issue16 branch works perfect on my system too (Debian Stretch-testing + Logitech G710). Thanks a lot, it's a great software indeed!