(Unofficial) Linux / OSX Driver

[Lauwenmark]

If you try to use the keyboard with the stock driver, the macro keys will cause it to freeze. Using ckb's driver will fix that.

I'm not using the macro keys. It freezes only when using the standard keys. It is also freezing when using the ckb driver.

 

Not sure about intermittent freezing issues, though. :\ If anything, they seem to be caused by abnormally high USB activity, but if you're not using animations then I don't see how that could apply. Maybe you could try turning the poll rate all the way up to 8ms, but I'm grasping at straws here.

I've tried setting the keyboard to its min. polling rate, and it didn't solve the issue.

[pastym]

I just installed the testing branch and it all seems to be working great except for the mouse's DPI. When the service is running the DPI drops to the lowest setting and the DPI buttons and sniper button stop working.

[ryanvn]

You probably have the wrong keyboard layout set in ckb - check "K70 RGB > Device > Layout" and set it to the physical layout of your keyboard (I'm guessing yours is United States, based on your description).

 

You were right, Thank you very much ^^

[MSC]

I'm not using the macro keys. It freezes only when using the standard keys. It is also freezing when using the ckb driver.

 

 

I've tried setting the keyboard to its min. polling rate, and it didn't solve the issue.

My comment about the macro keys was directed at petteyg359. I don't think there's anything else that will help you, unfortunately :\

 

I just installed the testing branch and it all seems to be working great except for the mouse's DPI. When the service is running the DPI drops to the lowest setting and the DPI buttons and sniper button stop working.

If you create a new mode it should enable the default DPI settings. It's still difficult to work with because there's no UI, though. I'm hoping to get it implemented within the next week.

[pizzly]

Updated to Kernel 3.16.0-38-generic, keyboard loads 99% of the time now :D:

[CorpNewt]

Using the latest master build, I've run into the issues of ckb-daemon hogging 50+% of the cpu at boot up and not being able to detect the keyboard until I unplug it, plug it back in, and then force quit ckb-daemon with Activity Monitor. I tried the latest testing build, but it disabled the use of my 10-key pad. I couldn't find any settings pertaining to that, and tried a clean install. Any ideas?

[MSC]

Should still be working...it might be due to a missing key bit or one of several changes I've made to the input system. I'm looking into it.

 

Sorry if I haven't had much time to deal with bug reports lately, I haven't had as much time for the project as I'd have liked and I was busy implementing a major rework for better M65 support. I'll try to tackle them as soon as possible.

[MSC]

Ok, I reverted the only OSX input change between master and testing (at least that I know of). See if it's working again now.

[CorpNewt]

I'll download it and give it a run. Any idea what might be causing the daemon to hang when launched by the launchd service? I have to unplug-replug the keyboard to be able to type my password and then when I log in, go into activity monitor and force quit the ckb-daemon to allow it to restart, then everything seems to work without a hitch.

 

I will take a look at the new testing build and see if the same thing persists there. Don't worry about taking time with the bugs ;) You've already kicked more than enough *** on this project and even with a few potholes here and there I still prefer your driver on my mac side over the official drivers on my windows side. Thanks again for all your hard work and help!

 

Edit:

 

Okay, I installed the new testing version and I still need to unplug-replug forcequit to get the keyboard up and running, and I still have the issue of the number pad not working. I also checked out a bunch of other keys and it looks like the ones that do work are the standard a-z keys and the number keys above the qwerty row, the media keys also work. The ones that don't work are 10-key, backspace, enter, spacebar, punctuation keys (,./;'[]\), the delete, end, home, etc.

They don't type the keys, or perform any of the reactive animations so I'm guessing the daemon doesn't even see them getting pressed.

 

Hopefully that info helps! For the meantime, I'm just going to keep rocking the master build and do my usual unplug-replug dance. I might right a shell script that force-quits the ckb-daemon when I log in. I have also noticed that the daemon seems to hang and my startup times are like double-triple when the keyboard is plugged in.

Edited July 25, 2015 by CorpNewt

[kripple]

I came here to thank MSC. You da real MVP.

 

Any way I can get a full list of LED commands to pipe into /dev/ckb ?

 

I'm going to tie this into Sublime to throw colors from the linter and events ( like save) also tying into iTerm to throw red on error.

 

Thanks again MSC, very glad to donate to you. Great project. Great work.

 

If you ever find your way to Orlando let me buy you a beer.

[MSC]

