Clément

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.

I would blame the USB interrupt polling for that. The window update/redraw should not happen more frequently than the screen refresh rate.

Please answer the question about the kernel driver, on the kernel driver thread. The LED/macro configuration is best done with ckb (or in another user space program). But remapping buttons is easier in the kernel driver. I will watch the github issue so I will find the informations, there is no need to bother MSC with my kernel driver issues. So, post the captures on MSC's ckb github and post anything concerning the kernel driver on the other thread or the driver github.

You need to make captures while changing settings with Corsair software. Keep your captures short and simple, note everything you did while capturing. There are few vendor specific control transfer in "corsairk40.txt" and "corasirk40-2.txt", the same ones. Two of them may be the same as for the K90: setting playback to software mode (bRequest=2), and backlight brightness to 0 (bRequest=49). Does that make sense?

The descriptors look like those from the non-RGB keyboards, and I was misled by the lack of RGB in the name. From the descriptors, I think it may be harder than just add an ID in ckb to make it work. But since you have access to a Windows machine you could try to sniff the USB traffic with USBPcap.

I don't think the K40 is a RGB keyboard. You cannot change the color of the LEDs (except with a soldering iron and new LEDs ;)).

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

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.

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)?

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

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?

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?

Thanks. If did not miss anything you only have these commands: #define NK95_HWOFF 0x020030 // Hardware playback off #define NK95_HWON 0x020001 // Hardware playback on #define NK95_M1 0x200001 // Mode switches #define NK95_M2 0x200002 #define NK95_M3 0x200003 If you are interested, I have more: https://github.com/cvuchener/k90-linux-driver/blob/master/control_messages.md For the profile switching you are using bRequest = 0x20 but I use 20 in decimal (0x14), so I think you have a bug there. PS: The capture in the issue thread are different from mine, I will have a look at them.

Hello, I am writing a kernel space driver for the K90 (https://github.com/cvuchener/k90-linux-driver/) and I was wondering if you wrote any documentation on the control messages for the keyboards you are supporting.