(Unofficial) Linux / OSX Driver

[MSC]

Would you be willing to run Windows in a virtual machine and do some USB captures? I can provide instructions. I think the protocol is more or less the same as the RGB keyboards but I don't have a keyboard to test it myself.

 

For now, can you give me the output of this terminal command?

lsusb -vd 1b1c:

[ESBDB]

I put the results in a pastebin as it's quite long:

http://pastebin.com/4vQiqHsr

 

I can do some testing in a windows virtual machine. Are you using the keyboard in the virtual machine and capturing the input from linux? Or can this be done in native windows?

 

Thanks for the quick response :) .

[fopa]

Do you have one? I'm not 100% certain but I think it's identical to the M65 apart from a slightly different layout and having one more light zone. I could add experimental support if you're interested in testing.

Hi, I'm just looking for a new mouse and consider to buy the Sabre RGB Laser. Since I do working on linux (ubuntu 64 bit) and gaming on windows, I need at least rudimentary functionality of the mouse on linux. Does the kernel support this even without this driver?

Apart from that, full feature support would be nice, of course. So, if it is not too much work for you to add support for the Sabre in your driver... :biggrin:

[sveppur]

Hi, I recently switched to Arch Linux and when I run the ./cbk-daemon it simply stops at this line. Any ideas what I could be doing wrong?http://i.imgur.com/MWWS0pG.png?1

[MSC]

I put the results in a pastebin as it's quite long:

http://pastebin.com/4vQiqHsr

 

I can do some testing in a windows virtual machine. Are you using the keyboard in the virtual machine and capturing the input from linux? Or can this be done in native windows?

 

Thanks for the quick response :) .

I've created a basic test branch which will treat the Strafe like a K70. I don't know how well it will work (actually, I'm not sure it will work at all) but I've opened an issue on the GitHub tracker with info about how to do the captures: https://github.com/ccMSC/ckb/issues/120

You can find the link for the test branch there as well. It's a bit of a long read so let me know if you have trouble following anything.

 

Hi, I'm just looking for a new mouse and consider to buy the Sabre RGB Laser. Since I do working on linux (ubuntu 64 bit) and gaming on windows, I need at least rudimentary functionality of the mouse on linux. Does the kernel support this even without this driver?

Apart from that, full feature support would be nice, of course. So, if it is not too much work for you to add support for the Sabre in your driver... :biggrin:

AFAIK the mouse works fine out of the box, though obviously you won't have any control over lighting and animation. I could add support fairly easily if you're willing to do some testing, as I believe the Sabre's protocol is identical to the M65's.

 

Hi, I recently switched to Arch Linux and when I run the ./cbk-daemon it simply stops at this line. Any ideas what I could be doing wrong?http://i.imgur.com/MWWS0pG.png?1

Seems to be working normally. The daemon isn't really meant to be run manually and doesn't log anything except when connecting/disconnecting a device.

[fopa]

AFAIK the mouse works fine out of the box, though obviously you won't have any control over lighting and animation. I could add support fairly easily if you're willing to do some testing, as I believe the Sabre's protocol is identical to the M65's.

Thanks for the information! Lightning control is not eminently important for me, but I would consent to help you with testing your drivers. Just let me first buy the Sabre mouse and let me find out if it suits me.

[Clément]

I am writing a linux kernel driver for the K90 and I was wondering how much it has in common with other Corsair keyboards and if it could be extended to other devices.

 

From what I see in ckb-daemon code, the USB protocol looks different (I am not sure, I did not read all of it). But what about HID usage code for the special keys? Do all the keyboards that you support use the same HID usage codes and are they the same as those of the K90?

[MSC]

No, in fact they're not even standard HID reports at all. Moreover the only way to get the keyboard to report input reliably (e.g. without glitching) is to instruct it to send all key reports through this custom protocol.

[Clément]

What do you mean with non-standard HID report? Are reports not doing what the descriptor says? Or is it just using some reports with the vendor specific usage page? Can you point me to the code reading the input?

 

In ckb-daemon/keymap.c, you have a LUT for converting HID usage codes to scancode. I am not sure how it works but if the numbers match the ones in the keymap array, you have mapped the HID usage codes I have for the K90 to the G-keys, profile keys, .... So what are the devices using that?

 

Edit: In the code below the LUT in hid_kb_translate, in looks like you are reading standard hid reports to me. Actually "case 1", "case 2" and "case 3" would respectively match the reports from interface 0, 1 and 2 on my K90.

 

Edit2: Okay, in ckb-daemon/usb_linux.c, you memcpy the report from endpoint 0x83 on RGB keyboards. Is this interface HID? If it is, I am curious about the HID report descriptor. What is the difference between this one and report 1 on endpoint 0x82?

Edited September 9, 2015 by Clément

[Clément]

Asking the HID usage code problem another way: Does other Corsair keyboard have the same mapping problem than the K90? I mean G9 behaving as delete, G17 as play/pause, changing light brightness starting the calculator, ...

[MSC]

No. The report doesn't conform to any HID standard that I'm aware of. In fact sending it to the kernel driver will cause the keyboard to go into a hard lock because the driver doesn't read it. The report is actually a bitfield of all keys currently pressed, including the G keys (in this way it's similar to the N-key rollover switch, which is how the keyboard communicates with the stock driver). However, the keys don't appear in the same order.