I'll download it and give it a run. Any idea what might be causing the daemon to hang when launched by the launchd service? I have to unplug-replug the keyboard to be able to type my password and then when I log in, go into activity monitor and force quit the ckb-daemon to allow it to restart, then everything seems to work without a hitch.

 

I will take a look at the new testing build and see if the same thing persists there. Don't worry about taking time with the bugs ;) You've already kicked more than enough *** on this project and even with a few potholes here and there I still prefer your driver on my mac side over the official drivers on my windows side. Thanks again for all your hard work and help!

 

Edit:

 

Okay, I installed the new testing version and I still need to unplug-replug forcequit to get the keyboard up and running, and I still have the issue of the number pad not working. I also checked out a bunch of other keys and it looks like the ones that do work are the standard a-z keys and the number keys above the qwerty row, the media keys also work. The ones that don't work are 10-key, backspace, enter, spacebar, punctuation keys (,./;'[]\), the delete, end, home, etc.

They don't type the keys, or perform any of the reactive animations so I'm guessing the daemon doesn't even see them getting pressed.

 

Hopefully that info helps! For the meantime, I'm just going to keep rocking the master build and do my usual unplug-replug dance. I might right a shell script that force-quits the ckb-daemon when I log in. I have also noticed that the daemon seems to hang and my startup times are like double-triple when the keyboard is plugged in.

 

I think I know what the problem is but I need some info from your system. I made a branch to test it: https://github.com/ccMSC/ckb/tree/inputtest

 

After installing, stop the system service:

sudo launchctl unload /Library/LaunchDaemons/com.ckb.daemon.plist

 

Then run the driver:

sudo /Applications/ckb.app/Contents/Resources/ckb-daemon --nohwload

 

--nohwload is a new switch I introduced to make the driver skip hardware profile loading entirely. I may make it the default behavior since the process seems to be more trouble than it's worth.

 

Once running, this version should output a bunch of info each time you press a key. Press some of the ones that aren't working, then quit the daemon with Ctrl+C and paste the output here.

 

I came here to thank MSC. You da real MVP.

 

Any way I can get a full list of LED commands to pipe into /dev/ckb ?

 

I'm going to tie this into Sublime to throw colors from the linter and events ( like save) also tying into iTerm to throw red on error.

 

Thanks again MSC, very glad to donate to you. Great project. Great work.

 

If you ever find your way to Orlando let me buy you a beer.

Thanks :)

 

There's a list of daemon commands here: https://github.com/ccMSC/ckb/blob/master/DAEMON.md

 

Keep in mind that the LED commands don't work when the GUI is running as it will overwrite them. I'm working on a solution for that in a future version.

[Vortigern]

Hi there!

First of all I'd like to thanks MSC and all people that worked/are working to build Linux software for these keyboards: I'm really grateful!

 

I have some question about the K70/K95 and the daemon:

