(Unofficial) Linux / OSX Driver

[MSC]

Download + Source code:

https://github.com/ccMSC/ckb

 

Supported devices:

K65 RGB keyboard

K70 RGB and non-RGB keyboards

K95 RGB and non-RGB keyboards

Strafe RGB and non-RGB keyboards

M65 RGB mouse

Scimitar RGB mouse

The "Gaming" and "Vengeance" models are both supported.

 

Supported operating systems:

Linux (Ubuntu, Mint, etc)

Mac OS X v10.9 - v10.11 (Mavericks, Yosemite, El Capitan)

 

Currently SUPPORTED features:

RGB lighting and animations

Reactive lighting

Key rebinding (with a limited number of special functions)

K95 G-key support

Multiple independent binding and lighting modes

Customizable mouse DPI

 

Currently UNSUPPORTED features:

Advanced key macros

Importing and exporting of profiles (including CUE profiles)

 

 

-----------------------------

 

 

Update 2015/01/08:

New video showing off some of the more advanced animation development.

 

[ame]

[/ame]

 

Original post:

Here's a short sample video:

[ame]

[/ame]

 

I'm building a driver for the RGB keyboards so that us Linux users don't miss out on the cool features. Many thanks to CalcProgrammer1 and others (link to his thread here) for decoding the LED messages - wouldn't have gotten this far without them. I really liked the music visualizer and wanted to restructure it into more of a generic driver, so here's my attempt. :biggrin:

 

It's very incomplete at the moment, needs more fine-tuning and it's still missing major features like key rebinding or the use of the G-keys, but if anyone else out there uses one of these keyboards with Linux I'd love some testing/feedback. It *should* work with the K70 as well as the K95, although I only have a K95 so I can't test the former. Might be possible to run it under OSX as well. I'll keep the GitHub posted as I make progress.

Edited November 11, 2015 by MSC
Updated support list

[CalcProgrammer1]

Nice work! I like the daemon idea. Can you write LED patterns directly to the dev node? If so, programs like my music visualizer could write to that rather than handling the USB connection directly.

[Corsair James]

This is impressive - how long did it take you to create this driver?

[SpeedFreak01]

Thanks for the work MSC, when i can get my RGB K95 to work correctly under linux i will do more testing and offer some feedback.

[MSC]

Thanks. I'm still trying to figure out these mysterious G-keys...there doesn't seem to be any special response to them. I really hope this isn't going to require a custom kernel driver.

EDIT: Scratch that, I just figured it out!

 

Nice work! I like the daemon idea. Can you write LED patterns directly to the dev node? If so, programs like my music visualizer could write to that rather than handling the USB connection directly.

 

Yep! You can see this in action in the animation demo - it basically just builds up a string of key/color combinations and sends that to the device. You should be able to implement the visualizer in the same way.

 

This is impressive - how long did it take you to create this driver?

 

Couple of days. I got the keyboard in on Friday and started working on it once I realized it didn't work on Linux. Having the LED messages already decoded was a big help.

Edited October 29, 2014 by MSC

[SpeedFreak01]

Ok, now that i have basic typing functionality back with the keyboard, time to test this driver :P

 

Unfortunately i haven't had much luck with this either, keeps throwing the error "Failed to get device info"

 

root @ # ckb-daemon
ckb Corsair Keyboard RGB driver v0.1
Root controller ready at /dev/input/ckb0
Detected K95 keyboard
Failed to get device info

 

Is there any info i can provide that might help with debugging that?

[galen104]

I have the same issue (with arch linux) but with a K70 RGB

 

I have set the BIOS switch to 8ms and now it works.

Edited October 29, 2014 by galen104
solved

[MSC]

Interesting...that's been happening to me sometimes, but so far I've been able to fix it by unplugging the keyboard and plugging it back in. Have you tried using a different USB port? If you're able, can you test it on Windows just to make sure it's working correctly there?

 

For right now, PM me the output of "dmseg | tail -100" when you see the error and I'll see if I can make anything of it. I'll try to implement better debugging soon.

[SpeedFreak01]

Will try unplugging it again when i get home later today. But the only real messages im seeing are

 

usbhid 5-2:1.1: can't add hid device: -110
usbhid: probe of 5-2:1.1 failed with error -110

 

The message pops up as soon as i run the daemon.

 

I really cant find much info on this error or what causes it.

Seems others indicate this might be a power supply issue to the device, or possibly a faulty device. Im hesitant to think its a problem with the USB ports given i have tested a range of other spare USB keyboards at home and all work instantly with no issues or errors.

 

Given a few people seem to be having the same issues, i suspect this has more to do with the k95 keyboard and dodgy firmware than anything.

 

The keyboard works fine in windows, although im testing that on a completely different PC.

I might be game to install windows on my linux box, but would rather not.

[MSC]

The firmware is definitely flakey, but I think it's the driver's fault in this case. I managed to reproduce your problem in a VM (same dmesg output as well). I just pushed a commit that, at least in my case, allows it to connect the device anyway. Unfortunately the LED controller still doesn't work when this happens. I'll keep working on it.

 