[Clément]

Non conform report or report descriptor can be fixed in kernel drivers. Can you post the report descriptor?

 

What exactly do you mean by "doesn't read it", the kernel is not polling the interrupt? a response is expected? Usually a device does not care what the kernel does with the reports.

 

To anyone with a Corsair keyboard: could you post the result of the following command?

for f in /sys/bus/hid/devices/0003\:1B1C\:*/report_descriptor; do echo $f; xxd -g 1 "$f"; done

(I think in does not work with ckb running, so stop the daemon, if you have it running)

 

Edit: I think I have found the report descriptors in the firmware (1.30 for K95RGB from your FIRMWARE file), I found 4 descriptors. The first two are what I expected from your code and my experience with the K90. The last two use vendor specific usage page.

 

The third (I guess the one you are polling in ckb) is an input report 64 bytes with usage 0xFFC00001/0xFFC00011.

The fourth has feature/input/output of 64 bytes with usage 0xFFC20002.

 

So they are perfectly valid vendor specific reports and the OS should ignore them. Why does the keyboard hang with Linux and not with Windows (without corsair driver installed)?

Edited September 11, 2015 by Clément

[fopa]

AFAIK the mouse works fine out of the box, though obviously you won't have any control over lighting and animation. I could add support fairly easily if you're willing to do some testing, as I believe the Sabre's protocol is identical to the M65's.

I've tried out the Sabre for a few days so far, and I must say: This mouse is fantastic! So I will definitely keep it.

If you would add controls over lightning and sensitivity settings to your linux driver, I would gladly help to test it. :-)

[MSC]

Non conform report or report descriptor can be fixed in kernel drivers. Can you post the report descriptor?

 

What exactly do you mean by "doesn't read it", the kernel is not polling the interrupt? a response is expected? Usually a device does not care what the kernel does with the reports.

 

To anyone with a Corsair keyboard: could you post the result of the following command?

for f in /sys/bus/hid/devices/0003\:1B1C\:*/report_descriptor; do echo $f; xxd -g 1 "$f"; done

(I think in does not work with ckb running, so stop the daemon, if you have it running)

 

Edit: I think I have found the report descriptors in the firmware (1.30 for K95RGB from your FIRMWARE file), I found 4 descriptors. The first two are what I expected from your code and my experience with the K90. The last two use vendor specific usage page.

 

The third (I guess the one you are polling in ckb) is an input report 64 bytes with usage 0xFFC00001/0xFFC00011.

The fourth has feature/input/output of 64 bytes with usage 0xFFC20002.

 

So they are perfectly valid vendor specific reports and the OS should ignore them. Why does the keyboard hang with Linux and not with Windows (without corsair driver installed)?

Frankly I don't know - it seems like a design flaw on Corsair's part. The OS doesn't read the reports at all. If I try to capture them in Wireshark, they simply don't appear without ckb running. For some reason this causes the keyboard to hard-lock (I assume it's waiting for the USB transfer to be acknowledged by the OS, which doesn't happen). It doesn't have this problem in Windows or OSX because they actually do read the reports, but don't do anything with them. It can be fixed with the ALWAYS_POLL HID quirk, which causes the Linux kernel to behave in the same way.

 

I've tried out the Sabre for a few days so far, and I must say: This mouse is fantastic! So I will definitely keep it.

If you would add controls over lightning and sensitivity settings to your linux driver, I would gladly help to test it. :-)

 

Awesome! Can you post the output of the following terminal command:

lsusb -d 1b1c:

[fopa]

In case you need more detailed info...

