Redragon Asura USB keyboard maps all Ctrl, Alt, Win keys to Shift_L

Question

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

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 08: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 08: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 08: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 https://pastebin.com/4VwDKRvU and https://pastebin.com/CrBVRFBj — Robert Munteanu, Jun 12 '17 at 09: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 09:14
@dirkt - The first device ( hid-generic 0003:0C45:760B.0037: input,hidraw2 ) did not generate any output using hexdump. The second device did ( hid-generic 0003:0C45:760B.0038: input,hiddev0,hidraw3 ). Pastebin for the second device is at https://pastebin.com/yLZRMyEe — Robert Munteanu, Jun 12 '17 at 09:56

score 2 · Answer 1 · answered Jan 13 '18 at 14:00

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

answered Jan 13 '18 at 14:00

Vipin Mohan R Nair

121
3

Thanks! I still hope to upstream my kernel patch though ( see https://marc.info/?l=linux-input&m=151557660008868&w=2 ). Just that there isn't much enthusiasm in accepting it – Robert Munteanu Jan 15 '18 at 15:10

Robert Munteanu · Accepted Answer · 2018-08-15T13:32:41.900

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.

edited Aug 15 '18 at 13:32

answered Jun 11 '18 at 06:46

Robert Munteanu

900
1
14
31

score 1 · Answer 3 · answered Jun 12 '17 at 12:40

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?

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
Filed https://bugzilla.kernel.org/show_bug.cgi?id=196053 . Thanks a lot for your help troubleshooting this — Robert Munteanu, Jun 13 '17 at 09: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 07: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 http://www.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 08: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 08:22
Ah, you mean a module for a quirk. Yes, that might work, but I think you have to register the quirk; a stand-alone module will likely not work. Anyway, first one has to find out what exactly goes wrong. — dirkt, Jun 14 '17 at 08:55
I've submitted a RFC patch for the module. It does not fully work yet, but it's close enough to ask for comments as I am not sure why it doesn't work - https://marc.info/?l=linux-input&m=149752350525343&w=2 — Robert Munteanu, Jun 15 '17 at 10:50
I still face the same issue now, has this been merged into the kernal? — Ankit Singhaniya, Nov 03 '17 at 18:23

Redragon Asura USB keyboard maps all Ctrl, Alt, Win keys to Shift_L

3 Answers3