Relación de la distribución del teclado y xmodmap

Estoy usando Xubuntu. Antes de iniciar sesión puedo elegir una distribución de teclado. Estoy usando xmodmappara reasignar algunas teclas.

Me interesan dos cosas:

1. Cómo cambia el estado de la asignación del teclado (a) cuando enciendo la computadora portátil, (b) durante el proceso de inicio y (c) inicio sesión en el sistema (en estas tres fases) y cuando trabajo con el sistema (conectado).
2. Qué causa qué símbolos se mostrarán en la pantalla (y las teclas de control enviadas) durante las fases individuales. Cuando presiono alguna tecla, envía una señal al controlador del teclado (?) Y luego debe haber algún proceso de decisión (aplicaciones y archivos de configuración) que determine qué símbolos se mostrarán. La respuesta a esta pregunta debería ser la lista de aplicaciones y rutas a esos archivos de configuración (estoy especialmente interesado en Ubuntu (sistema basado en Debian), pero puede describir algún otro sistema, pero se prefiere Ubuntu).

Aquí hay dos capas: KEYCODE to KEYSYM mapping y KEYSYM to text mapping. Hay más capas si cuenta el núcleo, que tiene que asignar códigos de escaneo del teclado AT a un CÓDIGO DE TECLA XT o un código HID del teclado USB a un CÓDIGO DE TECLA. Un KEYCODE es simplemente un entero sin signo de 8 bits que el núcleo de un sistema operativo pasa al servidor X11. Puede variar entre sistemas operativos como Linux y Solaris. En Linux, estos CÓDIGOS CLAVE son típicamente el mismo número utilizado en los antiguos teclados de PC XT. Las computadoras más nuevas con teclados AT, PS / 2 o USB generalmente solo asignan esos teclados al antiguo código XT para obtener la clave para simplificar la vida.

Los códigos de teclado sin formato, ya sean XT, AT, PS / 2 o USB, representan una ubicación física en un teclado. El teclado XT solo envía un único número de 8 bits al presionar o soltar una tecla. La tecla q en un teclado XT estadounidense / británico envía el número 16. En un teclado francés, esa misma tecla física está etiquetada como a, pero aún envía 16. Son las capas superiores del sistema operativo las que le asignan un significado real. Cuando se suelta una tecla en un teclado XT, se envía el mismo código de tecla más 128. Para este ejemplo, cuando se presiona q, se envía un 16, pero al soltar, se envía el número 142 (16 + 128). Los teclados AT usan códigos de escaneo que son una serie de números y pueden ser bastante largos. Los comunicados clave agregan códigos adicionales. Por ejemplo, el código de exploración para Pausa es E1, 1D, 45, E1, 9D, C5. La mayoría de los sistemas operativos, incluidos DOS, Windows, Linux, FreeBSD, y el BIOS asigna todos los códigos de escaneo en códigos de escaneo mucho más simples de estilo XT. También hace que sea más fácil admitir teclados más nuevos que usan códigos diferentes, como teclados USB que envían códigos HID. El sistema operativo asigna todos los códigos al mismo conjunto de códigos consistentes antes de X11 o la aplicación los ve.

X11 ignora esta parte del proceso, solo obtiene el KEYCODE del kernel y aplica su propia asignación para convertir ese KEYCODE en un KEYSYM. Xmodmap es la herramienta estándar para controlar esa asignación. Gran parte del comportamiento del mapeo del teclado es configurable, pero hay varios casos especiales como Num Lock, Mode Switch y Caps Lock / Shift Lock que están codificados en X11. Otros aspectos como Shift son realmente configurables. Cualquier tecla se puede asignar para actuar como cambio, a diferencia del cambio de modo o bloqueo numérico.

Los CÓDIGOS CLAVE representan claves físicas enviadas por el núcleo del sistema operativo. Cada KEYCODE puede mapearse a 8 KEYSYM posibles. Solo se usan 4 y a veces se llaman niveles 1-4. El nivel 1 especifica el KEYSYM que se imprime cuando no hay modificadores activos. A menudo son letras minúsculas y dígitos. Los modificadores son KEYCODE que modifican el KEYSYM generado por otros KEYCODE cuando el modificador está activo (presionado o activado). Los códigos de modificación también se controlan a través de Xmodmap. El nivel 2 especifica un KEYSYM que se enviará cuando se presione el modificador de cambio. El nivel 3 se activa cada vez que se presiona el interruptor de modo KEYSYM. El nivel 4 se activa cuando una tecla de mayúsculas y un interruptor de modo están activos.

Una vez que se ha generado un KEYSYM, esto se puede interpretar directamente, pero la mayoría de las veces se convertirá en texto. No todos los KEYSYM se convierten en texto o solo pueden afectar a un KEYSYM futuro. Un ejemplo es Shift_L, por supuesto, que no tiene representación textual, pero también hay una serie de KEYSYM que se utilizan para componer otro personaje. Una lista de ellos en mi sistema está debajo /usr/share/X11/locale/en_US.UTF-8/Compose. Un ejemplo de ello es el dead_acute KEYSYM que, cuando se presiona, intentará convertir el siguiente KEYSYM en una letra aguda acentuada. Existe un mapeo estándar para convertir KEYSYMs en Unicode.

Ahora que se ha dicho todo esto, tenga en cuenta que Xmodmap es obsoleto y reemplazado por XKB, que es mucho más sofisticado. Esto afecta la forma en que los KEYCODE se asignan a KEYSYM, pero no cómo el núcleo genera KEYCODE ni cómo los KEYSYM se convierten en texto o se componen, lo que sigue siendo el mismo. XKB puede desactivarse restaurando el comportamiento de Xmodmap. También tiene una capa de compatibilidad para admitir Xmodmap, pero puede tener problemas ya que no es completamente compatible. Las reglas de XKB están bajo /usr/share/X11/xkb/y son mucho más sofisticadas. Hay otra buena documentación en otra parte sobre cómo genera diseños de teclado para asignar KEYCODE a KEYSYMs.

En cuanto a la consola de Linux, tiene sus propios diseños de teclado que se almacenan /usr/share/keymapsy cargan con el loadkeyscomando. Cuando se encuentra en el BIOS y en las etapas anteriores del cargador de arranque, incluido GRUB2, la asignación del teclado es el número al que el BIOS decide asignar la clave.