me@mymachine:~$ sudo lsusb -v -d 1b1c:
Bus 006 Device 003: ID 1b1c:1b19 Corsair 
Device Descriptor:
 bLength                18
 bDescriptorType         1
 bcdUSB               2.00
 bDeviceClass            0 (Defined at Interface level)
 bDeviceSubClass         0 
 bDeviceProtocol         0 
 bMaxPacketSize0        64
 idVendor           0x1b1c Corsair
 idProduct          0x1b19 
 bcdDevice            1.19
 iManufacturer           1 Corsair
 iProduct                2 Corsair Gaming SABRE RGB Laser Mouse
 iSerial                 3 0200E038AE3B9403536D7B7DF5001942
 bNumConfigurations      1
 Configuration Descriptor:
   bLength                 9
   bDescriptorType         2
   wTotalLength          116
   bNumInterfaces          4
   bConfigurationValue     1
   iConfiguration          0 
   bmAttributes         0xa0
     (Bus Powered)
     Remote Wakeup
   MaxPower              300mA
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        0
     bAlternateSetting       0
     bNumEndpoints           1
     bInterfaceClass         3 Human Interface Device
     bInterfaceSubClass      1 Boot Interface Subclass
     bInterfaceProtocol      2 Mouse
     iInterface              0 
       HID Device Descriptor:
         bLength                 9
         bDescriptorType        33
         bcdHID               1.11
         bCountryCode            0 Not supported
         bNumDescriptors         1
         bDescriptorType        34 Report
         wDescriptorLength      58
        Report Descriptors: 
          ** UNAVAILABLE **
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x81  EP 1 IN
       bmAttributes            3
         Transfer Type            Interrupt
         Synch Type               None
         Usage Type               Data
       wMaxPacketSize     0x0008  1x 8 bytes
       bInterval               8
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        1
     bAlternateSetting       0
     bNumEndpoints           1
     bInterfaceClass         3 Human Interface Device
     bInterfaceSubClass      0 No Subclass
     bInterfaceProtocol      0 None
     iInterface              0 
       HID Device Descriptor:
         bLength                 9
         bDescriptorType        33
         bcdHID               1.11
         bCountryCode            0 Not supported
         bNumDescriptors         1
         bDescriptorType        34 Report
         wDescriptorLength      99
        Report Descriptors: 
          ** UNAVAILABLE **
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x82  EP 2 IN
       bmAttributes            3
         Transfer Type            Interrupt
         Synch Type               None
         Usage Type               Data
       wMaxPacketSize     0x000a  1x 10 bytes
       bInterval               1
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        2
     bAlternateSetting       0
     bNumEndpoints           1
     bInterfaceClass         3 Human Interface Device
     bInterfaceSubClass      0 No Subclass
     bInterfaceProtocol      0 None
     iInterface              0 
       HID Device Descriptor:
         bLength                 9
         bDescriptorType        33
         bcdHID               1.11
         bCountryCode            0 Not supported
         bNumDescriptors         1
         bDescriptorType        34 Report
         wDescriptorLength      21
        Report Descriptors: 
          ** UNAVAILABLE **
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x83  EP 3 IN
       bmAttributes            3
         Transfer Type            Interrupt
         Synch Type               None
         Usage Type               Data
       wMaxPacketSize     0x0040  1x 64 bytes
       bInterval               1
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        3
     bAlternateSetting       0
     bNumEndpoints           2
     bInterfaceClass         3 Human Interface Device
     bInterfaceSubClass      0 No Subclass
     bInterfaceProtocol      0 None
     iInterface              0 
       HID Device Descriptor:
         bLength                 9
         bDescriptorType        33
         bcdHID               1.11
         bCountryCode            0 Not supported
         bNumDescriptors         1
         bDescriptorType        34 Report
         wDescriptorLength      21
        Report Descriptors: 
          ** UNAVAILABLE **
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x84  EP 4 IN
       bmAttributes            3
         Transfer Type            Interrupt
         Synch Type               None
         Usage Type               Data
       wMaxPacketSize     0x0040  1x 64 bytes
       bInterval               1
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x04  EP 4 OUT
       bmAttributes            3
         Transfer Type            Interrupt
         Synch Type               None
         Usage Type               Data
       wMaxPacketSize     0x0040  1x 64 bytes
       bInterval               1
Device Status:     0x0000
 (Bus Powered)

[Clément]

Frankly I don't know - it seems like a design flaw on Corsair's part. The OS doesn't read the reports at all. If I try to capture them in Wireshark, they simply don't appear without ckb running. For some reason this causes the keyboard to hard-lock (I assume it's waiting for the USB transfer to be acknowledged by the OS, which doesn't happen). It doesn't have this problem in Windows or OSX because they actually do read the reports, but don't do anything with them. It can be fixed with the ALWAYS_POLL HID quirk, which causes the Linux kernel to behave in the same way.

 

