xra*_*alf 12 login boot keyboard xmodmap keyboard-layout
我正在使用Xubuntu。在登录之前,我可以选择键盘布局。我正在xmodmap
用于重新映射一些键。
我对两件事感兴趣:
pen*_*359 26
这里有两层,KEYCODE到KEYSYM的映射和KEYSYM到文本的映射。如果算上内核,则有更多层,它必须将 AT 键盘扫描码映射到 XT 样式的 KEYCODE 或将 USB 键盘 HID 代码映射到 KEYCODE。KEYCODE 只是一个 8 位无符号整数,操作系统内核将其传递给 X11 服务器。它可能因 Linux 和 Solaris 等操作系统而异。在 Linux 上,这些 KEYCODE 通常与旧 XT PC 键盘上使用的数字相同。带有 AT、PS/2 或 USB 键盘的较新计算机通常只是将这些键盘映射到旧的 XT 代码以获取密钥以保持简单。
原始键盘代码,无论是 XT、AT、PS/2 还是 USB,都代表键盘上的物理位置。XT 键盘仅在按下或松开按键时发送一个 8 位数字。US/British XT 键盘上的 q 键发送数字 16。在法语键盘上,相同的物理键被标记为 a,但它仍然发送 16。操作系统中的更高层为其分配了真正的含义。当在 XT 键盘上释放一个键时,发送相同的键码加上 128。对于这个例子,当按下 q 时,发送一个 16,但在释放时,发送数字 142 (16+128)。AT 键盘使用由一系列数字组成的扫描码,并且可能会变得很长。关键版本添加了额外的代码。例如,暂停的扫描码是 E1, 1D, 45, E1, 9D, C5。大多数操作系统,包括 DOS、Windows、Linux、FreeBSD、并且 BIOS 都将扫描码映射为更简单的 XT 式扫描码。它还可以更轻松地支持使用不同代码的较新键盘,例如发送 HID 代码的 USB 键盘。在 X11 或应用程序看到它们之前,操作系统将所有代码映射到相同的一致代码集。
X11 对这部分过程一无所知,它只是从内核获取 KEYCODE 并应用自己的映射将该 KEYCODE 转换为 KEYSYM。 Xmodmap是控制该映射的标准工具。键盘映射的大部分行为都是可配置的,但有几种特殊情况,例如 Num Lock、模式切换和 Caps Lock/Shift Lock,它们被硬编码到 X11 中。Shift 等其他方面实际上是可配置的。与模式切换或数字锁定不同,任何键都可以映射为移位。
KEYCODE 代表操作系统内核发送的物理密钥。每个 KEYCODE 可以映射到 8 个可能的 KEYSYM。仅使用 4 级,有时称为 1-4 级。级别 1 指定在没有修饰符处于活动状态时打印的 KEYSYM。这些通常是小写字母和数字。修饰符是当修饰符处于活动状态(按下或打开)时修改由其他 KEYCODE 生成的 KEYSYM 的 KEYCODE。修饰键代码也通过 Xmodmap 进行控制。级别 2 指定按下 shift 修饰符时要发送的 KEYSYM。每当按下模式开关 KEYSYM 时,就会激活第 3 级。当 Shift 键和模式开关都处于活动状态时,级别 4 被激活。
生成 KEYSYM 后,可以直接对其进行解释,但通常会转换为文本。并非所有 KEYSYM 都会变成文本,或者可能只会影响未来的 KEYSYM。一个例子是 Shift_L,当然,它没有文本表示,但也有许多 KEYSYM 用于组合另一个字符。他们在我系统上的列表在/usr/share/X11/locale/en_US.UTF-8/Compose
. 一个这样的例子是 dead_acute KEYSYM,当按下它时,它会尝试将下一个 KEYSYM 转换为重音符号。有一个将 KEYSYM 转换为 Unicode的标准映射。
既然已经说了这么多,请注意 Xmodmap 已经过时,取而代之的是更复杂的 XKB。这会影响 KEYCODE 映射到 KEYSYM 的方式,但不影响内核生成 KEYCODE 的方式,也不影响 KEYSYM 转换为文本或组合的方式,这仍然是相同的。可以禁用 XKB 恢复 Xmodmap 行为。它还有一个兼容层来支持 Xmodmap,但它可能有问题,因为它不完全兼容。XKB 规则在下面/usr/share/X11/xkb/
并且更加复杂。其他地方有一些很好的文档,说明它如何生成用于将 KEYCODE 映射到 KEYSYM 的键盘布局。
至于 Linux 控制台,它有自己的键盘布局,这些布局存储在命令中/usr/share/keymaps
并随loadkeys
命令一起加载。在 BIOS 和更早的引导加载程序阶段(包括 GRUB2)中,键盘映射是 BIOS 决定将键映射到的任何数字。
归档时间: |
|
查看次数: |
3945 次 |
最近记录: |