I have a Raptor K30 Keyboard, how can I help? #5
Comments
|
Here is the USB ID for the K30: |
|
The HID usage codes part seems to be consistent accross corsair devices. But advanced features like backlight or macro profiles have slight variation that makes it more complex to support everything and I am thinking about deprecating those in the kernel driver and replacing them with a user-space tool (https://github.com/cvuchener/corsair-usb-config). For testing the key remapping, you can try adding your device in the corsair_devices table in hid-corsair.c without enabling advanced features: and adding in hid-ids.h: (or I can create a branch for that, if you don't know how to edit the driver). If you do not want to test the driver directly, you may simply check that the HID usage codes match those: https://github.com/cvuchener/k90-linux-driver/blob/master/hid_usage_codes.md, using usbmon or hid-recorder. Testing advanced features is more complicated, the easiest and safest way is to study the windows driver first (but you need windows for that, a vm with usb passthough should work). You could although test my user-space tool by adding your device in device_table in main.cpp using an existing class and see what works and what does not (there is an undocumented command "raw-status" to test). But that can be dangerous, some usb transfer may set the device in a bad state, most of the time, resetting it should be enough but when sending random packets I some times had to reflash the firmware to make it work again. How far you can go is mainly depending on if you have access to windows and a second keyboard to use during recovery. If you don't have those, you may prefer to stop at remapping usage codes. |
|
Thanks for replying back. I used usbmon to get these results. Do they make sense? MR 1st press = 0000f600 00000000 00000000 000000 m1 = 0000f100 00000000 00000000 000000 Lock 1st press = 0000f400 00000000 00000000 000000 Light button start from off: Mute = e2000000 00000000 00000000 000000 Stop = b7000000 00000000 00000000 000000 Also, I have a Windows 10 kvm/qemu VM where I have a USB controller passed. Normally I just use the input patches to pass a fake keyboard through, but I could disable that and plug the keyboard directly in to the passthroughed USB controller to install the official drivers. If I do that, what do I need to get the needed information for you to fully support this keyboard in either this driver or the new user space one? Thanks, |
|
The usage code are the same, it should work fine for the remapping part. Do you have any problem with the sound/media keys? They work with the generic driver for my keyboard.
Record usb traffic while using the driver (I use USBPcap on windows, but with a vm, I think using usbmon on the linux host is enough). Keep you recording short and explain what you did in details. Interesting test would be:
If you know a little about USB protocol you can try comparing what you see with the protocol documented there : https://github.com/cvuchener/k90-linux-driver/blob/master/control_messages.md. |
|
I also have a k30 keyboard, could the driver "break" (not make it work ok) my keyboard on linux? |
|
Errors in the installation or configuration of the kernel driver can lead to case where no driver manage the keyboard, so it is best to have a second keyboard to fix things (it is hard to run command or edit files without one). About testing USB command, it is hard to tell and there will never be any guarantee. When testing random commands on my K90, I did manage to kind of brick it (solved by reflashing the firmware, so nothing too long term, but it required a second keyboard and windows). Make someone else try random commands is not a good idea anyway, so I need to start with some observation of the windows driver first. If you only want to fix the keycodes, you can try a pure udev solution, that should be easier and safer : You can change the part after the = to any key you want (see /usr/include/linux/input-event-codes.h or /usr/include/linux/input.h for the list of linux key codes). 0xff is a hack using an invalid key code that should behave like there is no key code at all. See /usr/udev/hwdb.d/60-keyboard.hwdb for documentation. After writing this file, reload udev hwdb ( |
|
I'll try that, because I just want to make the G keys work. So the method you told me now, shouldn't break my keyboard, right? |
|
Does it matter if I use hexadecimal or decimal when changing the codes for the g keys? |
|
The G keys are still not working, do I have to unplug and plug the keyboard back? |
I am not sure but I don't think decimal codes work, it would conflict with key name like KEY_1. I would recommend to use key names when possible. The doc says key names come from the kernel API, so I guess it is the part after "KEY_" in lower case. Look at examples in /usr/udev/hwdb.d/60-keyboard.hwdb or in archlinux doc.
How exactly are they not working? Do you get any key event like KEY_UNKNOWN or nothing at all? I don't know about the K30 but the K90 use several interfaces so the G-keys are not sent on the same device as the regular keys. Did you test the correct device? If you give me the output of Also keep in mind that X11 does not support key codes above 255 in case you want to use something like xbindkeys. Make sure to test with the evdev interface (evtest is good for that) before trying anything using X11.
Yes maybe that can help, I am not sure if the udev command I gave are enough, but the trigger command should have done that (or does it need the device to be specified?). Maybe add a |
|
Output of the command you gave me to see the device: I haven't tried unplugging and plugging the keyboard back yet. Should I do that? I also entered the key code as hexadecimal, I used f13, f14, f15, f16, f17 and f18 keys (0xb7,0xb8,0xb9,0xba,0xbb,0xbc) |
|
G-keys should be on the first one: event3, media keys on the second: event4, regular keys on event5. The ids I used in the hwdb file match yours, so that file should work. |
That was what the file I gave did. Anyway try it without modifying it first. You can play with that later. |
|
Ok I tested on event3, but it gives me KEY_UNKNOWN |
|
I'll try using the hex codes |
|
Hex doesn't work either |
|
Do you also get MSC_SCAN events? Does the value match the part before the = (e.g. 700d0)? I tested on my side and |
|
I ran them as root and I got those MSC_SCAN events.
And this is what I have in the file, try using the hex code maybe? |
|
I don't know if it comes from the way you pasted the file, but make sure the KEYBOARD_KEY_* lines begin with a space. Check the location and filename. Quoting
If these are not the problem I am out of ideas. |
|
These are not the problem. I checked the location it's in /etc/udev/hwdb.d and the file name is 60-corsair.hwdb. Anyway thanks for the help, I will tell you if I will manage to make them work. |
|
On what linux distro did you run it on? I have ubuntu. |
|
I am using fedora, udev v229. I found that : http://unix.stackexchange.com/a/216811 |
|
I have just learned, that |
|
ah, so that's why it wasn't working, so I should also change the 0xff to reserved, right? |
|
still doesn't work, maybe try using a ubuntu 14.04 virtual machine and find a way to make it work. |
|
I had some problem too with ubuntu 14.04. I solved it with that: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1361338
FYI, in my test, /etc/udev/hwdb/60-corsair.hwdb contained: |
|
it still doesn't work |
|
also do I have to restart my computer? |
By writing the name of the device in the Look for the device names in Once you have found your device, check the Now you have all the information you need, use the following commands (the keyboard won't work between the two commands, you should type them on the same line with a semicolon to separate them if you are typing that with the K30): or if you cannot understand what I wrote, just run: If everything goes well, it should print the names of the HID devices and unbind-bind them.
It can help, but the commands form the ubuntu bug were enough for me. |
|
Ok, I got a new keyboard now, a Corsair Vengeance K95, I still want the G Keys to work though, I saw that there's a driver for linux for this keyboard (unofficial driver), should I try using that driver or still use the method you told me (if I do that, then you should give me the k95's usb id). I also noticed that the G Keys don't have KEY_UNKNOWN, they have different keys (not each of the g keys though, G1->G8 use ABS_MT_TOOL_TYPE, G9->G10 use ABS_MT_BLOB_ID, G11->G18 use ABS_MT_TRACKING_ID. |
|
Is it the RGB version ? It is strange that you have ABS_* (absolute axis) events for keys. I thought from ckb source code that both the RGB and non-RGB K95 used the same usage code as the other corsair keyboards I know. Either way you can try configuring udev or using ckb as you prefer. You can get the vid/pid with lsusb. |
|
yes it's the RGB version |
|
Although I thought it was the same for the key HID usage code, the protocol for the other features is completely different from older corsair keyboards. You should ask MSC (ckb dev) about any problem you have with it. |
|
I installed the driver and works ok, I also managed to get the G Keys work with it. Anyway thanks for the help! |
Hi,
As the title states, I have a K30 model that has 6 G keys, three memory keys, one memory record button, on button with a lock on it with the windows logo(?), three levels of brightness for the backlighting, volume keys, and media keys. Is there anything that you need to make sure your drives can be 100% compatible with this keyboard?
Thanks for your hard work on this driver.
-Jon
The text was updated successfully, but these errors were encountered: