teclas F1-F12 não funcionam

Question

Comprei um teclado compacto. F1 = Fn + 1 e F2 = Fn + 2 ... MasasteclasF1-F12nãofuncionamnomeuUbuntu16.04.Porexemplo,oF1aumentaobrilho.EuverifiqueicódigosdeteclasdeF1-F12eelessãoinválidos.EntãoF1retorna232códigodeacesso(emvezde67).

Eutenteicorrigi-lousando:xmodmap-e"keycode 232 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1" Mas isso não ajudou. F1 ainda muda o brilho. Eu tentei remapear outras chaves F1-F12 e nenhum resultado. O Xmodmap funciona apenas para chaves não funcionais.

É possível corrigir chaves F1-F12? (Códigos de teclas de swap?)

Xmodmap configurado correto, mas F1 ainda altera o brilho :

$ xmodmap -e "keycode 232 = F1 F1 F1 XF86Switch_VT_1" # IT DON'T HELP!!

$ xmodmap -pke # everything is OK!
keycode  67 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1 F1 F1 XF86Switch_VT_1
keycode 232 = F1 F1 F1 XF86Switch_VT_1

$xev # take a look: XKeysymToKeycode = 67... F1... everything is OK again...
KeyRelease event, serial 40, synthetic NO, window 0x5000001,
    root 0xf5, subw 0x0, time 921326, (236,-87), root:(236,403),
    state 0x0, keycode 232 (keysym 0xffbe, F1), same_screen YES,
    XKeysymToKeycode returns keycode: 67
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
$sudo evtest 
Event: time 1497517949.369064, -------------- SYN_REPORT ------------
Event: time 1497517949.458895, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 0

$ setxkbmap -print
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwerty)" };
    xkb_types     { include "complete"  };
    xkb_compat    { include "complete+ledscroll(group_lock)"    };
    xkb_symbols   { include "pc+us+inet(evdev)+capslock(swapescape)"    };
    xkb_geometry  { include "pc(pc105)" };
};

P.S. Também o F1-F12 funciona corretamente no Windows.

Atualização:

Obrigado @dirkt. Por favor, dê uma olhada nos detalhes:

1. eu uso o Ubuntu 16.04.1 LTS Unity
2. /dev/input/event11: RK61 Bluetooth keyboard
3. sudo lsof /dev/input/event11 output: acpid , Xorg
4. evtest --grab /dev/input/eventX result: você está certo, porque o brilho da tela do Laptop permanece o mesmo (pressionei Fn + 1 = > F1)!

Tentando eliminar o processo acpid :

5. sudo kill 757 // matando o processo acpid
6. sudo lsof /dev/input/event11 output: Xorg // OK acpid eliminado
7. Pressionando F1 - > O brilho está mudando! // FAIL

Aqui está o meu arquivo rdesc: link

Aqui está o hexdump: https: // pastebin.com/eT9mNnGV

Também tentei alterar o código via xkbcomp e isso não ajuda.

Por favor, escreva qualquer pensamento. Obrigado!

    

Answer 1

Resposta parcial: o mapeamento xmodmap funciona corretamente. Como mostra xev , você recebe keysym 0xffbe , que é F1 , como deveria ser.

Então a questão é (1) porque ainda muda o brilho e (2) porque retorna o código de tecla 232 (para KEY_BRIGHTNESSDOWN ) ao invés daquele para a tecla F1 (67).

Para (1), eu suspeito que o Ubuntu rode algo por padrão, o lê diretamente de /dev/input ao invés de processar eventos X, e isso está processando a chave não importa o que xmodmap diga. Você não disse qual ambiente de área de trabalho você executa (Gnome?). Você pode procurar com lsof para um processo que leia diretamente a /dev/input/eventX source (você obteve o número X de evtest , os números podem mudar entre as inicializações). Você também pode testar essa teoria executando evtest --grab /dev/input/eventX : Isso tornará evtest o programa exclusivo para processar os eventos, então quando você pressionar Fn + F1, ele ainda deverá mostrar KEY_BRIGHTNESSDOWN , mas o brilho do seu PC / Laptop tela deve permanecer o mesmo.

Quanto a (2), pesquisando o nome da marca mostra que é um teclado Bluetooth. Isso significa que é provável que seja um dispositivo HID. Você pode depurar o analisando dmesg para identificar o arquivo de dispositivo hidraw correspondente e o identificador bluetooth. Então faça

mount -t debugfs none /sys/kernel/debug

como root e dê uma olhada em sys/kernel/debug/hid/*/rdesc para o dispositivo correto (veja os subdiretórios disponíveis). Se você não conseguir entender, coloque-o em um pastebin e edite a pergunta com o link. Além disso, despeje eventos HID brutos usando hexdump -C /dev/hidrawX , pressionando Fn e F1, F2, etc. várias vezes. Isso deve lhe dar uma ideia do motivo pelo qual o kernel traduz isso da maneira como funciona.

Editar

Olhando para o dump do hidraw, o teclado produz corretamente os scancodes 3a , 3b etc. para as teclas de função, conforme descrito no descritor HID.

Portanto, o problema deve estar na camada de conversão HID para entrada.

Você pode interrogar essa camada via ioctls. Não há nenhuma ferramenta pública para isso, mas posso colocar uma no github quando estiver pronto.

A ica maneira de definir este mapeamento que eu conheo via o banco de dados udev hwdb como descrito, e. aqui .

Então, eu diria quem tem algum pacote instalado que fornece uma entrada de banco de dados para mapear F1 para controle de brilho, e que também fornece um programa para reagir a isso monitorando diretamente /dev/input/event* . Tente ver se você pode encontrá-lo em seu sistema. lsof pode ajudar.

    

Answer 2

Encontrei a solução aqui: link

change behaviour on the fly 
# echo 2 > /sys/module/hid_apple/parameters/fnmode 

or modify it in config 
[/etc/conf.d/modules] 
module_hid_apple_args="fnmode=2 iso_layout=0"