(Unofficial) Linux / OSX Driver

I went back and read every page of this thread, and it looks like ckb does need to stay up and running in order for the animations to take place. I guess it isn't so bad, it does minimize to the tray and all. ;)

 

I'll take a look at the animation files to understand how they are written. I'd love to implement something where the user can use a .png and have the animation zoom/scroll/rotate/etc across the keys. If this is not possible or already in the works, let me know. :)

Love this, thanks so much, I've got this working fine on OSX 10.11 El Capitan with a K95 RGB keyboard

After updating to El Capitan the menu bar icon is missing... I can still click on the empty space to activate the drop down. Any idea how to fix it?

 

I have tried reinstalling.

 

http://i1083.photobucket.com/albums/j383/mhennessie/Screen%20Shot%202015-10-15%20at%2010.05.10%20PM_zpshrcyevqx.png

Possibly a Qt bug or a problem caused by using an older SDK. Should be fixed when I update the binary for v0.2.2.

 

Just purchased an M65 Vengence mouse and want to use the buttons etc via my Mac, I downloaded this software but it seems to be for if you are using the mouse via one of their keyboards ? I just want to use the mouse extra buttons via my Mac without all the flashing light keyboard attached.

 

Thanks.

I assume you have one of the non-RGB versions? Unfortunately they're not supported at the moment. The side buttons don't really work with OSX even with the RGB version, however. (A handful of apps recognize the back/forward actions, but most don't)

 

I went back and read every page of this thread, and it looks like ckb does need to stay up and running in order for the animations to take place. I guess it isn't so bad, it does minimize to the tray and all. ;)

 

I'll take a look at the animation files to understand how they are written. I'd love to implement something where the user can use a .png and have the animation zoom/scroll/rotate/etc across the keys. If this is not possible or already in the works, let me know. :)

 

No, but that's a pretty cool idea :) The animations are all C programs, it's a relatively straightforward API. Basically you just have to tell ckb which color to assign to each of the keys.

No, but that's a pretty cool idea :) The animations are all C programs, it's a relatively straightforward API. Basically you just have to tell ckb which color to assign to each of the keys.

 

I think I'll start simple... i haven't even looked at the animation files yet to see how you've implemented this. Do you assign colors on a per-key basis, or are the keys all mapped to an X,Y space with the actual key coordinates hardcoded into the driver/userland binary?

I think I'll start simple... i haven't even looked at the animation files yet to see how you've implemented this. Do you assign colors on a per-key basis, or are the keys all mapped to an X,Y space with the actual key coordinates hardcoded into the driver/userland binary?

 

A bit of both. The keys do have X/Y coordinates, which are sent to the animations when they start up. However, the color values are sent by name. What the built-in animations do is store the position map, then figure out what color to assign to each key based on its position.

Hi,

 

I have a Corsair K95 RGB with a French AZERTY layout. I set up a fresh Debian/Jessie installation. In the console, no problem - the keyboard is properly assigned the fr layout. But in X, it doesn't - instead, it is given a QWERTY/us one.

 

xorg configuration file: http://paste.ubuntu.com/12962664/

/etc/default/keyboard file: http://paste.ubuntu.com/12959295/

Xorg log file: http://paste.ubuntu.com/12959220/

udevadm info reports for the two /dev/input/eventX created for K95: http://paste.ubuntu.com/12959240/ and http://paste.ubuntu.com/12959257/ .

 

From the Xorg logfile, I can see that the keyboard event devices are indeed passed the option "xkb_layout=fr" (lines 217 and 241). Yet the keyboard is still in qwerty mode.

 

If I plug another keyboard instead of the K95, I get the proper "fr" mapping in X.

 

If I plug the K95 alongside another keyboard and start X, I get a qwerty layout on the K95. But if I then type even a single letter on the other keyboard, the K95 gets into an azerty layout. http://paste.ubuntu.com/12963232/ is the xev output from typing the "a" letter on the K95. The first entry is when I typed the letter before touching the other keyboard; the second is when I typed the same letter after touching the other keyboard.

 

I don't understand anything at all. This is obviously related to the K95 itself, as it doesn't happen with other keyboards. Installing the ckb driver presented here doesn't solve the issue. So what's going on? Anyone got an idea?

Keyboard layout should not be related to hardware (the keyboard does not know what is printed on its keys).

 

Some desktop session may change the layout from Xorg configuration (GNOME does it). What are you using? You should check those settings if they exist.

 

Check the output of "setxkbmap -query".

 

In /etc/default/keyboard, you use fr-latin9, in Xorg configuration, you use fr-oss. fr-latin9 is the one actually loaded according to the log. Although both are french AZERTY layouts and it should be related to your problem, you might want to fix this incoherency.

Keyboard layout should not be related to hardware (the keyboard does not know what is printed on its keys).

I do agree. Though the symptom suggests that for some reason, X is not applying the layout despite telling it is, and only does so with the K95, and not with any of the other 3 keyboards I tried, all on the same usb port.

 

