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.

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.

Last edited by MSC; 11-11-2015 at 03:54 AM.
Reason: Updated support list

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!

Quote:

Originally Posted by 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.

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.

Quote:

Originally Posted by Corsair James

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.

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.

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.

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.

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.

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...

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.

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.