|Summary:||Keyboard status indicators not functioning properly.|
|Severity:||normal||CC:||alexis.lameire, ghost53947, peter, qccmsc|
test case on keyboard with trace
test case on working keyboard
negociation on buggy keyboard
negociation on work keyboard
k95 rgb dmesg + lsusb -v
Trace of just numlock/capslock and scrollock
dmesg trail of keyboard unplug
capture with keyboard unplug and sleep 2
Description leon.lewis 2014-06-30 12:26:47 UTC
This issues happens with all corsair vengence K70 keyboards. Setting kbd_mode -u will turn the num lock status indicator on when num lock is off. Other than that the status indicators do not function at all. Set led does in some cases turn on the num lock.
Comment 1 leon.lewis 2014-07-01 12:25:23 UTC
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.
Comment 2 ghost53947 2014-08-29 01:55:40 UTC
Same issue with kernels 3.14, 3.16. Seems that the caps lock led might have to be remapped.
Comment 3 Alexis Lameire 2014-11-27 19:50:40 UTC
Created attachment 158951 [details] test case on keyboard with trace
Comment 4 Alexis Lameire 2014-11-27 19:51:34 UTC
Created attachment 158961 [details] test case on working keyboard
Comment 5 Alexis Lameire 2014-11-27 19:52:12 UTC
Created attachment 158971 [details] negociation on buggy keyboard
Comment 6 Alexis Lameire 2014-11-27 19:52:40 UTC
Created attachment 158981 [details] negociation on work keyboard
Comment 7 Alexis Lameire 2014-11-27 19:58:46 UTC
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.
Comment 8 leon.lewis 2014-11-28 09:41:33 UTC
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 ?
Comment 9 Alexis Lameire 2014-11-28 09:57:56 UTC
I used the usemon module that add /dev/usbmonX that allow listening usb trafic Your k70 is it an RGB edition ?
Comment 10 leon.lewis 2014-11-28 10:12:57 UTC
No mine I got 4 months before that release so it is still the K70 with plain blue LED's.
Comment 11 Alexis Lameire 2014-11-28 10:20:06 UTC
Okey, I think the led issue is related but the rest is specific to the new class of keyboard
Comment 12 leon.lewis 2014-11-28 10:36:11 UTC
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.
Comment 13 Alexis Lameire 2014-11-28 10:56:13 UTC
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
Comment 14 Peter Wu 2014-11-28 11:30:11 UTC
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.
Comment 16 Alexis Lameire 2014-11-28 19:09:52 UTC
Created attachment 159041 [details] k95 rgb dmesg + lsusb -v
Comment 17 Alexis Lameire 2014-11-28 19:10:45 UTC
I have some different trace, I had join it in attachement
Comment 18 leon.lewis 2014-11-28 19:15:55 UTC
Created attachment 159051 [details] Trace of just numlock/capslock and scrollock
Comment 19 Alexis Lameire 2014-11-28 19:22:17 UTC
file is broken
Comment 20 leon.lewis 2014-11-28 21:08:06 UTC
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
Comment 23 leon.lewis 2014-11-28 22:32:31 UTC
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
Comment 24 leon.lewis 2014-11-28 22:36:24 UTC
Created attachment 159101 [details] dmesg trail of keyboard unplug
Comment 25 leon.lewis 2014-12-02 21:36:28 UTC
Created attachment 159481 [details] capture with keyboard unplug and sleep 2 I hope this file contains everything
Comment 26 MSC 2014-12-03 19:31:14 UTC
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.
Comment 27 Alexis Lameire 2014-12-03 19:45:13 UTC
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.
Comment 28 leon.lewis 2014-12-04 07:21:13 UTC
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?
Comment 29 MSC 2014-12-05 05:08:47 UTC
(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.
Comment 30 Alexis Lameire 2014-12-10 18:13:15 UTC
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
Comment 31 leon.lewis 2015-02-02 09:01:56 UTC
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.
Comment 32 leon.lewis 2015-03-11 07:50:25 UTC
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
Comment 33 leon.lewis 2015-03-11 07:53:37 UTC
Ignore my previous post I didn't realise it was the same person. MSC if you need any help testing just let me know.
Comment 34 leon.lewis 2015-03-11 08:09:18 UTC
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.
Comment 35 ghost53947 2015-07-31 20:54:31 UTC
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.
Comment 36 ghost53947 2016-02-29 18:58:36 UTC
Is it just me or is this still an issue in the 4.4.1 kernel ?