- is it possible to store on the on-board memory macro for the K70? (basically I'd just like to create macro and store them to K70 F-keys)

- a part from colours is there any difference between K70 and K70 RGB: talking about macros and functionalities (already know about Cherry MX switch differences).

- do I need the daemon to be up and running to use recorded macros (both K70 and K95) ?

- do I need to have the daemon running for using stored lighting profile (both K70 and K95)?

 

Thank you very much again!

[CorpNewt]

Hmm... I loaded up the daemon with the --nohwload and then pushed the num-pad and other keys that aren't responding and it doesn't do anything at all...

 

Chip-Mac:~ Chip$ sudo /Applications/ckb.app/contents/resources/ckb-daemon --nohwload

ckb: Corsair RGB driver beta-v0.1.5+t11

Hardware load disabled

Root controller ready at /var/run/ckb0

Connecting Corsair K70 RGB Gaming Keyboard (S/N: 0701503FAE3618E3530D5EE9F5001944)

Starting input thread for /var/run/ckb1

Corsair K70 RGB Gaming Keyboard ready at /var/run/ckb1

 

When I press the keys that do work, I get things like this:

 

Input 0x00 0x01 (0x15): 010100000000000000000000000000000000000000

RGB switch

kb: -2 (21)

kp: 0x003b, 1

Input 0x00 0x01 (0x15): 010000000000000000000000000000000000000000

RGB switch

kb: -2 (21)

kp: 0x003b, 0

 

Thanks for helping me troubleshoot this. It looks like the newer version of the driver just isn't catching anything from those keys.

[MSC]

Hi there!

First of all I'd like to thanks MSC and all people that worked/are working to build Linux software for these keyboards: I'm really grateful!

 

I have some question about the K70/K95 and the daemon:

- is it possible to store on the on-board memory macro for the K70? (basically I'd just like to create macro and store them to K70 F-keys)

- a part from colours is there any difference between K70 and K70 RGB: talking about macros and functionalities (already know about Cherry MX switch differences).

- do I need the daemon to be up and running to use recorded macros (both K70 and K95) ?

- do I need to have the daemon running for using stored lighting profile (both K70 and K95)?

 

Thank you very much again!

1. No, the device hardware doesn't store those settings.

2. As far as I know, the RGB lighting is the only difference. Keep in mind that the RGB version also supports software-controlled animations, whereas the non RGB version does not.

3. Yes.

4. The hardware can store the base lighting settings, but no animations. On the K95 you can store three lighting modes in the hardware (M1-M3). On the K70, only one.

 

Hmm... I loaded up the daemon with the --nohwload and then pushed the num-pad and other keys that aren't responding and it doesn't do anything at all...

 

Chip-Mac:~ Chip$ sudo /Applications/ckb.app/contents/resources/ckb-daemon --nohwload

ckb: Corsair RGB driver beta-v0.1.5+t11

Hardware load disabled

Root controller ready at /var/run/ckb0

Connecting Corsair K70 RGB Gaming Keyboard (S/N: 0701503FAE3618E3530D5EE9F5001944)

Starting input thread for /var/run/ckb1

Corsair K70 RGB Gaming Keyboard ready at /var/run/ckb1

 

When I press the keys that do work, I get things like this:

 

Input 0x00 0x01 (0x15): 010100000000000000000000000000000000000000

RGB switch

kb: -2 (21)

kp: 0x003b, 1

Input 0x00 0x01 (0x15): 010000000000000000000000000000000000000000

RGB switch

kb: -2 (21)

kp: 0x003b, 0

 

Thanks for helping me troubleshoot this. It looks like the newer version of the driver just isn't catching anything from those keys.

 

Well there goes my theory. It must be somewhere in the setup phase then. I'll let you know if I think of anything else.

 

EDIT: Actually, one other thing. I assume ckb (the GUI) is running when you do this? Can you try it again without the GUI running and see if the result is any different?

Alternatively, if you weren't running the GUI, try running it with the GUI active and see if that makes a difference.

Edited July 29, 2015 by MSC

[crazybear]

MSC, your great driver has been working like a charm now for months. Sometimes I had to just pull out the keyboard plugs and then put them back in...weird...but it solves most problem. However, I just ran into a new one that confounds me....

 

My OS 12.04 would not boot into GUI desktop at all. I had to use my 14.04 OS, which is not my primary at all. I'd tried most everything and was pulling my hair looking in all the wrong places. Instead of going to a desktop it would go into tty, but, stranger than that when I'd try to type into the tty, all I'd get are very strange 'characters' - non-Latin [such as diamond shapes or things that looked like Thai characters]. I finally figured out it was some interaction between the keyboard and the OS. I also found out I could unplug the keyboard and let it boot into the desktop, then replug in the keyboard....but one thing was still wrong. Caps lock was reversed...when 'on' it was off - when 'off' it was on....

 

Any suggestion what the fix would be? There is a program xdotool that will reverse the caps lock, but I'd rather not go that route unless I have to. Also, what might I have to do to not have to unplug the keyboard every time I turn on the machine.

 

Thanks much for all your hard work.

[MSC]

It sounds like the problem is somewhere between when the computer starts up and when the driver loads - unfortunately, I don't know of any good solution for this. The caps lock problem could probably be solved by pressing caps lock once before you unplug the keyboard. Not 100% sure.

 

In other news, I've released beta v0.1.6 today to provide compatibility with the latest v1.30 firmware. If you're using Linux, this upgrade is REQUIRED in order to continue using the keyboard properly with the new firmware. On OSX it is optional - actually, the OSX version hasn't changed at all since v0.1.5.

 

v0.2.0, which will bring M65 support, is still a few weeks out.

[crazybear]

Where is this new firmware available? I don't see it on the Corsair site. Thanks.

[MSC]

Actually, don't update it right now - I'm still sorting out some problems. Will post status when it's working properly.

[crazybear]

Actually, don't update it right now - I'm still sorting out some problems. Will post status when it's working properly.

 

I find I have to re-install every time I boot up for the Corsair K95 to work at all - some times I have to install twice once after the other. One time it installed the ckb, but not the daemon [in 14.04]. Will it be long [should I find an older copy and install that] or will this likely be fixed soon? Thanks

[Keridos]

2 Questions: Does this have a GUI?

And are we able to import macros and profiles from the CUE to also work on linux?

 

BTW: Corsair really annoyed me by stating that we can "store settings" on the board, but unlike most other keyboards AND Mice it actually does not store the per key lighting settings, the profiles and the macros on the keyboard itself so we cannot properly use all the features of the keyboard without CUE running (e.g. on Linux/Mac)

 

/edit: MSC, thanks for the driver, I sincerely hope that Corsair helps you on that one, paying 203€ for a keyboard that does not properly work on mac/linux is a bad joke.

Edited August 2, 2015 by Keridos

[Dygear]

Actually, don't update it right now - I'm still sorting out some problems. Will post status when it's working properly.

 

Now ya tell me. Good thing I had a spare keyboard next to me. I installed the drivers to get away from the boot time hang, that was making it last 30 seconds longer then it should be because the device registers it's self a 3 keyboards, none of them seem to want to play nice with the linux kernal. Anyway, I have to uninstall your drivers until support the new firmware. Thanks for the work on this, it's always nice to have access to all the features of the device under Linux. Hopefully Corsair hired you.

 

[edit]

Good news is, the grub usbhid.quirks fixed the slow system boot. I also uninstalled the driver for linux and can use the keyboard again without the keyboard animations. (and that's fine, because I don't really need the fancy stuff when I'm doing work in linux)

Edited August 4, 2015 by Dygear

[MSC]

2 Questions: Does this have a GUI?

And are we able to import macros and profiles from the CUE to also work on linux?

 

BTW: Corsair really annoyed me by stating that we can "store settings" on the board, but unlike most other keyboards AND Mice it actually does not store the per key lighting settings, the profiles and the macros on the keyboard itself so we cannot properly use all the features of the keyboard without CUE running (e.g. on Linux/Mac)

 

/edit: MSC, thanks for the driver, I sincerely hope that Corsair helps you on that one, paying 203€ for a keyboard that does not properly work on mac/linux is a bad joke.

1. Yes

2. Not at the moment. This is my most requested feature, it will definitely be done at some point.

 

Now ya tell me. Good thing I had a spare keyboard next to me. I installed the drivers to get away from the boot time hang, that was making it last 30 seconds longer then it should be because the device registers it's self a 3 keyboards, none of them seem to want to play nice with the linux kernal. Anyway, I have to uninstall your drivers until support the new firmware. Thanks for the work on this, it's always nice to have access to all the features of the device under Linux. Hopefully Corsair hired you.

 

[edit]

Good news is, the grub usbhid.quirks fixed the slow system boot. I also uninstalled the driver for linux and can use the keyboard again without the keyboard animations. (and that's fine, because I don't really need the fancy stuff when I'm doing work in linux)

Sorry :C

FWIW, the driver in the testing repo works for me with the latest firmware. But I'm receiving several different reports of the key input not working, and I'm not sure why, so I'm trying to sort that out before I actually release the new version.

[etrigan63]

I will let you know if this works with El Capitan.

[MSC]

v0.2 is released! It brings fixes for the latest firmware for Linux users (sorry about that) as well as the long-awaited M65 RGB support.

 

There's no cross-device lighting at this point, you have to use separate profiles for the keyboard and mouse. This will be added soon. I also plan to add other mouse-related options like the ability to share the DPI setting between modes. For now you get RGB lighting with all of ckb's standard animations, as well as full rebinding support. Let me know if there are any other features you'd like to see for the mice.

[sewer56lol]

I've just came here to say that I truly appreciate your efforts in showing love to this keyboard and the open source community, creating such an awesome open source software suite for us users and enthusiasts to enjoy, I'm in love with this. Support for other OS is something which realistically should've came out of the box, if Corsair has, or has had no intention of developing a driver for alternate OS they should at least give to the community and allow devs to go over walls, e.g. help implement profile support if possible since CUE is proprietary - but what was done here is truly great and exceptional, but I am glad that they are showing support, even in more indirect manner - especially by sticking this thread, but I've not been here for that long - so what could I know? *wink wink*

 

Edit:

Small issue report, low impact. Found program crash when you right click in the animations box in a space where there isn't an animation (empty space) under lighting. Distro info: http://i.imgur.com/U1MpRZ1.png

Edited August 8, 2015 by sewer56lol