Edit: It seems the keyboard really hates the linux HID driver. I think the best route is to disable it entirely and implement all key binding in the custom driver, even when keys aren't reassigned.

Edited October 30, 2014 by MSC

[SpeedFreak01]

Well, pulled down the latest commit, managed to get a little further this time in the log output, but unfortunately the keyboard died again. All the lights are on, but it just doesn't accept any key presses.

 

Looks like the driver did a rest or something on the usb interface?

I haven't really had much luck getting this keyboard to consistently initialise in linux so its in no way your drivers fault.

 

Here are the logs, certainly seems like usbhid has issues with something.

 

[76655.903992] hid-generic 0003:1B1C:1B11.0001: usb_submit_urb(ctrl) failed: -1
[76657.068766] usb 5-2: reset full-speed USB device number 2 using uhci_hcd
[76657.991910] input: Corsair Corsair K95 RGB Gaming Keyboard as /devices/pci0000:00/0000:00:1a.2/usb5/5-2/5-2:1.0/0003:1B1C:1B11.0007/input/input20
[76657.992365] hid-generic 0003:1B1C:1B11.0007: input,hidraw0: USB HID v1.11 Keyboard [Corsair Corsair K95 RGB Gaming Keyboard] on usb-0000:00:1a.2-2/input0
[76692.957553] usbhid 5-2:1.1: can't add hid device: -110
[76692.957575] usbhid: probe of 5-2:1.1 failed with error -110
[76751.133606] usb 5-2: USB disconnect, device number 2
[76781.806411] usb 5-2: new full-speed USB device number 3 using uhci_hcd
[76782.479678] usb 5-2: New USB device found, idVendor=1b1c, idProduct=1b11
[76782.479683] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[76782.479687] usb 5-2: Product: Corsair K95 RGB Gaming Keyboard
[76782.479689] usb 5-2: Manufacturer: Corsair
[76782.479692] usb 5-2: SerialNumber: <removed>
[76782.688907] input: Corsair Corsair K95 RGB Gaming Keyboard as /devices/pci0000:00/0000:00:1a.2/usb5/5-2/5-2:1.0/0003:1B1C:1B11.0008/input/input21
[76782.689380] hid-generic 0003:1B1C:1B11.0008: input,hidraw0: USB HID v1.11 Keyboard [Corsair Corsair K95 RGB Gaming Keyboard] on usb-0000:00:1a.2-2/input0
[76817.656097] usbhid 5-2:1.1: can't add hid device: -110
[76817.656118] usbhid: probe of 5-2:1.1 failed with error -110
[76852.620736] usbhid 5-2:1.2: can't add hid device: -110
[76852.620758] usbhid: probe of 5-2:1.2 failed with error -110
[76887.584308] usbhid 5-2:1.3: can't add hid device: -110
[76887.584328] usbhid: probe of 5-2:1.3 failed with error -110

 

So.. back to square one, getting the keyboard to work again. are there any other alternatives to the default HID driver?

[MSC]

Nope. I'm in the process of rewriting the program to detach the stock HID driver entirely and handle all key input through the ckb daemon. It's a less elegant solution than I was hoping for, but I don't feel like debugging the USB keyboard module to figure out what's wrong with it.

 

It seems to be necessary (most of the time) to issue a USB reset to the device when activating it, and in fact the Windows driver appears to do 2 or 3 of them. But the device breaks again as soon as I try to reactivate the Linux driver. I have a SLIGHT suspicion this keyboard didn't get much compatibility testing... :rolleyes:

[SpeedFreak01]

Appreciate the work mate, you seem to be doing a hell of a lot more for the community than the actual devs, so top job.

 

Its really a shame, i think the keyboard has great potential but the firmware is just too buggy at the moment.

 

Thinking i might put the keyboard aside for now and wait for corsair to release more firmware updates.

Users are clearly unhappy with the device, and its abundantly clear there are issues with it, i guess its just a case of waiting for further revisions.

 

In the meantime will keep watching this thread, whenever you update this next will do some more testing.

[MSC]

Yeah, the firmware's pretty buggy. Thanks for your feedback regardless - it's been helpful.

 

I've pushed an update that disables the kernel driver and uses a custom input device. It seems to fix the keyboard not responding, but I don't know if you'll be as lucky. I don't think there's much else I can do if it still fails, so fingers crossed.

[Dwindleflip]

hire this person.

[SpeedFreak01]

MSC you're an absolute legend!.

 

I can now consistently get the keyboard to work using your driver.

 

Still a bit fiddly given the fact i need to have another keyboard on hand so i can start the driver etc, but its a dam sight better than the out of the box solution from corsair :P

 

Still a few bugs.. most of them you have listed on git already.

 

Some key combinations do odd things, for example alt+arrow keys.

Quite often I will use alt+left arrow key to quickly skip words in a terminal. At the moment that key combo produces a capital D.

 

Been having some fun playing around with lighting combinations.

Any idea if you can set the colour for the G keys?

 

Also getting way ahead of myself here.. what do you think the chances are of being able to write to the keyboards internal memory to enable profile switching with the M keys?

[MSC]

