☰

Remapeamento do teclado em uma "camada inferior" no X

tag-icon • tag-icon x11 keyboard
Remapeamento do teclado em uma "camada inferior" no X

Os mapas de teclas têm um fluxo semelhante ao modelo OSI, embora não tão bem definido. Atualmente estou remapeando em um nível mais alto do que gostaria. Obviamente, a Camada 1 corresponde ao teclado físico e a Camada 7 ao aplicativo, mas não tenho certeza de quantas outras camadas existem ou onde elas se alinham.

Se este fosse um desktop com um teclado físico programável dedicado, eu estaria pronto, mas, infelizmente, é um laptop e preciso manter os remapeamentos enquanto uso o teclado integrado.

FWIW, estou trocando os seguintes pares de chaves: [Tilde/Esc], [Caps/LCtrl], [Back{space,slash}]. Eu também uso o Dvorak, mas ele está configurado no SO da maneira padrão.

Atualmente, estou modificando /usr/share/X11/xkb/keycodes/evdev para fazer minhas alterações no X (e criar um arquivo de layout personalizado para consoles, mas isso não é relevante aqui). Não tenho certeza de onde isso se enquadra na "pilha de camadas".

O problema:Meu mapa de teclado não se traduz em sessões do console Proxmox, que usa um cliente web VNC. (O layout também não se aplica, mas isso é esperado.) O problema é claramente que o cliente VNC está conectando o teclado em uma camada inferior onde o remapeamento do evdev ainda não foi aplicado.

No Windows, eu uso um utilitário chamado KeyTweak para gerar mapas de scancode para o registro, que parece ser basicamente a “Camada 3”. Joguei jogos que aparentemente prenderam o teclado na “Camada 2”, mas isso não é um problema, já que há muito pouca digitação na maioria dos jogos.

Para concluir, não tenho certeza de onde o evdev se enquadra no meu modelo imaginário de teclado OSI, mas como posso remapear em uma camada inferior? Não preciso sair do remapeamento por nenhum motivo, então essa mudança pode ser basicamente permanente. Se eu pudesse fazer isso na BIOS, eu faria.

Responder1

A resposta acabou sendo udev. Eu basicamente seguiesta postagem, mas a essência é:

  • Instalarevtest
  • Execute evteste pressione as teclas que deseja remapear para verambosos scancodes e códigos de acesso.
  • Crie um novo arquivo com /etc/udev/hwdb.d/um nome semelhante 70-keyremap.hwdbao conteúdo abaixo
    • Presumo que o número seja a ordem do arquivo, mas não tinha nenhum arquivo existente para baseá-lo, então não tenho certeza de quais são os pré-requisitos para que ele precise ter um número maior. Na verdade, o hwdb.ddiretório não existia para mim no Tumbleweed, então tive que criá-lo, mas ainda funcionou.
  • Correr systemd-hwdb update.
  • Reinício

_

# This is from the brokkr.net post I linked above
# Format can be found on [https://wiki.archlinux.org/title/Map_scancodes_to_keycodes].

$ cat 70-keymap.hwdb
evdev:atkbd:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr*
 KEYBOARD_KEY_01=41     # Remap Tilde to Esc
 KEYBOARD_KEY_29=01     # Remap Esc to Tilde (evtest showed "1" but when I put that without the leading zero, it was interpreted as the literal [1] key.)
 KEYBOARD_KEY_3A=29     # Remap Caps to LCtrl
 KEYBOARD_KEY_1D=58     # Remap LCtrl to Caps
 KEYBOARD_KEY_0E=43     # Remap Backspace to Backslash
 KEYBOARD_KEY_2B=14     # Remap Backslash to Backspace

Atualizar: O método acima funcionou muito bem no meu laptop, mas quando o encaixei, os teclados externos ainda usavam o mapa de teclado padrão. Acontece que isso ocorre porque o teclado interno está se comunicando usando PS/2, que ainda usa os scancodes AT ( atkbdna string do dispositivo), mas o USB é totalmente diferente. Acabei tendo que executar o evtest novamente para pegar os scancodes de uma placa USB e escrever outro mapa. Aqui está meu arquivo resultante:

evdev:atkbd:dmi:*
 KEYBOARD_KEY_01=41
 KEYBOARD_KEY_29=01
 KEYBOARD_KEY_3A=29
 KEYBOARD_KEY_1D=58
 KEYBOARD_KEY_0E=43
 KEYBOARD_KEY_2B=14

evdev:input:b0003v*
 KEYBOARD_KEY_70029=41
 KEYBOARD_KEY_70035=01
 KEYBOARD_KEY_70039=29
 KEYBOARD_KEY_700e0=58
 KEYBOARD_KEY_7002a=43
 KEYBOARD_KEY_70031=14

informação relacionada