Jump to content
Corsair Community

(Unofficial) Linux / OSX Driver


MSC

Recommended Posts

This is brilliant, thank you so much MSC for your hard work. I'm using a UK (British) layout K70, and found that there were problems with two of the keys not working: # and \. I believe the former is not a dedicated key on US keyboards, and the latter is in a different place and has a different second symbol.

 

I've written a patch for this that seems to work well for me (Ubuntu 14.04) and submitted a pull request to merge this into your main branch. Hope it looks OK to you! If anyone's desperate for it, you can get my fork of the code here: https://github.com/bmerrison/ckb. You need to replace -DKEYMAP_DEFAULT with -DKEYMAP_UK on lines 15 and 16 of Makefile and then recompile in order to get the UK key map.

 

I'm also working on a little utility built on top of this driver to allow lighting patterns to be scripted in Python. It's pretty much just for my personal use, but I'll stick it up on GitHub and post a link here when it's working anyway...

Link to comment
Share on other sites

  • Replies 824
  • Created
  • Last Reply

Top Posters In This Topic

Nice work, the new layout seems to work just fine. I've added it back to the main repository.

 

I also did a rewrite of the OSX code today so it no longer requires libusb. It's a lot less buggy now and more importantly, key rebinding works. I think I'm going to drop libusb from the Linux version as well, because it seems to be causing some problems and it doesn't play well with mutlithreading.

Link to comment
Share on other sites

Wow this is absolutely amazing! Thanks MSC! I thought this keyboard wouldn't be properly usable on a Mac, I'm glad you stepped in to make it work!

 

I'm curious how exactly this works, I've perused the code a little bit, but not enough yet to really grasp it. It looks like you're effectively making your own keyboard driver, that handles all the keyboard input? I assume that's why the system's modifier key rebinding doesn't work?

 

Also I noticed on the earlier version, the one using libusb at least, that my computer's screen would dim, and it would go to sleep, even while I was actively typing on the keyboard. I haven't messed around with the new non-libusb one enough to try to reproduce this, but I'm wondering if you've noticed something similar?

 

I'm unfortunately not very well versed in c, but if there's anything I can do to help, testing-wise, I'd be glad to!

Link to comment
Share on other sites

Correct. The keyboard hardware provides an option to use two different input interfaces, one of which is compatible with the standard input driver (IN_HID in my code) and the other of which is a proprietary input (IN_CORSAIR). The windows driver actually uses both of them if the keys aren't rebound, but I found it worked better to use only the proprietary input and handle all key events within the daemon. But yeah, it means that OSX's built-in modifier remapping doesn't work, since that only serves the system driver.

 

I didn't notice any issues with screen dimming. But I use my mouse almost constantly, so I imagine that cancels it. Let me know if you run into it again and I'll see if there's anything I can do to stop it. At this point the most helpful thing you can do is just keep testing it; I'm still having some trouble getting the device to behave consistently so feedback about anything that does or doesn't work is extremely helpful. :)

 

By the way, for Linux users: I did what I mentioned earlier and stopped using libusb, so now it just runs with udev and usbfs. The dependencies are different, so check your package manager for "libudev" or "libudev-dev" if it doesn't compile anymore. The driver seems to be a little bit more stable now, at least on my machine. Hopefully the change doesn't make it blow up for anyone.

Link to comment
Share on other sites

Are you running "echo rgb off > /dev/input/ckb1/cmd" ? If you were writing to ckb0 or didn't use that exact path, the command won't do anything. If you run the ckb program with an animation (like "bin/ckb ripple white blue") does that work? If so, you should be able to turn it off with "bin/ckb solid black" as well.
Link to comment
Share on other sites

Are you running "echo rgb off > /dev/input/ckb1/cmd" ? If you were writing to ckb0 or didn't use that exact path, the command won't do anything. If you run the ckb program with an animation (like "bin/ckb ripple white blue") does that work? If so, you should be able to turn it off with "bin/ckb solid black" as well.

 

 

 

Yes it works but the problem is, once i start the ripple effect i need to CTRL+C it to stop it and then i can change the colors.

but yeh i didnt know of the command "echo rgb off > /dev/input/ckb1/cmd", thanks that works now

 

Lovely program thanks

Link to comment
Share on other sites

