Linux系统下xmodmap修饰键（modifiers）的工作原理是什么？

基础运作逻辑 #

X窗口系统的键盘输入处理分为三层独立的映射链路：

1. 物理按键按下后首先生成固定的keycode：和硬件直接绑定，同一个物理按键的keycode不会随配置变化，比如原生左Ctrl键按下永远上报keycode 0x25
2. keycode映射为keysym：就是通过keycode 0xXX = 名称命令修改的部分，定义了按键对应的符号身份，比如把0x25的映射改成Caps_Lock，那这个按键按下后上报的符号名就是Caps_Lock
3. 修饰键绑定：也就是xmodmap -pm输出的映射表，本质是keysym到修饰位的映射规则。X服务端会根据当前按下按键的keysym，匹配该表给输入事件打上对应的修饰位标记，所有应用程序都是读取这个修饰位标记来判断用户是否按下了修饰键，而非直接读取keysym或物理按键信息。

常见疑问解答 #

1. 交换Caps Lock和Control时，为什么改完keysym还要配置修饰键？ #

只修改keycode到keysym的映射，只是给按键改了个“名字”，如果对应的keysym没有被加入到对应修饰组里，X服务端不会给事件打上对应的修饰位标记，功能就不会生效。
比如你把原生左Ctrl的keysym改成了Caps_Lock，但如果Caps_Lock这个keysym没有被加入到lock修饰组，X不会给后续输入事件打大小写锁定的修饰标记，应用也不会触发大小写切换的逻辑。交换按键的配置中，add命令就是把新映射的keysym加入到对应的修饰组，保证修饰功能正常生效。

2. 执行clear lock、clear control后，对应按键仍然正常工作是为什么？ #

当前主流Linux发行版（包括你用的Ubuntu）默认使用XKB（X键盘扩展）作为优先的键盘管理方案，xmodmap只是作为XKB的兼容层存在。你通过xmodmap执行的clear操作只会修改兼容层的临时映射表，不会改动XKB本身的修饰规则，X服务端和桌面环境优先读取XKB的配置，所以按键功能不会受影响。

3. 把Shift_L/Shift_R加入control修饰组后不生效是什么原因？ #

还是XKB优先级更高导致的。xmodmap修改的修饰绑定会被XKB的内置规则覆盖，你用xev检测到的修饰位是XKB输出的结果，自然不会按照xmodmap的配置变化。如果需要xmodmap的修饰配置生效，需要先关闭XKB的修饰重写规则，或者直接使用XKB的配置逻辑完成改键需求。

内容的提问来源于stack exchange，提问作者DeanSinaean