Thanks! So the fix will be quite easy (if I ever find a tester for it), I just have to add this quirk in the driver for RGB keyboards.

[Clément]

Peter Hutterer and Benjamin Tissoires started a project for configuring gaming mice on Linux. I think it would be a good thing to contact them about what you have done for Corsair mice (and maybe keyboards if they want to extend to that).

[Slim.Jim]

Just registered to say THANKS! This driver is working perfectly for me with a K65 RGB.

[Slim.Jim]

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.

 

Was there ever any progress with this?

 

I have the very long boot times and if I reboot from Windows into OS X the keyboard works during the Clover boot screen but when OS X loads it functions just like you report with having to unplug it, etc...

[Jimjitsu]

Registered to say thank you for this driver, I have made a donation to your Paypal so you can grab yourself a beer. I have just purchased a Corsair gaming K70,M65 and MM600 because of this driver and it's use with Linux, I think Corsair should recognise that this driver is making sales for them and should officially support it and it's creator. Edited September 18, 2015 by Jimjitsu

[abracadaniel]

Works better than the official one for windows, thanks heaps

[Patchwerk_Adams]

I just downloaded this now, and like a few people before me have said this one works better than the official drivers for Windows. You are incredibly talented to pull this off, thank you so much.

[robbob2112]

I had an 'oops' moment last night with 'sgdisk' trying to copy a partition table.. Why the folks that wrote sgdisk thought it would be smart to switch the expected order or arguments I'll never know.... ever unix copy command I know does .... COMMAND src dest ... but sgdisk does ... sgdisk /dev/sd(dest) /dev/sd(src) .... so I managed to wipe my partition table out ......

 

That said,

 

after I mucked around with it for an hour or so and decided the simplest and cleanest cure would be a re-install and restore the critical stuff from backup... ..

 

Much to my surprise the k95-RGB functions with the native drivers under Fedora 22 .... there is no way to adjust the colors or any of the other great stuff, but it does work now...

 

I will re-install ckb simply because it is a great utility.... and thanks again for writing and maintaining it... But thought you should know they seem to be rolling support into the newer kernels now.

 

Linux intrepid 4.0.4-301.fc22.x86_64 #1 SMP Thu May 21 13:10:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

 

Also note: they integrated support for the volume and mute buttons into it.

 

Robert

Edited September 22, 2015 by robbob2112

[debianmainused]

Quick Question---I know that I don't have a K65 or up keyboard--Have just bought a K40 & was wondering if anyone has any pointers/ideas to just change the color (want to go from the default red to a dark blue)----running Debian Sid & am able to do debugging work--just need ideas where to start........I've got a good basic keyboard without any options.

 

(edit) This is for a K40 Keyboard:

 

dean@linux:~$ for f in /sys/bus/hid/devices/0003\:1B1C\:*/report_descriptor; do echo $f; xxd -g 1 "$f"; done

/sys/bus/hid/devices/0003:1B1C:1B0E.0001/report_descriptor

00000000: 05 01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 ..........)...%.

00000010: 75 01 95 08 81 02 75 08 95 01 81 01 05 07 19 00 u.....u.........

00000020: 2a ff 00 15 00 26 ff 00 75 08 95 06 81 00 05 08 *....&..u.......

00000030: 19 01 29 03 25 01 75 01 95 03 91 02 95 05 91 01 ..).%.u.........

00000040: c0 .

/sys/bus/hid/devices/0003:1B1C:1B0E.0002/report_descriptor

00000000: 05 0c 09 01 a1 01 05 0c 19 00 2a ff 0f 15 00 26 ..........*....&

00000010: ff 0f 75 10 95 02 81 00 c0 ..u......

/sys/bus/hid/devices/0003:1B1C:1B0E.0003/report_descriptor

00000000: 05 01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 ..........)...%.

00000010: 75 01 95 08 81 02 19 00 29 6f 15 00 25 01 75 01 u.......)o..%.u.

00000020: 95 70 81 02 c0

 

Edit #2:

OK, I fired up a old XP machine & installed the software & firmware updates--Got the blue I wanted & saved it to my profile---pain in the "you know where" But it worked...Really ready to assist in making the K40 added to this software......

Edited September 24, 2015 by debianmainused

[Slim.Jim]

Has anyone else noticed that the CPU (i7-4790k) multiplier stays high when this is installed?

 

If I uninstall it, the multiplier steps down to x8 like it should but with this installed it stays at a constant x40. Turbo still works fine boosting x44 it just doesn't drop below x40.

Edited September 24, 2015 by Slim.Jim