By the way, for Linux users: I did what I mentioned earlier and stopped using libusb, so now it just runs with udev and usbfs. The dependencies are different, so check your package manager for "libudev" or "libudev-dev" if it doesn't compile anymore. The driver seems to be a little bit more stable now, at least on my machine. Hopefully the change doesn't make it blow up for anyone.

 

Still seems to be working fine, no noticeable difference for me.

 

Still getting the strange issue where F keys seem to have weird mappings after i kill the daemon and restart it.

Maybe you have noticed this as well, but if you kill the daemon the keyboard still works fine. F key bindings are also correct.

But as soon as you restart the driver without unplugging the keyboard and plugging it back in, the F keys are always messed up.

 

Certainly not a massive issue though.

 

Appreciate the work as always :biggrin:

Link to comment
Share on other sites

Yes it works but the problem is, once i start the ripple effect i need to CTRL+C it to stop it and then i can change the colors.

but yeh i didnt know of the command "echo rgb off > /dev/input/ckb1/cmd", thanks that works now

 

Lovely program thanks

 

Glad you got it working :D

You do have to stop ckb and restart it in order to change the animation, that's a limitation of the current version. I'm going to start work on a better utility very soon so you won't have to do that anymore.

 

Still seems to be working fine, no noticeable difference for me.

 

Still getting the strange issue where F keys seem to have weird mappings after i kill the daemon and restart it.

Maybe you have noticed this as well, but if you kill the daemon the keyboard still works fine. F key bindings are also correct.

But as soon as you restart the driver without unplugging the keyboard and plugging it back in, the F keys are always messed up.

 

Certainly not a massive issue though.

 

Appreciate the work as always :biggrin:

 

Yeah, I haven't had that problem exactly but I definitely run into strange behavior after closing the daemon. I've tried everything I can think of, including doing a USB reset after releasing the device, so I'm giving up on this issue. I think there's something particular about the Linux kernel driver that the keyboard doesn't like (the problem doesn't occur on OSX), and if that's the case I probably can't do anything about it. Won't be a big deal for long, since my goal is to have the daemon run in the background and never need to be restarted. Thanks for the feedback anyway :)

Link to comment
Share on other sites

Yeah, I haven't had that problem exactly but I definitely run into strange behavior after closing the daemon. I've tried everything I can think of, including doing a USB reset after releasing the device, so I'm giving up on this issue. I think there's something particular about the Linux kernel driver that the keyboard doesn't like (the problem doesn't occur on OSX), and if that's the case I probably can't do anything about it. Won't be a big deal for long, since my goal is to have the daemon run in the background and never need to be restarted. Thanks for the feedback anyway :)

 

No worries, maybe the next firmware update from corsair will help. :)

 

Just out of curiosity, would it be possible to bind the M1,M2 and M3 keys to the different profiles stored on the keyboard?

Link to comment
Share on other sites

Yes, but indirectly. I added an ability to generate a notification when a keypress occurs. My plan for it is to have a (much better) ckb utility store all the profiles/modes as user settings, including animations and other effects. So the ckb utility will tell the daemon to print a notification whenever an M-key is pressed, and then as soon as it receives that notification it switches modes. There are one or two things left that I need to implement in the daemon (mostly the ability to print out the RGB settings from the hardware) but I'll get started on the new user utility in the next 2-3 days.
Link to comment
Share on other sites

Hi there,

 

great to see someone working on the Linux drivers! Did I understand it correctly, that this keyboard gets unresponsive on a vanilla Linux install, as soon as you press a special / macro key?

 

Also, for the Linux support, have you taken a look at hidraw (kernel module)? It passes raw HID events directly to userspace - they don't get processed in contrast to hiddev. You wouldn't need to de-attach the keyboard from the hid-generic kernel module, so general stuff can still be done using it. You can talk to the keyboard via HID feature requests.

 

Keep up the great work!

 

Cheers,

Tolga

Link to comment
Share on other sites

MSC, congratulations on writing this driver! It is working very good on my K70 and I very much appreciate it. If you have need for any K70 testing pm me.

 

So the last week little by little i have been writing a new lighting effect, and now that its complete i'd like show it to you guys and ask for oppinions. The effect is called Life and its based on a evloutionary cell game called Conways Game of Life.

 

[ame=https://www.youtube.com/watch?v=_NbPGT8dI94&feature=youtu.be]Short Youtbe demo[/ame]

 

The idea was to create an effect much like MSC-s random effect, that will always change the lighting to something different and interesting, but won't be too flashy so that it draws your attention off the screen. I have also made it interactive so that each key (cell) you press comes to life and then interacts with its environment (surrounding keys) and continues the cycle of life.

When the effect is run, life is generated randomly and lives on for 30-60 sec, and then it dies out (except for still life, wiki it). After that every live cell and any interactions between them are the direct result of your typing, so it is a interactive lighting effect with its own little game running with rules and so on. If youre interested read the wiki.

It is not very flashy and fabolous as most of the windows effects, but that was exactly the intention so that its pretty and interesting for everyday use and not showcasing 16m colours to friends.

 

The effect is only beta now. I have integrated it into MSCs ckb program as one of the available effect so that , if he doesnt mind, he can include it in his future releases. I have forked it so you can compile it and try out, and i would like to hear your opinions on it.

 

There is only one problem with the effect right now and that is the key press reader. Since MSC hasnt integrated a keypress reader API or smthing like it i have written a function that will read directly from the input files, on my ubuntu located on /dev/input/event0-9. The program probes these files if they are keyboard input files, and if they are starts reading from them. I have no idea how that will function on other linux systems, let alone mac, so feel fre to post your problems and lets hope that MSC will make a real system for this and not this junk that i use for reading.

 

EDIT: I just saw that you included some keypress notifications in the last release, i will check tomorrow if i can use them for keypres reports.

 

I added another video demonstrating two oscilators and two forms of still life, since the initial video is pretty boring.

[ame=https://www.youtube.com/watch?v=B0g1JljwJNw&feature=youtu.be]Video 2[/ame]

Edited by The_Jolly_Roger
Link to comment
Share on other sites

Dude, that's brilliant. Love it!

 

I had an idea, once I write a better user-level utility, to have a setting where it can get the animation data by running a custom program. So it would write something to the program's stdin pipe every time it wants a frame (or could be configured to write on keypress), and it would get the RGB data from the stdout pipe, or something like that. Any thoughts on that? Should be a lot easier than reading the event device directly. I'd love to include this one if you don't mind.

 

Hi there,

 

great to see someone working on the Linux drivers! Did I understand it correctly, that this keyboard gets unresponsive on a vanilla Linux install, as soon as you press a special / macro key?

 

Also, for the Linux support, have you taken a look at hidraw (kernel module)? It passes raw HID events directly to userspace - they don't get processed in contrast to hiddev. You wouldn't need to de-attach the keyboard from the hid-generic kernel module, so general stuff can still be done using it. You can talk to the keyboard via HID feature requests.

 

Keep up the great work!

 

Cheers,

Tolga

 

Correct, the keyboard will freeze with the standard HID driver when you press one of the rebindable keys. Reason being the keyboard tries to send a nonstandard USB interrupt-in transfer and the Linux HID won't acknowledge it, so the keyboard's CPU blocks waiting for the transfer to complete (which it never will). The reason why I have ckb detach the kernel driver is partly because of that, and partly because even the standard HID input just plain doesn't work for me ~50% of the time. I think a couple of other people have the same problem. It isn't worth the effort IMO to figure out why exactly it doesn't like the Linux HID or how to make them work together, so I found it simpler to detach the driver completely.

 

Incidentally, OSX doesn't have this issue (in fact, I do make use of OSX's native HID driver), so it's definitely operating system specific. Even weirder is the fact that it's usually not enough just to detach the driver; the keyboard often requires 1-3 USB resets *after* claiming the device before normal communication can occur. It's not every time, though, just most of the time. It's a very strange firmware issue and, like I said, I don't think it's worth the time to debug. I'll definitely look into using hidraw if the firmware is ever fixed, though.

Link to comment
Share on other sites

First, thank you so much for the work you have done with this! I know how to use the ckb application to change lighting and etc, but how do we work in reactive lighting? I would just like to accomplish something as simple as when you press a key, it goes white, then fades back to off or some other color. Any help would be appreciated! Thanks again!

 

Edit: I also just noticed that when I run ckb and have it set to a wave, then try to type fast (even just hitting the backspace key to delete a sentence or two) it drops keys like crazy and only sends keypresses at ~5 times a second even if I'm hitting the key at least twice that speed.

Edited by CorpNewt
Link to comment
Share on other sites

Reactive lighting is coming soon. I haven't experienced any issues with dropped keys. Is this happening on Linux or on OSX? Do you have the rate switch on your keyboard set to 1ms? If it's caused by animations, you might try starting ckb-daemon with "sudo bin/ckb-daemon --fps=30" to see if that fixes it. I don't think the animations can interfere with the input anymore, but there might be something happening at a hardware level too. I'll take another look at the code and see if there's anything else I can do to improve it.
Link to comment
Share on other sites

Hmm, alright. I haven't had any problems with the animations under OSX, but let me know what you find. One other question: have you plugged this keyboard into a Windows PC to do a firmware update? The keyboards don't ship with the latest firmware AFAIK. I'm considering adding a firmware update to ckb in case the older firmware has more bugs, but if you've already updated it then that wouldn't be the issue.
Link to comment
Share on other sites

I just got back from work so I will try and switch the fps on the mac side. I dual boot windows and Mac OSX. I am running the latest firmware (1.15). I will let you know what I find out tonight. Thanks again for your help.

 

Edit: I just tried it with --fps=30 and that seems to have cleared up the issue.

Edited by CorpNewt
Link to comment
Share on other sites

Interesting, didn't realize that would cause problems. I'll make a note of that.

 

I finally got a Qt-based UI started. Build instructions are completely different now, so check the readme again. It's not much of an improvement over the old command-line utility, but it does offer the ability to adjust colors and framerate on the fly and it can run in the background without having to keep a terminal open. I'll make an install script for the daemon soon so that you won't have to run it separately.

Link to comment
Share on other sites

Bit of an update from me, loving the gui so far.

The ability to select colours / patterns and adjust a range of settings is just great. Better yet is the ability to use the brightness button.

Words cant express how happy i am that brightness is now working. Thank you very much :)

Storing profiles and writing them to the hardware seems to work fine as well.

 

One thing though, the changes you made to ckb-daemon in commit 11ec0b3, stopped the daemon working for me. I ended up checking out commit b37a519, which resolves the issue.

 

ckb-daemon output

ckb Corsair Keyboard RGB driver v0.0.3
Setting FPS to 60
Setting default layout: us
Root controller ready at /dev/input/ckb0
Connecting Corsair K95 RGB Gaming Keyboard (S/N: 0701B03EAE3618E3530D5E92F5001946)

 

The program halts here, and the following is spammed in dmesg

[ 1754.114238] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
[ 1754.170184] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
[ 1754.226127] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
[ 1754.282073] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
[ 1754.289059] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110

 

Guessing this might have something to do with the changes to usb.c?? could be wrong though.

 

I ended up cherry-picking the two later commits after 11ec0b3, fixed a merge conflict in usb.c where i pretty much removed anything that could set fail to 1 in the setupusb method and now the keyboard connects, and it connects much faster than it use to.

 

Not exactly sure why this works, but maybe you might see something.

 

Thanks again :)

Edited by SpeedFreak01
Link to comment
Share on other sites

Hmm. So it doesn't work for you if you use the latest version unmodified, but if you revert to a commit before 11ec0b3 or comment out the failure code, then it does?

 

I do remember 11ec0b3 specifically having problems, so double-check to make sure it hasn't been fixed since then. I'll add some more debug info to help pinpoint where it's happening. strerror says that 110 is "Connection timed out" but it sounds like the messages are reaching the keyboard anyway? Maybe it would be better to ignore that error. You could test this by changing

usb_linux.c:16

   int res = ioctl(kb->handle, USBDEVFS_CONTROL, &transfer);
   if(res <= 0)
       return 0;
   // Rotate queue
   uchar* first = kb->queue[0];

 

to:

usb_linux.c:16

   int res = ioctl(kb->handle, USBDEVFS_CONTROL, &transfer);
   if(res == -110)
       res = MSG_SIZE;
   if(res <= 0)
       return 0;
   // Rotate queue
   uchar* first = kb->queue[0];

 

I'll put up a new version of the daemon tomorrow night with some more debugging info, so check back then and hopefully we can get this sorted out :)

Link to comment
Share on other sites

To confirm, doesn't work on the latest commit cbd0981. unmodified.

Only works consistently on commit b37a519 unmodified.