Some desktop session may change the layout from Xorg configuration (GNOME does it). What are you using? You should check those settings if they exist.

True, but my problem happens even before any DE is loaded. Any connection manager that doesn't explicitely set a layout different from the default one selected by X (this is the case for xdm, slim and others by default) uses it. Same for twm or fvwm, or even more complex ones like kde without an explicit keyboard layout defined.

 

Check the output of "setxkbmap -query".

rules: evdev

model: pc105

layout: fr

variant: latin9

 

Yet qwerty is how the keyboard behaves!

 

In /etc/default/keyboard, you use fr-latin9, in Xorg configuration, you use fr-oss. fr-latin9 is the one actually loaded according to the log. Although both are french AZERTY layouts and it should be related to your problem, you might want to fix this incoherency.

You are riht. The oss is a leftover from the many config attempts and tests I made. This should and was normally "latin9". In any case, end result was the same.

Download + Source code:

https://github.com/ccMSC/ckb

 

Supported devices:

K65 RGB

K70 RGB and non-RGB

K95 RGB and non-RGB

M65 RGB mouse

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

 

Thank you so very much for doing this. It really sucked not being able to use 200$ keyboard in linux. Honnestly, corsair should hire you to give CUE a facelift. I know it's not complete yet but just from a useability and common sense in design point of view, your CKB software for running the k95 puts CUE to shame.

your CKB software for running the k95 puts CUE to shame.

 

This. It seems to be more and more common now; the community always seems to put out better software in the end. I'm still mucking around with the code, but I plan on forking the project and doing an animation with some pan/zoom/rotate features against a .png file. At the very least, the author gave me something to tinker with. :D:

 

I'm kinda curious about the keyboard now... a lot of the 32 bit ARM micros have built in USB hosts as well as Ethernet and a bunch of other peripherals. You might be able to hack one of these into a small remote net terminal with enough patience with coding and a soldering iron. :)

...Honnestly, corsair should hire you to give CUE a facelift. I know it's not complete yet but just from a useability and common sense in design point of view, your CKB software for running the k95 puts CUE to shame.

 

I kind of hope they DO NOT hire him! The first thing we'd lose is this Linux / Mac driver, then he'd likely be forced to work on the bloat-ware that is the corsair software, likely focusing on the "male teenager theme" that seems to be popular with so many hardware vendors. Rarely do they take an adult approach to design (usually because the ones with the final say have little to no design abilities).

 

Anyway, I'm just thrilled that community development is not swatted down by corsair. Keep up the great work!

 

And if you use ckb, and haven't already, toss the dude a fiver or something via the paypal donate link on the github page...

Edited October 29, 2015 by myrkat

I forgot to ask, MSC, have you thought about integrating the IdleKeys or something similar in ckb? Seems like a natural fit...

I finally found what was causing my mapping issue. There is a bug in current versions of Xorg preventing it to properly apply XkbLayout directives to keyboards recognized both as pointer and keyboard devices. This will thus happen to anyone using those keyboards with non-us layouts.

 

Upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=49950 .

 

The patch in the bug report ( https://bugs.freedesktop.org/attachment.cgi?id=95117 ) was tested and indeed solves the issue I had with my K95 RGB.

 

I suggest adding a reference to that patch in the ckb documentation, as this bug affects any non-us K95 Linux user (and I guess other Kxx keyboards are affected as well).

 

On debian-based (ubuntu, etc) distributions, here's how to rebuild Xorg packages solving the bug:

 

1. Download the patch mentioned above, and save it into a file (for example /tmp/xorg.patch);

2. Download the source package with:

apt-get source xserver-xorg-dev

This will create a subdirectory in your current directory. On my system, it was called "xorg-server-1.16.4/"

3. Move into that newly created directory:

cd xorg-server-1.16.4

4. Get build dependencies with:

apt-get build-dep xserver-xorg-dev

5. Apply the patch with:

patch -p1 < /tmp/xorg.patch

6. Install what's needed to rebuild the package:

sudo apt-get install build-essential fakeroot devscripts

7. Rebuild it:

debuild -b -uc -us

8. This will generate several packages on the upper directory level (cd ..). Install those you need, replacing those you had:

dpkg -i xserver-common*.deb xserver-xorg-core*.deb

(I only needed those two, but check if you don't use the others yourself !)

And restart your X server, or reboot your system if you prefer.

 

Hope this helps !

I have been having some weird issues with my K95 keyboard under arch. Every time I turn on or restart the computer it sits at a black screen until I either unplug the keyboard or switch it into BIOS mode. And even then this doesn't always work. Then after booting up I freeze at my login manager and nothing seems to work. Sometimes after playing with the BIOS switch everything will recover and then I can start typing and moving the mouse, and again this doesnt always solve the issue. The weird thing is that this weird functionality also seems to happen in grub and sometimes I cannot select any of my operating systems. Im sure that nothing is wrong with the keyboard because everything works fine in windows and with the windows bootloader. And whenever I use a different keyboard with arch I have no issues what so ever. I have tried re installing the driver multiple times but nothing seems to work.

I forgot to ask, MSC, have you thought about integrating the IdleKeys or something similar in ckb? Seems like a natural fit...

Yeah, this is planned for some point in the future. Can't give a timeline yet as it's pretty far down the backlog.

 

I finally found what was causing my mapping issue. There is a bug in current versions of Xorg preventing it to properly apply XkbLayout directives to keyboards recognized both as pointer and keyboard devices. This will thus happen to anyone using those keyboards with non-us layouts.

Interesting, thanks for that. I'll add a note in the Troubleshooting section.

 

I have been having some weird issues with my K95 keyboard under arch. Every time I turn on or restart the computer it sits at a black screen until I either unplug the keyboard or switch it into BIOS mode. And even then this doesn't always work. Then after booting up I freeze at my login manager and nothing seems to work. Sometimes after playing with the BIOS switch everything will recover and then I can start typing and moving the mouse, and again this doesnt always solve the issue. The weird thing is that this weird functionality also seems to happen in grub and sometimes I cannot select any of my operating systems. Im sure that nothing is wrong with the keyboard because everything works fine in windows and with the windows bootloader. And whenever I use a different keyboard with arch I have no issues what so ever. I have tried re installing the driver multiple times but nothing seems to work.

 

Have you tried updating your BIOS or moving the keyboard to a different USB port? It seems like some motherboards have this problem and, as far as I know, there's no consistent solution for it. Sorry :/

I have been having some weird issues with my K95 keyboard under arch. Every time I turn on or restart the computer it sits at a black screen until I either unplug the keyboard or switch it into BIOS mode. And even then this doesn't always work. Then after booting up I freeze at my login manager and nothing seems to work. Sometimes after playing with the BIOS switch everything will recover and then I can start typing and moving the mouse, and again this doesnt always solve the issue. The weird thing is that this weird functionality also seems to happen in grub and sometimes I cannot select any of my operating systems. Im sure that nothing is wrong with the keyboard because everything works fine in windows and with the windows bootloader. And whenever I use a different keyboard with arch I have no issues what so ever. I have tried re installing the driver multiple times but nothing seems to work.

That is not so much an issue with Arch (or any OS at that point), but rather your BIOS. I have an Asus Sabertooth Z87 mobo, with latest BIOS, etc. and I also see this. It really slows down booting up (either Windows or Linux).

 

I even bought a PCI USB card, hoping it was the USB chipset that Asus was using, but that, too, did not alleviate my issues. It kind of pisses me off that Corsair cannot stick to the standards for keyboards (even with a "BIOS Mode" toggle switch).

Have you tried updating your BIOS or moving the keyboard to a different USB port? It seems like some motherboards have this problem and, as far as I know, there's no consistent solution for it. Sorry :/

 

Yes I have tried other ports but it seems to happen regardless. I will update my BIOS and do some more playing around and see if anything changes.

 

Thanks

This might be a dumb question but if you hide the menu bar icon... how do you get it back?

This might be a dumb question but if you hide the menu bar icon... how do you get it back?

 

I couldn't figure this out either... I ended up reinstalling ckb in the end...

Re-launching the program will open the UI again. It should show up in your applications menu.

Recently bought Strafe RGB for my mac. Installed cKB and now my WinKey isn't functioning. Rebooting fixed it but then like 10 mins later it got disabled again...

 

PS: keyboard is not recognized by cKB, could this commit be the culprit?

 

EDIT: compiled the testing branch and fixed the comma typo - everything is working now :D

Edited November 9, 2015 by frifox

Re-launching the program will open the UI again. It should show up in your applications menu.

 

I have tried that and I have tried re-installing it. I still have nothing in the menu bar but it does show up in Activity Monitor so it is running properly. I cannot get to the GUI though to make any changes.

 

EDIT: I got it fixed by finding the key in the com.ckb.ckb.plist and changing the value from YES to NO and then restarting the CKB application.

Edited November 9, 2015 by Slim.Jim

Hey guys, I was just wondering... Will the rgb Strafe will be supported with this? I am currently trying to get rid of my old keyboard *cough*Blackwidow Chroma*cough* in effort to get quieter and better switches. I don't really want the k70 due to the hardware issues I keep seeing and the Strafe has the white backplate and the new silent switches.

 

On a side note, I also run OSX El Capitan now. V10.11.1, so I assume CKB will not operate on my Mac?

 

I'd really appreciate some help from the Dev or anyone who has any information on the questions I need answering.

 

Thanks in advance.

Hey guys, I was just wondering... Will the rgb Strafe will be supported with this?

 

Yes, it is supported. I added the Strafe RGB support, and tested along with a couple of other folks. It's in the testing branch and will be official in the upcoming release of ckb from ccMSC.

 

Please report any bugs/feature requests for Strafe on the GitHub.

Hey everyone, sorry it's been so long in coming, but v0.2.2 is finally released tonight! Adds support for the Strafe and Strafe RGB as well as the new Scimitar mouse. It also fixes the bug with launching programs on Linux, which has been around since v0.2.1. Let me know if you find any new issues with it.