Niri窗口管理器中的键盘事件传递机制分析

Niri作为一款现代化的Wayland合成器，在处理键盘事件时采用了独特的机制。近期发现的一个有趣现象揭示了该合成器在关闭过程中键盘事件传递的一个边界情况。

问题现象

当用户在Niri合成器运行时按下Enter键关闭合成器，该Enter键事件不仅会触发合成器的关闭操作，还会被传递给后台运行的应用程序。这一现象在文件管理器场景下尤为明显——如果用户恰好在文件管理器中选中了视频文件，关闭Niri时按下的Enter键会同时触发视频文件的播放。

技术背景

Wayland协议规定，键盘事件应当由合成器负责管理和分发。Niri作为合成器，需要正确处理以下关键流程：

1. 键盘事件捕获
2. 焦点窗口判断
3. 事件分发机制
4. 合成器自身快捷键处理

在正常操作中，Niri会优先拦截系统级快捷键（如关闭合成器），然后将剩余事件传递给当前焦点窗口。然而在关闭过程中，事件队列的处理出现了时序问题。

根本原因分析

通过代码审查发现，问题源于7b18ff8870c2610b3d532afef81a387a7a3f21d3提交修复的一个键盘事件处理逻辑缺陷。具体表现为：

1. 合成器在接收到关闭指令后，没有立即终止事件处理循环
2. 键盘事件缓冲区中的未处理事件在合成器关闭过程中被释放到系统
3. DRM/KMS层将这些事件传递给了保持活跃的客户端应用程序

这种边界情况在Intel HD 4000等集成显卡环境下更容易复现，因为其DRM驱动对事件传递的处理较为宽松。

解决方案与改进

修复方案主要包含以下关键点：

1. 在合成器关闭序列开始时立即刷新键盘事件缓冲区
2. 增加事件处理循环的提前终止检查
3. 完善DRM后端的事件清理机制

这些改进确保了合成器在关闭过程中能够正确处理残留的键盘事件，避免意外传递给客户端应用程序。

开发者启示

这个案例为Wayland合成器开发提供了重要经验：

1. 合成器生命周期管理需要与事件处理深度集成
2. 键盘事件的处理应当考虑各种边界条件
3. DRM/KMS后端的行为差异需要被充分考虑

对于使用Niri的开发者而言，理解这一机制有助于编写更健壮的Wayland客户端应用程序，特别是在处理全局快捷键和合成器交互时。

该修复已包含在Niri 0.1.10之后的版本中，用户升级后即可避免此类键盘事件传递问题。