(https://github.com/ccMSC/ckb/commit/b37a519d05648d1293353ffd364fb1911319cbc8)

 

I tried changing the code as you suggested, but didn't see anything different in the standard output, or in the dmesg logs.

Still get the constant spam as mentioned before in the dmesg logs.

 

Will wait for another update.

Link to comment
Share on other sites

Ok, the new daemon code is up. If I'm understanding your problem correctly, you should now see warning messages spammed to the daemon output, but it should work regardless. If it doesn't work then paste the warnings and I'll see if I can make anything of it.

 

I put up two commits which are identical except for some minor timing differences. If 63ab888 (the newest) doesn't work then check 9c28b21 (the one before it) instead. I notice that 11ec0b3 has some long delays which weren't present in b37a519, so I shortened them in the latest commit. That's the only substantial difference I can find so hopefully one of these fixes it for you.

 

Edit: Ok, after playing around with it a bit more I put up one more commit, 2ed0e96. It seems like the best solution is just to reset the board repeatedly sometimes. You might want to try out all three commits and let me know which one works best, if at all.

Edited by MSC
Link to comment
Share on other sites

Testing again, thanks for being patient :)

 

(To note, i didn't unplug the keyboard before testing the latest revision, was running commit b37a519 at the time)

This time i checked out the latest revision (63ab888), compiled the code, copied the daemon as root to /usr/local/bin. Ran the daemon as root, keyboard connected with no issues.

 

ckb Corsair Keyboard RGB driver v0.0.6
Setting FPS to 60
Setting default layout: us
Root controller ready at /dev/input/ckb0
Connecting Corsair K95 RGB Gaming Keyboard (S/N: 0701B03EAE3618E3530D5E92F5001946)
Device ready at /dev/input/ckb1
^C
Caught signal 2
Disconnecting Corsair K95 RGB Gaming Keyboard (S/N: 0701B03EAE3618E3530D5E92F5001946)
Removed device path /dev/input/ckb1
Removed device path /dev/input/ckb0

 

I then killed the daemon as you can see above, and unplugged the keyboard.

 

Gave the keyboard about 30 seconds of being unplugged before re-connecting it.

Ran the daemon again, and this time it failed to connect.

 

Logs:

ckb Corsair Keyboard RGB driver v0.0.6
Setting FPS to 60
Setting default layout: us
Root controller ready at /dev/input/ckb0
Connecting Corsair K95 RGB Gaming Keyboard (S/N: 0701B03EAE3618E3530D5E92F5001946)
Error: usbdequeue (firmware.c:24): Operation not permitted
Error: usbdequeue (usb.c:71): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
^C
Caught signal 2
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (main.c:25): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (main.c:31): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (usb.c:80): Operation not permitted
Error: usbdequeue (main.c:41): Operation not permitted
Disconnecting Corsair K95 RGB Gaming Keyboard (S/N: 0701B03EAE3618E3530D5E92F5001946)
Error: usbdequeue (usb.c:80): Operation not permitted
Removed device path /dev/input/ckb1
Removed device path /dev/input/ckb0

 

Nov 26 16:23:31: [79798.615213] usb 8-1: USB disconnect, device number 8
Nov 26 16:23:32: [79798.890762] usb 8-1: new full-speed USB device number 9 using uhci_hcd
Nov 26 16:23:32: [79799.563990] usb 8-1: New USB device found, idVendor=1b1c, idProduct=1b11
Nov 26 16:23:32: [79799.563995] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 26 16:23:32: [79799.563999] usb 8-1: Product: Corsair K95 RGB Gaming Keyboard
Nov 26 16:23:32: [79799.564001] usb 8-1: Manufacturer: Corsair
Nov 26 16:23:32: [79799.564004] usb 8-1: SerialNumber: 0701B03EAE3618E3530D5E92F5001946
Nov 26 16:23:32: [79799.773081] input: Corsair Corsair K95 RGB Gaming Keyboard as /devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/0003:1B1C:1B11.000E/input/input40
Nov 26 16:23:32: [79799.773385] hid-generic 0003:1B1C:1B11.000E: input,hidraw4: USB HID v1.11 Keyboard [Corsair Corsair K95 RGB Gaming Keyboard] on usb-0000:00:1d.2-1/input0
Nov 26 16:24:07: [79834.735410] usbhid 8-1:1.1: can't add hid device: -110
Nov 26 16:24:07: [79834.735433] usbhid: probe of 8-1:1.1 failed with error -110
Nov 26 16:24:42: [79869.700022] usbhid 8-1:1.2: can't add hid device: -110
Nov 26 16:24:42: [79869.700045] usbhid: probe of 8-1:1.2 failed with error -110
Nov 26 16:25:17: [79904.664643] usbhid 8-1:1.3: can't add hid device: -110
Nov 26 16:25:17: [79904.664665] usbhid: probe of 8-1:1.3 failed with error -110
Nov 26 16:25:17: [79904.743760] usb 8-1: Process 24781 (ckb-daemon) called USBDEVFS_CLEAR_HALT for active endpoint 0x81
Nov 26 16:25:32: [79919.729800] input: ckb1 as /devices/virtual/input/input41
Nov 26 16:25:33: [79920.228872] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 1 ret -110
Nov 26 16:25:33: [79920.379770] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:33: [79920.531604] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:33: [79920.683444] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79920.743369] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79920.803368] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79920.863221] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79920.923160] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79920.983159] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79920.803368] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79920.863221] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79920.923160] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79920.983159] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.043036] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.103059] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.162969] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.222910] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.282868] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.342774] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.406673] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.466690] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.526590] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.586537] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.646505] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:34: [79921.706387] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79921.766406] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79921.826350] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79921.886242] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79921.946200] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.010149] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.070008] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.130014] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.189874] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.249904] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.309814] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.369786] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.429767] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.489642] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.549589] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.609527] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.669460] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:35: [79922.729403] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79922.789335] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79922.849367] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79922.909209] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79922.969134] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79923.029034] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79923.089047] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79923.148963] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79923.208898] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79923.268837] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79923.328820] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79923.388731] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79923.448660] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:25:36: [79923.508573] usb 8-1: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110

 

Checked out 9c28b21, did the same thing. Tried running the daemon without unplugging the keyboard first, still didn't work.

Unplugged the keyboard and tested again, still no luck, same above logs.

 

 

Edit: Noticed the latest commit whilst typing / testing all this, checked out cbd0981 and i think we have a winner! :)

 

Didnt unplug the keyboard after the testing on 9c28b21. Ran the new daemon and instantly the keyboard came back up. Logs incase you're interested..

 

ckb Corsair Keyboard RGB driver v0.0.6
Setting FPS to 60
Setting default layout: us
Root controller ready at /dev/input/ckb0
Connecting Corsair K95 RGB Gaming Keyboard (S/N: 0701B03EAE3618E3530D5E92F5001946)
Error: usbdequeue (firmware.c:23): Operation not permitted
Error: usbdequeue (usb.c:71): Operation not permitted
Error: usbdequeue (usb.c:79): Operation not permitted
Error: usbdequeue (profile.c:249): Operation not permitted
Failed to set up device, trying to reset...
Reset success
Device ready at /dev/input/ckb1

 

Nov 26 16:57:17: [81821.862265] usbhid 8-2:1.1: can't add hid device: -110
Nov 26 16:57:17: [81821.862282] usbhid: probe of 8-2:1.1 failed with error -110
Nov 26 16:57:17: [81821.862368] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:59:20: [81944.736254] usb 8-2: Process 25301 (ckb-daemon) called USBDEVFS_CLEAR_HALT for active endpoint 0x81
Nov 26 16:59:25: [81949.732865] usb 8-2: Process 25301 (ckb-daemon) called USBDEVFS_CLEAR_HALT for active endpoint 0x82
Nov 26 16:59:30: [81954.727797] usb 8-2: Process 25301 (ckb-daemon) called USBDEVFS_CLEAR_HALT for active endpoint 0x83
Nov 26 16:59:35: [81959.723128] input: ckb1 as /devices/virtual/input/input47
Nov 26 16:59:35: [81960.222299] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 1 ret -110
Nov 26 16:59:35: [81960.273167] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:59:35: [81960.425147] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:59:35: [81960.481008] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:59:35: [81960.636858] usb 8-2: usbfs: USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
Nov 26 16:59:36: [81960.951975] usb 8-2: reset full-speed USB device number 11 using uhci_hcd

 

I unplugged the keyboard to try the driver from scratch again and everything worked fine!

 

So i suspect the issue is resolved for now, just needed some brute force love :P

 

Many thanks :)

Link to comment
Share on other sites


×
×
  • Create New...