3

Status: This is fixed as of Kernel 4.18, see the accepted answer for details.

I just started using a Redragon Asura USB Keyboard. The keyboard works at a basic level, but unfortunately all the Ctrl, Alt keys and the Win key are mapped to the left shift key, which makes it quite hard to use.

The dmesg output is

[185765.848957] input: USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:0C45:760B.0022/input/input50
[185765.905395] hid-generic 0003:0C45:760B.0022: input,hidraw3: USB HID v1.11 Keyboard [USB Keyboard] on usb-0000:00:14.0-3/input0
[185765.949342] input: USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:0C45:760B.0023/input/input51
[185766.009474] hid-generic 0003:0C45:760B.0023: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [USB Keyboard] on usb-0000:00:14.0-3/input1

I've started debugging the key presses using xev, and I get the exact same key mapping for those keys. I might've mixed the KeyPress and KeyRelease events, but all in all they are the same ( see at the end of the post ).

What can I do to properly map the Ctrl, Alt and Win keys?

Left alt:

KeyRelease event, serial 36, synthetic NO, window 0x3200001,
    root 0xd7, subw 0x0, time 185237066, (307,429), root:(2272,538),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Left ctrl:

KeyPress event, serial 36, synthetic NO, window 0x3200001,
    root 0xd7, subw 0x0, time 185265721, (443,237), root:(2408,346),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

Left shift:

KeyRelease event, serial 36, synthetic NO, window 0x3200001,
    root 0xd7, subw 0x0, time 185303441, (436,539), root:(2401,648),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Win key:

KeyPress event, serial 36, synthetic NO, window 0x3200001,
    root 0xd7, subw 0x0, time 185327465, (399,367), root:(2364,476),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

Right Alt:

KeyPress event, serial 36, synthetic NO, window 0x3200001,
root 0xd7, subw 0x0, time 185361768, (348,141), root:(2313,250),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

Right ctrl:

KeyPress event, serial 36, synthetic NO, window 0x3200001,
    root 0xd7, subw 0x0, time 185401328, (598,415), root:(2563,524),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

Edit: indeed, the keyboard shows up as two USB devices. I've uploaded the HID descriptors from /sys/debug/kernel/hid at

Improve this question
6
  • Does it actually show up as two HID devices, or did you plug it out and in again, reboot in between etc? Run evtest as root, select USB keyboard, see if they show up at the same scan code there as well. If yes, we need the HID descriptor (I'll tell you how). If no, edit question with output of setxkbmap -print.
    – dirkt
    Jun 12 '17 at 8:34
  • @dirkt - it does appear as two USB devices - I've unplugged and re-plugged in to double check. Running evdev as root shows me two 'USB keyboard' devices. The first one does not get generate any input, only the second one. The same problem is listed with evdev, left control generates type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1
    – Robert Munteanu
    Jun 12 '17 at 8:41
  • Huh, interesting. Do mount -t debugfs none /sys/kernel/debug as root, put output of /sys/kernel/debug/hid/DEVICE/rdesc for all DEVICE you can find into question (or pastebin, if too large). Does it also show up as two devices in lsusb?
    – dirkt
    Jun 12 '17 at 8:46
  • @dirkt - I have two related entries under /sys/kernel/debug/hid: 0003:0C45:760B.0037 and 0003:0C45:760B.0038 . I've uploaded the rdesc files at pastebin.com/4VwDKRvU and pastebin.com/CrBVRFBj
    – Robert Munteanu
    Jun 12 '17 at 9:01
  • That looks unusual enough that you may need a quirk in the HID kernel driver. Before I look at that in detail, do a hexdump -C /dev/hidrawX on both hidraw devices (check dmesg for current numbers), each time: press each of the Ctrl/Alt/Win keys twice, press space bar at end a few times until the next line appears. Put output in pastebin.
    – dirkt
    Jun 12 '17 at 9:14
2

I know this answer is a bit late, but i found Swoogans keyboard driver and modified it for our purpose. I recently bought a Asura K501 myself and went through the same trouble. Please note that my asura is 2017 model and chipset is 0x760b and not 0x7603

https://bitbucket.org/vipinmohan/redragon-asura-kb-ubuntu

Use this. My Asura works fine now

Improve this answer
1
2

My Linux kernel patch to fix Redragon Asura keyboards is now mainlined and will part of the Kernel 4.18 release.

There is a minor issue with the Num Lock and Caps Lock LEDs not being active ( keys work just fine ) that will be fixed with 4.19.

The patch can be applied to 4.16 and 4.17 as well, openSUSE started carrying it with 4.16.

Improve this answer
1

Partial answer:

The first (silent) HID descriptor looks like what you usually see for USB keyboards: A report consists of 8 bits for the left and right Ctrl/Shift/Alt/Meta (Win) keys, followed by a reserved byte (zero) and 6 bytes for the scan codes for key presses. (This is the reason why USB keyboards are limited to 6-key rollover). This may be some sort of legacy descriptor.

The second descriptor makes use of several report types. The first three are for "consumer" (whatever that is), power control, and one vendor-defined (so we don't know what it does). The remaining three report types (IDs 4 to 6) report every single key as a bitfield (which makes a lot of sense for a gaming keyboard with n-key rollover).

As you can see from the hidraw dump, the functions keys are reported correctly: Pressing Left Ctrl gives you

04 01 00 00 00 00 00 00

(report id is 4, first bit is on), while pressing Left Alt gives you

04 04 00 00 00 00 00 00

(report id is 4, third bit is on), etc., and releasing all keys resets all bits to zero.

The device mapping in the kernel

Keyboard.00e0 ---> Key.LeftControl
Keyboard.00e1 ---> Key.LeftShift
Keyboard.00e2 ---> Key.LeftAlt
Keyboard.00e3 ---> Key.LeftMeta
Keyboard.00e4 ---> Key.RightCtrl
Keyboard.00e5 ---> Key.RightShift
Keyboard.00e6 ---> Key.RightAlt
Keyboard.00e7 ---> Key.RightMeta

actually claims to understand that, and it should map those to different scan codes. So if you really don't see something similar to

type 4 (EV_MSC), code 4 (MSC_SCAN), value 1d
type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 1
-------------- SYN_REPORT ------------
type 4 (EV_MSC), code 4 (MSC_SCAN), value 1d
type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 0
-------------- SYN_REPORT ------------
type 4 (EV_MSC), code 4 (MSC_SCAN), value 38
type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 1
-------------- SYN_REPORT ------------
type 4 (EV_MSC), code 4 (MSC_SCAN), value 38
type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 0
-------------- SYN_REPORT ------------

in evtest (notice the different MSC_SCAN codes, once 1d, once 38; never mind the line with EV_KEY), then something goes wrong when the kernel maps the HID report to the scan codes.

In that case, please file a bug with the kernel developers (I guess for "input subsystem"), include all the information so far, and see if they have an idea to debug this.

A possible alternative solution is to somehow activate the legacy HID device, as this is more similar to normal USB keyboard and may work out of the box. Are there some keys or key combinations on the keyboard that look like they might do this?

Improve this answer
8
  • Thanks, I'll look into filing a bug. The keyboard does not have a legacy option, but I'll contact the manufacturer regarding that.
    – Robert Munteanu
    Jun 12 '17 at 12:56
  • 1
    Filed bugzilla.kernel.org/show_bug.cgi?id=196053 . Thanks a lot for your help troubleshooting this
    – Robert Munteanu
    Jun 13 '17 at 9:02
  • you seem very knowledgeable in this area. I decided to take out my rusty C for a walk and try and write a kernel module for the fix. I basically built a hid module stub and have an empty input_mapping method I'm looking at. Can you tell me where I can find the correspondence between the hid_* kernel data structures and what I see using hexdump -C ? I should be able to get something going then.
    – Robert Munteanu
    Jun 14 '17 at 7:58
  • I don't think you can write a new kernel module, you'll have to look at the existing ones. I don't understand the kernel HID layer in detail, but have a look at drivers/hid, especially hid-core.c and hid-input.c, and also Documentation/hid, especially hidraw.txt and hid-transport.txt. For the HID descriptor, read usb.org/developers/hidpage/HID1_11.pdf, essentially the kernel parses this and uses it in the above files to pass stuff to the input layer.
    – dirkt
    Jun 14 '17 at 8:16
  • Documentation/hid is a good start, thank you. I've seen that lots of HID drivers exist for such quirks, e.g. hid-microsoft.c . Hopefully something comes out of that
    – Robert Munteanu
    Jun 14 '17 at 8:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.