ckb does not connect to devices after sleep

[viggy96]

ckb does not connect to devices after waking up from sleep, and fails to connect to devices that have been plugged in some time after Linux has finished booting.

[frickler24]

@viggy96 I cannot confirm this. I just had done a lot of testing with switching keyboards on and off. Reconnecting when waking up from standby is essential to me.
So we need more info from you: What system, what corsair hardware (mouse, KB, model, firmware), what do you mean with sleep (hybernate, standby) and so on.

[viggy96]

System: Lenovo ThinkPad W540, Ubuntu 16.04.1 LTS

Corsair devices: K70 keyboard & M65 PRO RGB mouse

By sleep, I mean standby/suspended, not hibernate. I have tried adding the USB quirks to the boot flags, but that does not help.

[Tynach]

@viggy96, what sort of K70? I have the K70 LUX and cannot reproduce this. I have a desktop computer though, with a lot of power saving features turned off... But nonetheless, I can standby/suspend (go into 'sleep mode') and come back out with no problems. I too run Ubuntu 16.04.1.

However, I only have one such Corsair product. Perhaps it's the fact that you have both a keyboard and a mouse? Or perhaps it's working for me because of various hardware settings in BIOS that I've switched to not even attempt to save power. Or just because I'm on a desktop.

I'll try turning on various power saving mechanisms (some of which warn that some devices may not wake from sleep as reliably if I enable them).

[viggy96]

Its the K70 RGB.

I don't believe that its the fact that I have multiple Corsair devices, since this problem occurs even when I only have one device connected (usually the M65 PRO RGB).

[Tynach]

I apologize, BIOS' way of phrasing the L1 power saving mode was that it could cause 'incorrect data transmission', not that things would fail to wake back up.

At any rate, still works fine going into sleep mode and back. Had also enabled 'aggressive' power saving, and disabled letting the OS determine what hardware could be put to sleep or not. Overall, I'm feeling doubtful that this is the CKB-Next driver's fault alone.

Maybe something else to look at is the boot flags for the Linux kernel? I remember having to edit /etc/default/grub and adding usbhid.quirks=0x1B1C:0x1B36:0x20000408 at the end, then running update-grub. Have you tried having just one of your devices plugged in, and also removing the corresponding entry from your boot parameters?

[frickler24]

@viggy96 what can you find in the journal? There should be lines like

[I] Starting input thread for /dev/input/ckb1
[I] Starting input thread for /dev/input/ckb2
[I] Setup finished for /dev/input/ckb1
[I] Setup finished for /dev/input/ckb2

When you (re) start your daemon, you should get two lines, indicating the setup status. Do you get new lines when waking up your system? Or do you get new USB Channels after waking up?

If we don't get new hints with this, please wait until the patch #64 is published (or install that patch on your system). With this patch, you get more debug info and a longer delay when starting the usb communication. It belongs to #48.

[viggy96]

This is what I get when I restart the daemon in the terminal (with only the mouse):

ckb: Corsair RGB driver beta-v0.2.7 [I] Root controller ready at /dev/input/ckb0 [I] Connecting Corsair Gaming M65 Pro RGB Mouse at /dev/input/ckb1 [I] Starting input thread for /dev/input/ckb1 [I] Setup finished for /dev/input/ckb1

However, the ckb UI does not show the mouse as connected, and my lighting profile does not load.
Similarly for when both of my devices are connected (or just keyboard).

[frickler24]

OK, the daemon has detected it well.
Next try: When you got that messages you sent me, the config directory for the M65 is /dev/input/ckb1.
Looking in that directory and some important files (created by the daemon when starting the device), it should look like:

