Relação do layout do teclado e do xmodmap

Estou usando o Xubuntu. Antes do login, posso escolher um layout de teclado. Estou usando xmodmappara remapear algumas chaves.

Estou interessado em duas coisas:

1. Como o estado do mapeamento do teclado muda (a) quando ligo o laptop, (b) durante o processo de inicialização e (c) efetuo login no sistema (nessas três fases) e ao trabalhar com o sistema (logado).
2. O que causa quais símbolos serão exibidos na tela (e as teclas de controle enviadas) durante as fases individuais. Quando pressiono alguma tecla, ele envia algum sinal ao driver do teclado (?) E, em seguida, deve haver algum processo de decisão (aplicativos e arquivos de configuração) determinando quais símbolos serão exibidos. A resposta a esta pergunta deve ser a lista de aplicativos e caminhos para esses arquivos de configuração (estou especialmente interessado no Ubuntu (sistema baseado no Debian), mas você pode descrever outro sistema, mas o Ubuntu é o preferido.

Existem duas camadas aqui, mapeamento de KEYCODE para KEYSYM e KEYSYM para mapeamento de texto. Existem mais camadas, se você contar o kernel, que precisa mapear os scancodes do AT Keyboard para um código-chave do estilo XT ou um código HID do teclado USB para um código-chave. Um KEYCODE é simplesmente um número inteiro não assinado de 8 bits que o kernel de um sistema operacional passa para o servidor X11. Pode variar entre sistemas operacionais, como Linux e Solaris. No Linux, esses KEYCODEs são normalmente o mesmo número usado nos antigos XT PC Keyboards. Os computadores mais novos com teclados AT, PS / 2 ou USB normalmente apenas mapeiam esses teclados para o código XT antigo, a fim de manter a vida simples.

Os códigos brutos do teclado, sejam XT, AT, PS / 2 ou USB, representam um local físico no teclado. O teclado XT envia apenas um único número de 8 bits ao pressionar ou soltar uma tecla. A tecla q em um teclado XT americano / britânico envia o número 16. Em um teclado francês, a mesma tecla física é rotulada como a, mas ainda envia 16. São as camadas mais altas do sistema operacional que lhe atribuem um significado real. Quando uma tecla é liberada em um teclado XT, o mesmo código é enviado mais 128. Neste exemplo, quando q é pressionado, um 16 é enviado, mas no lançamento, o número 142 (16 + 128) é enviado. Os teclados AT usam scancodes, que são uma série de números e podem demorar bastante. As principais liberações adicionam códigos adicionais. Por exemplo, o scancode para Pause é E1, 1D, 45, E1, 9D, C5. A maioria dos sistemas operacionais, incluindo DOS, Windows, Linux, FreeBSD, e o BIOS mapeia scancodes em scancodes muito mais simples no estilo XT. Também facilita o suporte a teclados mais recentes que usam códigos diferentes, como teclados USB que enviam códigos HID. Todos os códigos são mapeados para o mesmo conjunto consistente de códigos pelo sistema operacional antes do X11 ou o aplicativo os vê.

O X11 ignora essa parte do processo, apenas obtém o KEYCODE do kernel e aplica seu próprio mapeamento para converter esse KEYCODE em um KEYSYM. Xmodmap é a ferramenta padrão para controlar esse mapeamento. Grande parte do comportamento do mapeamento do teclado é configurável, mas há vários casos especiais, como Num Lock, Mode Switch e Caps Lock / Shift Lock, que são codificados no X11. Outros aspectos, como o Shift, são configuráveis. Qualquer tecla pode ser mapeada para atuar como shift, ao contrário do Switch de modo ou do Num Lock.

KEYCODEs representam chaves físicas enviadas pelo kernel do sistema operacional. Cada KEYCODE pode mapear para 8 possíveis KEYSYMs. Apenas 4 são usados ​​e às vezes são chamados de níveis 1-4. O nível 1 especifica o KEYSYM que é impresso quando nenhum modificador está ativo. Geralmente, são letras minúsculas e dígitos. Modificadores são KEYCODEs que modificam o KEYSYM gerado por outros KEYCODEs quando o modificador está ativo (pressionado ou ativado). Os códigos de chave do modificador também são controlados pelo Xmodmap. O nível 2 especifica um KEYSYM a ser enviado quando o modificador de turno é pressionado. O nível 3 é ativado sempre que o interruptor de modo KEYSYM for pressionado. O nível 4 é ativado quando uma tecla Shift e a chave de modo estão ativas.

Depois que um KEYSYM for gerado, isso poderá ser interpretado diretamente, mas na maioria das vezes será convertido em texto. Nem todos os KEYSYMs se transformam em texto ou podem afetar apenas um futuro KEYSYM. Um exemplo é Shift_L, é claro, que não possui representação textual, mas também existem vários KEYSYMs usados ​​para compor outro caractere. Uma lista deles no meu sistema está abaixo /usr/share/X11/locale/en_US.UTF-8/Compose. Um exemplo é o KEYSYM dead_acute que, quando pressionado, tentará converter o próximo KEYSYM em uma letra acentuada aguda. Existe um mapeamento padrão para transformar KEYSYMs em Unicode.

Agora que tudo isso foi dito, observe que o Xmodmap é obsoleto e substituído pelo XKB, que é muito mais sofisticado. Isso afeta como os KEYCODEs são mapeados para KEYSYMs, mas não como o kernel gera KEYCODEs, nem como KEYSYMs são convertidos em texto ou compostos, que ainda é o mesmo. O XKB pode ser desativado, restaurando o comportamento do Xmodmap. Ele também possui uma camada de compatibilidade para oferecer suporte ao Xmodmap, mas pode ter problemas, pois não é totalmente compatível. As regras XKB estão abaixo /usr/share/X11/xkb/e são muito mais sofisticadas. Há alguma boa documentação em outro lugar sobre como ele gera layouts de teclado para mapear KEYCODEs para KEYSYMs.

Quanto ao console do Linux, ele possui seus próprios layouts de teclado, que são armazenados /usr/share/keymapse carregados com o loadkeyscomando. Quando está nos estágios do BIOS e do carregador de inicialização anterior, incluindo o GRUB2, o mapeamento do teclado é o número que o BIOS decide mapear a chave.