O teclado Redragon Asura USB mapeia todas as teclas Ctrl, Alt, Win para Shift_L

2

Status : Isto é corrigido a partir do Kernel 4.18, veja a resposta aceita para detalhes.

Acabei de começar a usar o Teclado USB Redragon Asura . O teclado funciona em um nível básico, mas infelizmente todas as teclas Ctrl, Alt e Win são mapeadas para a tecla Shift esquerda, o que dificulta muito o uso.

A saída do dmesg é

[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

Eu comecei a depurar as teclas pressionando xev , e recebo exatamente o mesmo mapeamento de teclas para essas chaves. Eu poderia ter misturado os eventos KeyPress e KeyRelease, mas no geral eles são os mesmos (veja no final do post).

O que posso fazer para mapear corretamente as teclas Ctrl, Alt e Win?

Alt esquerdo:

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

Ctrl esquerdo:

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

deslocamento para a esquerda:

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

Chave do Win:

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

Alt Direita:

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

Ctrl direito:

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

Editar : na verdade, o teclado aparece como dois dispositivos USB. Eu carreguei os descritores HID de / sys / debug / kernel / hid em

por Robert Munteanu 12.06.2017 / 10:28

3 respostas

1

Meu patch do kernel do Linux para corrigir teclados do Redragon Asura agora é mainlined e fará parte do lançamento do Kernel 4.18.

Há um problema menor com os LEDs Num Lock e Caps Lock não ativos (as teclas funcionam bem) que serão corrigidos com 4.19.

O patch pode ser aplicado a 4.16 e 4.17 também, o openSUSE começou a carregá-lo com 4.16.

    
por 11.06.2018 / 08:46
2

Eu sei que esta resposta é um pouco tarde, mas eu encontrei o driver do teclado Swoogans e o modifiquei para o nosso propósito. Eu comprei recentemente um Asura K501 e passei pelo mesmo problema. Por favor note que o meu asura é o modelo 2017 e o chipset é 0x760b e não 0x7603

link

Use isso. Meu Asura funciona bem agora

    
por 13.01.2018 / 15:00
1

Resposta parcial:

O primeiro descritor HID (silencioso) se parece com o que você costuma ver para teclados USB: Um relatório consiste em 8 bits para as teclas Ctrl / Shift / Alt / Meta (Win) esquerda e direita, seguidas por um byte reservado (zero ) e 6 bytes para os códigos de digitalização para pressionamentos de tecla. (Esta é a razão pela qual os teclados USB são limitados ao rollover de 6 teclas). Isso pode ser algum tipo de descritor legado.

O segundo descritor faz uso de vários tipos de relatórios. Os três primeiros são para "consumidor" (o que quer que seja), controle de energia e um fornecedor definido (portanto, não sabemos o que ele faz). Os três tipos de relatórios restantes (IDs 4 a 6) relatam cada chave como um campo de bits (o que faz muito sentido para um teclado de jogos com sobreposição de teclas n).

Como você pode ver no dump do hidraw, as teclas de funções são relatadas corretamente: Pressionar Ctrl da esquerda dá a você

04 01 00 00 00 00 00 00 

(id do relatório é 4 , o primeiro bit está ativo), enquanto pressiona Alt esquerdo dá a você

04 04 00 00 00 00 00 00

(o ID do relatório é 4 , o terceiro bit está ativo), etc., e a liberação de todas as chaves redefine todos os bits para zero.

O mapeamento de dispositivos no 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

na verdade afirma que entende isso, e deve mapeá-los para diferentes códigos de varredura . Então se você realmente não vê algo parecido com

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 ------------

em evtest (observe os diferentes MSC_SCAN códigos, uma vez 1d , uma vez 38 ; não importa a linha com EV_KEY ), então algo dá errado quando o kernel mapeia o relatório HID para a varredura códigos.

Nesse caso, registre um bug com os desenvolvedores do kernel (eu acho que para "subsistema de entrada"), inclua todas as informações até o momento e veja se eles têm uma idéia para depurar isso.

Uma solução alternativa possível é ativar de alguma forma o dispositivo HID legado, pois isso é mais semelhante ao teclado USB normal e pode funcionar imediatamente. Existem algumas teclas ou combinações de teclas no teclado que parecem fazer isso?

    
por 12.06.2017 / 14:40