Skip to content
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

Master issue 48 segfault with k70 rgb in bios mode #64

Conversation

frickler24
Copy link
Collaborator

@frickler24 frickler24 commented Feb 5, 2017

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:

  • Unplug the keyboard first,
  • switch the mode,
  • wait a few seconds (about 10; this time is for your usb driver to detect the disconnect. This is done very fast normally, but these state transfers are all but normally...)
  • reconnect the keyboard
  • have a look at you system logs (or stdout, if you have called the ckb-daemon manually).
    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

When switching K70RGB or K95RGB to BIOS mode, only one usb channel is provided
by the KB driver.
Because in usb_linux.c for all other modes the last channel is not used,
zero channels have to be initialized. this brings the daemon to a SIGSEGV.

While debugging this, sometimes the KB got informations which stopped the KB
completely from working. Only disconnecting + connecting worked,
no software-reset via the switch had been successful in this state.
When connecting a KB in this state to the daemon, 0 channels were detected.
These two special conditions (0 and 1 EP for an RGB device)
got special treatment in the code.
Changing the operating modes for the RGB keyboards that provide this feature
(such as the K70RGB or the K95RGB) will result in massive disruptions
to the daemon and the keyboard itself.

A test matrix is stored in the corresponding issue # 48.

The settings here refer to the timeout before sending a USB message.
The timeout was previously 10ms and has been doubled.

Minor corrections and the clipping of the debug output
in a #define DEBUG were also committed here.
@frickler24
Copy link
Collaborator Author

This one is replaced by #89, which is based on testing.

@frickler24 frickler24 closed this Feb 26, 2017
@frickler24 frickler24 deleted the master-issue-48-Segfault-with-K70-RGB-in-BIOS-mode branch February 26, 2017 16:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant