mjhjmtu

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

• https://pastebin.com/4VwDKRvU


• https://pastebin.com/CrBVRFBj

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

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?

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.