Nice! I tried pressing Alt+Left in a terminal and I get a capital D as well, but all of my other keyboards do the same thing. Do you have a non-US layout or any alternate key bindings? I'm working on key rebinding now, so once it's done you should be able to solve the problem that way if nothing else. After that I'll get started on a better control utility so that you can edit the colors/bindings easily.

 

Unfortunately CUE currently won't write hardware profiles (Corsair says they've disabled it due to firmware issues) so I won't be able to do anything with them until that functionality is added back. Once it is I'll certainly try to implement it.

[jacks0_0]

I'm trying to run make, but there is an error:

src/ckb-daemon/includes.h:8:10: fatal error: 'features.h' file not found

 

When will you release a MAC version? :)

[BillRathbone]

The latest CUE release re enables saving profiles to the device, btw.

[SpeedFreak01]

The latest CUE release re enables saving profiles to the device, btw.

 

Do you guys happen to have any documentation on how to push profiles to the device outside the CUE app?

[MSC]

I'm trying to run make, but there is an error:

src/ckb-daemon/includes.h:8:10: fatal error: 'features.h' file not found

 

When will you release a MAC version? :)

 

That's strange..what distro are you running? Can you post the output of "find /usr -name features.h" ?

 

I'm going to start working on a mac version soon. No promises yet since I'm not sure how many differences the OS has compared to linux, but I'll give it a shot sometime in the next week or two.

 

The latest CUE release re enables saving profiles to the device, btw.

 

Ah, so it does.

 

Do you guys happen to have any documentation on how to push profiles to the device outside the CUE app?

 

I took a quick look at the hardware save commands and they don't look too complicated (in fact, the RGB commands are exactly the same as the regular ones). I need to code the concept of profiles into the daemon first, but I should be able to implement this soon.

[SpeedFreak01]

I took a quick look at the hardware save commands and they don't look too complicated (in fact, the RGB commands are exactly the same as the regular ones). I need to code the concept of profiles into the daemon first, but I should be able to implement this soon.

 

Awesome, no rush on that, keyboard is working fine as is.

 

Haven't had a chance to play with the macro settings, will do that tonight.

 

Also noticed that the numlock and capslock lights work correctly now. Actually amazed given these lights didn't work correctly on windows for me.

 

The alt+left arrow combo to skip over words in a terminal seems to be working, not sure if its something you did or maybe i restarted my pc? Either way, no issues there.

 

One other thing i have noticed, and i really need to get more examples to explain it better, but it seems if i plug the keyboard in, start the driver everything works fine, all key mappings are correct.

However, if i kill the daemon and restart it, the key mappings on the keyboard seem to do some weird things, F keys will often produce odd characters etc.

To fix it i need to unplug the keyboard, plug it in again, and restart the daemon.

I honestly havent checked logs or anything to work out whats going on. So will leave it for now and if i can figure out a way to replicate the issues will post an update.

[swarfega]

Nice job with this. Linux is always being left out.

 

As one person said, hire this person or at least sponsor the project.

[MSC]

I'd be happy forever if Corsair officially endorsed this (nudge nudge ;). It's still not nearly complete, but I definitely think I'll be able to provide all of the same functionality as the Windows driver once I'm finished.

 

One other thing i have noticed, and i really need to get more examples to explain it better, but it seems if i plug the keyboard in, start the driver everything works fine, all key mappings are correct.

However, if i kill the daemon and restart it, the key mappings on the keyboard seem to do some weird things, F keys will often produce odd characters etc.

To fix it i need to unplug the keyboard, plug it in again, and restart the daemon.

I honestly havent checked logs or anything to work out whats going on. So will leave it for now and if i can figure out a way to replicate the issues will post an update.

 

I've had this issue as well, the daemon doesn't seem to shut down completely cleanly. Not sure yet if it's a hardware problem or if there's something I should be doing differently software-side.

 

I just spent an entire day hitting my head against the wall trying to figure out why the keyboard was reporting all three hardware profiles as having the same RGB settings, only to import them into CUE again and realize that the Windows driver has the exact same problem. Now I see why this was disabled. The save works fine, though, so there's at least that.

 

By the way, can anybody with a K70 test this (specifically the hwload and hwsave commands)? I know the K70 lacks the mode buttons, so I assume it's the same thing except with only one hardware mode, but I don't have a K70 so I can't confirm it.

 

I'm nearly done writing the daemon now, so after a few more revisions I'll move on to writing the user utility and you shouldn't have to recompile/restart it every time I make an update. I'll start testing out an OSX version in the next few days as well.

Edited November 5, 2014 by MSC

[MSC]

Hey everyone! Sorry for the double post, but I just added OSX support. You have to install libusb separately since OSX doesn't have it by default, but other than that it's just as easy as building the Linux driver.

 

Now the not so good news...the RGB controller works on OSX, but key rebinding doesn't. Apple's built-in driver grabs the device and refuses to let go. In order to stop it I would have to create a custom kernel driver, and Apple is now forcing all kernel drivers to be signed with a developer key. I'm not going to pay Apple $100 just so I can make a device ungrabber. It MAY be possible to bypass the driver anyway, but there's a good chance that key rebinding on OSX just isn't going to work.