Bug 79251

By logging into tty2 as root and running kbd_mode -u the numlock and scroll lock now functions correctly. Caps lock status indicator still does not come on. Even xset led name "Caps Lock" won't turn it on.

Same issue with kernels 3.14, 3.16. Seems that the caps lock led might have to be remapped.

Created attachment 158951 [details]
test case on keyboard with trace

Created attachment 158961 [details]
test case on working keyboard

Created attachment 158971 [details]
negociation on buggy keyboard

Created attachment 158981 [details]
negociation on work keyboard

I have the same issue with k95 keyboard. Moreother when I press a macro key on the left (not available on k75) all keyboard become freezed and need a computer reboot.

The freeze is from the keyboard because others functions managed by the keyboard don't work (changing profile, lower luminositie)

I have make 2 test on azerty keyboard :
the first one :
press a
press z
press e
press r
release r
release e
release z
release a
press caps lock
release caps lock
press caps lock
release caps lock

the second one :
lauch the capture 
plug the keyboard


you can found theses tests on attachements.

I can see that the packets size between the two keyboard is différent, the keycode too. The reference keyboard is a simple usb keyboard that just work perfectly.

My lower luminositie and windows lock key all function fine with the K70 it is just the status indicator lights for scroll lock, caps lock and num lock that either don't show or don't show as expected. How did you managed to see the calls ?

I used the usemon module that add /dev/usbmonX that allow listening usb trafic

Your k70 is it an RGB edition ?

No mine I got 4 months before that release so it is still the K70 with plain blue LED's.

Okey, I think the led issue is related but the rest is specific to the new class of keyboard

Ah I see, is the fix for this simple? My friend owns the K70 RGB so if needed I can get traces for that keyboard.

good idea ;) It's can be usefull for salving the bug

The precedure need to use wireshark and usbmon module
you modeprobe the module, add the user on the wireshark group, chmod o+rw /dev/usbmon*

you make an lsusb and found the divice, the number on the left before vendore:device code is the number of the correct port

try a capture from the same test, try to hit a macro to freeze it. If it's freeze try to change the light level.

thanks

I see something odd. Only the first interface has the Keyboard subclass, and the kernel only requests the HID descriptor for that interface. The keyboard events seem to come through a different endpoint though (EP 2) which is a different interface for which I have no HID device descriptor.

Please post (attach?) the output of:

    sudo lsusb -v -d 1b1c:1b11

Please unplug and insert your keyboard as well and post the tail of the dmesg.

Requested output: 
http://pastebin.com/YDULg4tD

Created attachment 159041 [details]
k95 rgb dmesg + lsusb -v

I have some different trace, I had join it in attachement

Created attachment 159051 [details]
Trace of just numlock/capslock and scrollock

file is broken

Created attachment 159061 [details]
lsusb-v.txt

sudo rmmod hid-generic; sudo lsusb -v -d 1b1c:1b11 > lsusb-v.txt; sudo modprobe -v hid-generic

Created attachment 159071 [details]
lsusb.txt

Created attachment 159081 [details]
capture dump

Created attachment 159091 [details]
keyboard unplug

unplug and re-plug caps lock on and off, num lock on and off, scroll lock on and off

Created attachment 159101 [details]
dmesg trail of keyboard unplug

Created attachment 159481 [details]
capture with keyboard unplug and sleep 2

I hope this file contains everything

Hey, I've been working on a userspace driver for the K70/K95 RGB keyboards, so here's my 2¢:

Peter Wu is correct that the keyboard input usually comes through EP 2. The Corsair K95 keyboard additionally has remappable keys, which send data through EP *3*. The Linux HID driver completely ignores EP 3, and in fact I don't even see the transfers when I capture the traffic with Wireshark. Instead, the data stream just stops (it seems to cause the keyboard's internal CPU to lock up). The EP 3 inputs only appear in Wireshark when running the Windows software in a VM or running my userspace driver.

The indicator LEDs (Num, Caps, Scroll Lock) can be set via Control URBs to endpoint 0, however these too fail to appear in my wireshark captures using the Linux driver.

It's worth noting that (at least on my device) endpoint 0 is located on interface 3, endpoint 2 is located on interface 1, and endpoint 3 is located on interface 2. Interface 0 seems to be useless. I don't know if that's normal behavior for a keyboard, but I'm guessing it isn't, so that might be relevant.

I confirm some facts that MSC say, The cpu completly lock down on this case. 

Moreother, the HID initialization sean to not be correctly made (according of the size of the packets on wireshark)

the userspace driver located here https://github.com/ccMSC/ckb have some good iuudea and can certenly help linux kernel developer to add it into kernel.

In this we should add a new file on the HID driver to fix initializatioln.
Moreother, we should on this file create a new /dev entry that allow color management and firmware update.

Thanks to the work of MSC, I think that the task will not be too complicated, but I don't have the knowleage on kernel driver wrote.

Will there be an interface to interact/change the colour of the RGB edition? I know the K95 has additional keys which are more for gaming and I am not sure how hard that will be. Linux as far as I know does not have any interface to go and customize anything for linux mice with additional buttons unless you do that in xorg but there is no program to do that. Will it be possible to write just like a GUI for that?

(In reply to leon.lewis from comment #28)
> Will there be an interface to interact/change the colour of the RGB edition?
> I know the K95 has additional keys which are more for gaming and I am not
> sure how hard that will be. Linux as far as I know does not have any
> interface to go and customize anything for linux mice with additional
> buttons unless you do that in xorg but there is no program to do that. Will
> it be possible to write just like a GUI for that?

See the link posted by Alexis: https://github.com/ccMSC/ckb

That's my userspace driver which does what you're asking. It's a work in progress right now but it fixes the major problems of the keyboard and it has a basic UI.

I don't think it makes sense to handle the advanced functions within the kernel, as there's a lot of abstraction that goes into it (converting human-readable RGB colors into device commands, timing the commands so that they don't lock up the device, resetting the device when that inevitably happens anyway because the firmware isn't very well designed...) and the driver runs just fine in userspace.

However, the kernel driver should at least allow it to function correctly as a basic keyboard, and it doesn't. As outlined above, the problems are: 1. Caps lock doesn't work, and 2. Pressing one of the proprietary rebindable keys causes the entire board to lock up.

I think the two problem is related to the negotiation made by the driver.

About the curstom function I think a block divice should be created.
- one ioctl call should be add to send color
- another one should be made for firmware update
- the last one for read color

I just want to add a correction, caps lock does work on the K70 scroll lock does not work at all. For Caps lock the LED on the keyboard that shows caps lock is active does not work. Numlock has issues with the LED as well.

I don't know if the person who is doing the dev work on this is, is also replying here but this driver seems to fix the issues witht he keys pretty well. https://github.com/ccMSC/ckb

Ignore my previous post I didn't realise it was the same person. MSC if you need any help testing just let me know.

Regarding the K95 and booting, when loading a profile in windows that is animated and then going to linux the static part of the lightning effect is all that is on. You have to launch MSC's gui in order for the lights to change or adjust the brightness.

Would it be possible to just add a fix to the kernel that is does not freeze up the keyboard and detects it properly? Getting the full functionality ckb can be used. This way at least the default keys can be used. So that means pressing any other key won't cause it to freeze or the kernel to try detect it.

Is it just me or is this still an issue in the 4.4.1 kernel ?