Master issue 48 segfault with k70 rgb in bios mode #64
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pullrequest avoids the most important crashes of the daemon when the polling switches on the RGB keyboards are changed.
Unfortunately, the cause of the error is the co-working of the keyboard firmware, the Linux USB driver and the ckb-daemon.
I have tried different test combinations with my K95RGB and M65RGB mouse. The result can be found here: Test matrix.pdf.
In short, even without the ckb-daemon you can bring the USB driver or even the keyboard itself to crash by moving the state-switches.
This is only supplemented by the daemon, so that the user is completely irritated and the cause of the error can no longer be identified.
What I found was a hint in the usb driver about the delays before sending a message: 5ms was the standard. Because I had a lot of trouble with the 8ms settinngs for my K95RGB, I tried to double this delay. It works a lot better, even not perfect.
My suggestion is that we use that increased setting and observe whether we get a timing problem elsewhere.
If you are interested: I have several logfiles from the usb communication to show with wireshark or vusb-analyzer
The following info may be helpful for our users in the README.md file.
But first please check with your HW (K70xxx and others), if that change work for you.
The most reliable way to switch is by following that order:
After maximum 15 seconds it should inform you about having started the communication with the KB.
If after 15 seconds the keyboard remains dark or simply not react, the daemon should be killed, the keyboard unplugged and after 15 seconds replugged.
The times may vary depending on your system: It is needed for the usb driver to detect the reconnection of the usb device.
Please try killing the daemon gently first with "sudo pkill ckb-daemon", because with this it does some cleanup.
Only if the process wont stop (there is a situation with a loop between kernel and daemon), kill it tough and then clean up manually. Example for Linux:
sudo pkill -9 ckb-daemon; sudo rm -rf /dev/input/ckb* # be careful with this statement!!!
If you do not clean up and have a lot of testing, you will have too many devices in the directory (max 10 allowed).
references #48