lutz@Mainfrix /dev/input/ckb1 $ ls -lsa
insgesamt 20
0 drwxr-xr-x 2 root root 200 Feb  6 22:44 .
0 drwxr-xr-x 7 root root 840 Feb  6 22:45 ..
0 prw-rw-rw- 1 root root   0 Feb  6 22:57 cmd
4 -rw-r--r-- 1 root root  64 Feb  6 22:44 features
4 -rw-r--r-- 1 root root   5 Feb  6 22:44 fwversion
4 -rw-r--r-- 1 root root  29 Feb  6 22:44 model
0 prw-r--r-- 1 root root   0 Feb  6 22:44 notify0
0 prw-r--r-- 1 root root   0 Feb  6 22:57 notify1
4 -rw-r--r-- 1 root root   5 Feb  6 22:44 pollrate
4 -rw-r--r-- 1 root root  33 Feb  6 22:44 serial
lutz@Mainfrix /dev/input/ckb1 $ cat features fwversion model pollrate serial 
corsair m65 rgb pollrate adjrate bind notify fwversion fwupdate
0204
Corsair M65 RGB Gaming Mouse
1 ms
0D02303DAE3D8C6953and_so_on
lutz@Mainfrix /dev/input/ckb1 $ 

Do you get the same (please have a look at the file permission also)?
How many directories /dev/input/ckb* do you have?
You should have /dev/input/ckb0 and one for each device plugged in.
If you try the following statement:
cd /dev/input && watch "bash -c 'ls -ls | grep ckb'"
you should get something like the following:

Alle 2,0s: bash -c 'ls -ls | grep ckb'                                                                             Mon Feb  6 23:07:50 2017

0 drwxr-xr-x  2 root root     100 Feb  6 22:44 ckb0
0 drwxr-xr-x  2 root root     200 Feb  6 23:05 ckb1
0 drwxr-xr-x  2 root root     200 Feb  6 22:45 ckb2

Now disconnect either your KB or mouse. you should see the correspondig line disappearing and - if replugging the device - the line reappears. you may try this several times, it is reproducable.

If this all works for you with your two devices, then the daemon is OK and we must have a look at the client.

[viggy96]

@frickler24 , Yes I can confirm that all that does work.
Only the client doesn't see my devices and load my lighting profiles. (They stay on the default white)
Further, this could be related to #67.

Sorry for the late reply.

[frickler24]

@viggy96 just that I understand it correctly:

1. Your (two) devices are running fine after a fresh boot.
2. After wake-up at least still one (or both?) of your devices are detected by the daemon
   (both ckb - directories are available and the daemon responds correct to un-/replugging the devices)
3. the Client does not detect (one or both?) the device (which number of ckb-channel?)

• What happens if you close (right-click the icon, quit ckb) and reopen the client?
• If this won't help: What happens, if you stop and restart the daemon while your client is running?

Please excuse my annoying questions, but the error seems to be difficult to reproduce on my system.

[viggy96]

@frickler24

1. Correct
2. Correct (both)
3. Correct (both) (ckb1, ckb2)

• I have tried closing and reopening the client, it still does not recognise my devices
• Restarting the daemon while the client is running does not work
• Quitting the client, restarting the daemon, and starting the client also does not work.

[frickler24]

Thanks. Now I am completely at a loss. I have to think about that, especially about the last statement.
When quitting the client and stopping the daemon: Does any /dev/input/ckb* directory remain?

[viggy96]

@frickler24 No, after quitting the client and stopping the daemon, no /dev/input/ckb* directories remain.

[frickler24]

The usb handling in the daemon robbes me fo the sleep.
We seem to have some unhandled conditions:

• Sometimes the firmware version isn't readable,
• sometimes we get error messages about unclaimed usb connection usage and so on.
• Some have trouble to connect while booting the system (sqirks don't help),
• in my system from time to time I get in trouble when waking up from suspend mode with different effect, depending on having just the KB connected or the M65RGB also.

So I suggest to investigate the usb handling more closely. Who would like to support me?

[fleischie]

Hey @frickler24. I'm Interested. What needs to be done? What do you need assistance with? I might be in chat tomorrow again, but for replicability I would appreciate a short summary of necessary tasks. 😄

[mattanger]

@frickler24 I've uncovered some weirdness, that may be related to my system or maybe it's a rare bug. It's certainly related to how usb is handled, though. Haven't had much time here lately, but after this week I'll have some more time that I an dedicate to investigating. I'll hop on IRC tomorrow, late morning or early afternoon for Europe.

…

On Tue, Feb 14, 2017 at 5:35 PM, Karl Fleischmann ***@***.***> wrote: Hey @frickler24 <https://github.com/frickler24>. I'm Interested. What needs to be done? What do you need assistance with? I might be in chat tomorrow again, but for replicability I would appreciate a short summary of necessary tasks. 😄 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFM7GsPe_0ymzZu07QdOpGikynOESSxYks5rcixHgaJpZM4L2swJ> .

[frickler24]

@fleischie and @mattanger I agree that this discussion should be writte here in github, so I will start:

Last weekend I had a short discussion in the irc about libusb. That's a library to cover the system specifics for Linux, MaxOS (and Windows) and it looks interesting for me. The question was: Should we rewrite the usb handling and if - based on what library?
IMHO we should talk about a plan and do not overthrow anything:

• First we should do a better documentation on the existing implementation (usb.c and the system dependent one for linux and mac). As I understand the mechanisms in linux and macOS are quite different. Maybe that is a root cause for the spurious effects we all have. I can do a more detailed documentation on usb.[ch] and usb_linux.[ch] and some of you apple experts should do it for the usb_mac.[ch]

• Second we should discuss whether we do a clear reimplementation based on what we know about the functions needed OR if we go on for a reimplementation based on libusb. libusb might help us to cover system dependencies, but it is an additional library for the users to deal with. so we should think twice.

• Third question I have: How to test the new implementation, no matter what form of implementation we chose. For this we need a solid cover on devices and device combinations. The USB implementations are central for the entire daemon.
  Do we have enough different corsair devices in combination with mac / linux systems, that we have a real chance for a wide test coverage? We have a lot users of the software, but not all of them are able to support us with the information we need for debugging or even run gdb for getting special informations.
  E.g.: A year ago I had an issue with an implementation: It was running fine with my K95RGB but one of the ccMSC-supporters indicated a problem with a mouse. Because I wanted to clear the issue, I bought that mouse - but no one of us can buy all hardware devices for testing or issue fixing.

That are the first questions I have.

[fleischie]

My two cents:

documentation

• With 'documentation' do you mean comments in the source code, that describes the behavior of each individual function/subroutine?
• I am by no means an expert in Mac, but I am willing to read the mac-documentation and understand what's going on/write the appropriate comments.

libusb or re-implemented

• I personally am for external libraries: They usually tend to be better managed/documented/(sometimes) tested and overall more approachable by external devs.
• Regarding extra maintain-effort: Qt is a dependency as well and it's more help than it's a burden, we just have to be very verbose with what version of what library we require.
• When packaging this project most package-managers can handle the library-dependencies as well and thus we might bypass additional libusb-issues for the more casual users.

testability

• This is tricky alright.
• Normally I would write a unit-test to ensure certain functionality when refactor/reimplement. But this seems more error-prone, than just hoping the rewrite works as expected.
• Additional we could provide scripts, that automate the debugging-process, so the users must only attach a log or something. This seems to be a little more productive in respects to the detect-device script.

P.S.: What do you mean with overthrow anything?

[mattanger]

• libusb and/or usb re-implementation: This is an area that I would like for us to work on. The current implementation strikes me as difficult to maintain between. I don't know much about libusb, but from what I understand libusb is pretty common across Linux distros. If it could help us merge usb_linux & usb_mac into a single cleaner and more maintainable implementation, I'm all for it.

• Testing: I like the idea of scripting some of the debugging processes. In concert with a more automated method of debugging maybe we should identify and organize a group of users who can act as our test base.

[frickler24]

@fleischie I ment "do not hurry" with this decision. We all have a lot to do, but maybe clearing these usb bugs would give us some more time.
What I ment with documentation is:

• Producing some overview pictures (what functions are used locally, but possibly are not static, what data structures are used between usb module and its callers and so on).
• Afterwards adding some comments in the code (at best readable for doxygen) and creating a doxygen documentation (I used this type of documentation when I started reading the client code and found it heplful).
• Third it may be that we need some control- and data flow diagrams, because we must map the existing interface to that of libusb.

@fleischie @mattanger I believe we can do a lot testing and debugging with scripting. But especially these connection oriented issues (different usb protocols depending on hardware and firmware versions, connecting / disconnecting devices, resuming from special OS modes, reaction on combination of keys): For these I have currently no idea how to automate this.
Or do you know a mocking interface to emulate most of these conditions to our daemon?

[fleischie]

OK, thanks for clarification. I see, what I can do in regards to the mac-specific implementation details of the usb-interface.

Regarding the testing: When I think about it really hard abstraction-wise, we would have to record a stream of binary data, that we pipe into the daemon/OS (thus, producing a keyboard-emulator). My personal knowledge is very limited about this, but I think we would need a lot of understanding how libusb/our own re-implementation works for the piping to work correctly.

Linus Torvalds once said:

"Regression testing"? What's that? If it compiles, it is good; if it boots up, it is perfect.

[ghost]

@fleischie I agree on your point but Linus Torvalds has a big community of very bright minds behind him that are working on the kernel full-time. And the code requirements before the patch is merged are rather high. But I also cannot think of the way different hardware-dependent cases could be automatically tested (of course it doesn't mean it's not possible).

[mattanger]

On the testing note, @fleischie, as cool as capturing a binary stream from corsair* devices and piping it to the daemon sounds, I think that may not the best use of our time. That said, if you or someone else thinks that sounds neat and wants to do it, by all means.

I think a better approach may be to document and automate a testing and data/packet capture procedure that testers can use to send us data for devices that none of us have access to.

[frickler24]

@fleischie and @light2yellow here is the first documentation from testing branch (no additional comments done up to now).
You can find three things:

• the HTML documentation of ckb-daemon created by doxygen
• the same as PDF
• the Doxyfile I used if you want to change parameters for your own

Hope it helps a bit. In the next days I will start documenting the usb / usb-linux files and push a new version of the doxy files

[frickler24]

I've updated the HTML info and the pdf file as mentioned in the last post.
It's a very hard job to document this driver.
most of usb.c, parts of usb_linux.c and some functions and data members in other files are documented now.
Tomorrow it's going on.
If you are interested, have a look at _setupusb() (there is a long doc) and please give me feedback, if one can understand this. My English is really not the best :-(

[fleischie]

@frickler24 Thank you for your effort. 😄

I will check out the docs in detail in the following weeks, as I only had time to skim them shallowly.

Your English is sufficient, I would say. The important part is, that you put all this effort in setting up this documentation. If there are grammatical or orthographical issues, a more proficient users can amend the docs. So, thank you again for your work. 😊

[frickler24]

usb.c, usb.h and most of usb_linux.c are done now. The links above show the new content.
Currently I have some problems with the pfd version, because latex gets errors because of utf-8 special chars.
So eg no content list is generated and a lot of format error are generated. The html code looks better than the pdf, but to search for something pdf is the better choice.

In the pdf at page 331 usb.c starts, at 353 usb.h and at 397 usb_linux begins.

[mattanger]

@frickler24 I've just set up a host for ckb-next.org. If you'd like, I get you access and we can host the docs on that or I can point something like docs.ckb-next.org to your server. Shoot me an email and we can figure it out.

[frickler24]

Maybe there is a new hint for the devices not reconnecting properly after wakeup (the original thread :-))
Yesterday and today I found the following sequence in my logfile:

lutz@Mainfrix ~ $ journalctl |grep "^Feb 22" | egrep "usb 3-13|ckb"
Feb 22 06:30:44 Mainfrix ckb-daemon[1058]:     ckb: Corsair RGB driver beta-v0.2.7
Feb 22 06:30:44 Mainfrix ckb-daemon[1058]: [I] Root controller ready at /dev/input/ckb0
Feb 22 06:30:49 Mainfrix kernel: usb 3-13: new full-speed USB device number 6 using xhci_hcd
Feb 22 06:30:49 Mainfrix kernel: usb 3-13: New USB device found, idVendor=1b1c, idProduct=1b11
Feb 22 06:30:49 Mainfrix kernel: usb 3-13: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 22 06:30:49 Mainfrix kernel: usb 3-13: Product: Corsair K95 RGB Gaming Keyboard 
Feb 22 06:30:49 Mainfrix kernel: usb 3-13: Manufacturer: Corsair
Feb 22 06:30:49 Mainfrix kernel: usb 3-13: SerialNumber: 0F022014AE3B9406537275B6F5001945
Feb 22 06:30:50 Mainfrix ckb-daemon[1058]: [I] >>>vendor = 0x1b1c, product = 0x1b11, path = /dev/bus/usb/003/006, syspath = /sys/devices/pci0000:00/0000:00:14.0/usb3/3-13
Feb 22 06:30:50 Mainfrix ckb-daemon[1058]: [I] Connecting Corsair K95 RGB Gaming Keyboard at /dev/input/ckb1
Feb 22 06:30:50 Mainfrix ckb-daemon[1058]: [I] claiming interfaces. name=Corsair K95 RGB Gaming Keyboard , serial=0F022014AE3B9406537275B6F5001945, firmware=0205; Got >> 3<< as ep_str
Feb 22 06:30:50 Mainfrix ckb-daemon[1058]: [I] claiming 3 endpoints
Feb 22 06:30:50 Mainfrix ckb-daemon[1058]: [I] Starting input thread for /dev/input/ckb1
Feb 22 06:30:50 Mainfrix kernel: input: ckb1: Corsair K95 RGB Gaming Keyboard as /devices/virtual/input/input19
Feb 22 06:30:50 Mainfrix kernel: input: ckb1: Corsair K95 RGB Gaming Keyboard as /devices/virtual/input/input20
Feb 22 06:30:55 Mainfrix ckb-daemon[1058]: [I] Setup finished for /dev/input/ckb1
Feb 22 18:47:19 Mainfrix kernel: usb 3-13: reset full-speed USB device number 6 using xhci_hcd
Feb 22 18:47:19 Mainfrix kernel: usb 3-13: usbfs: process 2493 (ckb-daemon) did not claim interface 0 before use
Feb 22 18:47:19 Mainfrix kernel: usb 3-13: usbfs: process 2493 (ckb-daemon) did not claim interface 1 before use
Feb 22 19:21:39 Mainfrix ckb-daemon[1058]: [E] os_sendindicators (usb_linux.c:86): Device or resource busy
Feb 22 19:21:39 Mainfrix kernel: usb 3-13: usbfs: process 2443 (ckb-daemon) did not claim interface 0 before use
Feb 22 19:21:39 Mainfrix kernel: usb 3-13: usbfs: process 2443 (ckb-daemon) did not claim interface 2 before use
Feb 22 19:21:39 Mainfrix ckb-daemon[1058]: [E] os_sendindicators (usb_linux.c:86): Device or resource busy
Feb 22 19:21:39 Mainfrix kernel: usb 3-13: usbfs: process 2443 (ckb-daemon) did not claim interface 0 before use
Feb 22 19:22:06 Mainfrix sudo[2779]:     lutz : TTY=pts/2 ; PWD=/home/lutz/Projekte/ckb-next/src/ckb-daemon ; USER=root ; COMMAND=/usr/bin/lsusb
Feb 22 19:22:13 Mainfrix sudo[3787]:     lutz : TTY=pts/2 ; PWD=/home/lutz/Projekte/ckb-next/src/ckb-daemon ; USER=root ; COMMAND=/usr/bin/lsusb

So why is the kernel resetting the usb device at 18:47:19 (wakeup-time)?
I'll build some more debugging info into the daemon to follow that effect.

[tatokis]

If the kernel is resetting the keyboard, then it most likely sounds like a firmware implementation issue on the keyboard itself, possibly not responding when the computer wakes up. I think the problem is that the daemon sees this reset, and tries to send all the initialisation packets all over, but I assume the keyboard is already in some specific mode from before the computer went to sleep and doesn't respond well to the packets/usb commands it receives. Perharps we should make a list with what devices are affected by this? I tried my K70 RGB in different computers with different USB host controllers and I was unable to reproduce.

[frickler24]

I have this issue with my K95RGB.
I inserted a lot of debugging info at all positions, where a wakeup may disrupt an ioctl or similar.
There are several conditions to detect what happened, but no code to handle it yet.

[frickler24]

Here is some more output with debugging info.IN this case today the keyboard worked, but no macros-keays and no key-lighting on pressure was active.

--> fresh boot
Feb 23 06:12:09 Mainfrix ckb-daemon[1082]:     ckb: Corsair RGB driver beta-v0.2.7
Feb 23 06:12:09 Mainfrix ckb-daemon[1082]: [I] Root controller ready at /dev/input/ckb0
Feb 23 06:12:14 Mainfrix kernel: usb 3-13: new full-speed USB device number 6 using xhci_hcd
Feb 23 06:12:14 Mainfrix kernel: usb 3-13: New USB device found, idVendor=1b1c, idProduct=1b11
Feb 23 06:12:14 Mainfrix kernel: usb 3-13: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 23 06:12:14 Mainfrix kernel: usb 3-13: Product: Corsair K95 RGB Gaming Keyboard 
Feb 23 06:12:14 Mainfrix kernel: usb 3-13: Manufacturer: Corsair
Feb 23 06:12:14 Mainfrix kernel: usb 3-13: SerialNumber: 0F022014AE3B9406537275B6F5001945
Feb 23 06:12:15 Mainfrix mtp-probe[2320]: checking bus 3, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-13"
Feb 23 06:12:15 Mainfrix ckb-daemon[1082]: [I] Connecting Corsair K95 RGB Gaming Keyboard at /dev/input/ckb1
Feb 23 06:12:15 Mainfrix ckb-daemon[1082]: [I] Starting input thread for /dev/input/ckb1
Feb 23 06:12:15 Mainfrix kernel: input: ckb1: Corsair K95 RGB Gaming Keyboard as /devices/virtual/input/input19
Feb 23 06:12:15 Mainfrix kernel: input: ckb1: Corsair K95 RGB Gaming Keyboard as /devices/virtual/input/input20
Feb 23 06:12:20 Mainfrix ckb-daemon[1082]: [I] Setup finished for /dev/input/ckb1

--> standby and wakeup

Feb 23 07:18:34 Mainfrix kernel: usb 3-13: reset full-speed USB device number 6 using xhci_hcd
Feb 23 07:18:34 Mainfrix kernel: input: Corsair Corsair K95 RGB Gaming Keyboard  as /devices/pci0000:00/0000:00:14.0/usb3/3-13/3-13:1.0/0003:1B1C:1B11.0009/input/input32
Feb 23 07:18:34 Mainfrix kernel: input: Corsair Corsair K95 RGB Gaming Keyboard  as /devices/pci0000:00/0000:00:14.0/usb3/3-13/3-13:1.1/0003:1B1C:1B11.000A/input/input33
Feb 23 07:18:34 Mainfrix kernel: usbhid 3-13:1.2: couldn't find an input interrupt endpoint
Feb 23 07:18:34 Mainfrix kernel: usb 3-13: usbfs: process 2441 (ckb-daemon) did not claim interface 0 before use
Feb 23 07:18:34 Mainfrix kernel: usb 3-13: usbfs: process 2441 (ckb-daemon) did not claim interface 1 before use
Feb 23 07:18:34 Mainfrix ckb-daemon[1082]: [W] os_inputmain (usb_linux.c:244): os_inputmain 2: got retcode -1 and errno = 4, Interrupted system call
Feb 23 07:18:34 Mainfrix ckb-daemon[1082]: [W] os_inputmain (usb_linux.c:299): os_inputmain 5: got retcode -1 and errno = 16, Device or resource busy
Feb 23 07:18:34 Mainfrix ckb-daemon[1082]: [W] os_inputmain (usb_linux.c:299): os_inputmain 5: got retcode -1 and errno = 16, Device or resource busy
Feb 23 07:18:34 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 07:18:34 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 07:18:34 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 11:47:26 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 11:47:26 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 11:47:26 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 11:47:26 Mainfrix ckb-daemon[1082]: [W] os_inputmain (usb_linux.c:244): os_inputmain 2: got retcode -1 and errno = 4, Interrupted system call
Feb 23 15:49:00 Mainfrix ckb-daemon[1082]: [W] os_inputmain (usb_linux.c:244): os_inputmain 2: got retcode -1 and errno = 4, Interrupted system call
Feb 23 15:49:00 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 15:49:00 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 15:49:00 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 15:49:00 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 22:05:25 Mainfrix ckb-daemon[1082]: [W] os_inputmain (usb_linux.c:244): os_inputmain 2: got retcode -1 and errno = 4, Interrupted system call
Feb 23 22:05:25 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 22:05:25 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18
Feb 23 22:05:25 Mainfrix ckb-daemon[1082]: [W] _ledthread (input_linux.c:179): _ledthread: got retcode 0x18

Interesting are the following aspects:

• marking a missing usbclaim before any usb -reaction from wakeup.
• in comparison to the last logging, there are mentionsed claiming errors for usb 0 and 1 but not usb 2

I will collect more log files in the coming days. Unfortunately, one can obviously not provoke the error by manually setting the computer into standby. Perhaps we are still on the trail with patience.

[viggy96]

Any update on this issue? It seems that the daemon properly detects the device (M65 Pro RGB), but the mouse settings are not applied, and the ui does not show the tab for the device when connecting the mouse after the computer has been on for some time and has been cycling between sleep and awake.

[viggy96]

Any update on this issue? It seems that the daemon properly detects the device (M65 Pro RGB), but the mouse settings are not applied, and the ui does not show the tab for the device when connecting the mouse after the computer has been on for some time and has been cycling between sleep and awake.

[Calvin-Xu]

I have the same issue here on Mac OS 10.13.1 with K70 RGB. System detects keyboard fine but ckb cannot connect to keyboard. Happens often after device sleeps.

[Alan-Penkar]

I have this issue as well with the K70RGB on Ubuntu Budgie 17.10. It immediately wakes on shutdown and the keyboard is no longer responsive. Also for some reason, on reboot the keyboard will not load and system doesn't boot. A hard reset will always fix this.

[tatokis]

ckb-next/ckb-next#3

[dron1885]

For anyone having the same issue in 2021 (like me with K70 LUX RGB).
Patchwork solution: create a service that restarts the ckb-next-daemon after sleep/hibernation.

[Unit]
Description=Restart ckb-next service after sleep/hibernation
After=suspend.target hibernate.target

[Service]
Type=simple
ExecStart=/usr/bin/systemctl --no-block restart ckb-next-daemon.service

[Install]
WantedBy=suspend.target hibernate.target