Niri项目中的Xwayland全屏窗口冻结问题分析

在Niri项目中，用户报告了一个关于Xwayland全屏窗口的有趣问题。当用户创建一个Xwayland窗口（无论是通过rootful Xwayland还是xwayland-satellite）并将其设置为全屏模式（不仅仅是最大化）时，显示器会出现画面冻结现象。值得注意的是，其他显示器工作正常，Niri本身也没有冻结。杀死Xwayland进程并不能解决问题，但通过关闭显示器电源再重新唤醒可以解除冻结状态。

问题现象

用户在使用Nvidia RTX 2060显卡和Intel i5-7600K处理器的NixOS系统上遇到了这个问题。具体表现为：

• 显示器画面冻结，但系统仍在运行
• 可以切换工作区、移动窗口（包括跨显示器移动）
• 显示器仍显示应用程序的冻结帧
• 通过电源管理命令关闭再开启显示器可以暂时解决问题

有趣的是，这个问题在使用gamescope时不会出现，暗示这可能与特定的渲染路径或显示管理方式有关。

技术分析

通过详细的日志分析，我们发现问题的核心在于直接扫描输出（direct scan-out）机制。当Xwayland窗口全屏时，系统尝试将其内容直接扫描输出到显示器，而不是通过常规的合成路径。日志显示：

1. 系统成功接收了CRTC 55（DP-1）的vblank事件
2. 将Wayland表面分配给主平面
3. 成功排队了页面翻转操作
4. 测试直接扫描输出的原子提交没有失败

然而，在此之后，系统再也没有接收到该CRTC的vblank事件，导致显示冻结。这表明问题可能出在驱动程序层面，特别是在处理直接扫描输出时的vblank事件处理上。

解决方案

目前有两种可行的解决方案：

1. 临时解决方案：在配置文件中添加以下设置可以解决问题：

   debug {
       disable-direct-scanout
   }
   

   这会禁用直接扫描输出功能，强制系统使用常规的合成路径。

2. 根本解决方案：Smithay项目已经提交了一个修复（PR #1501），更新后的版本应该能解决这个问题。Niri项目已经将Smithay更新到包含该修复的提交。

深入理解

直接扫描输出是一种优化技术，允许应用程序的缓冲区直接发送到显示控制器，绕过合成器。这可以减少延迟和CPU/GPU负载，特别是在全屏应用程序中。然而，这种技术高度依赖驱动程序的正确实现。

在Nvidia显卡上，特别是与Xwayland结合使用时，可能会出现兼容性问题。日志中显示系统尝试使用"legacy fbadd"（传统帧缓冲区添加）方法，这可能表明驱动程序对新特性的支持不完全。

结论

这个问题展示了在Wayland合成器中处理不同硬件和驱动程序组合时的复杂性。虽然直接扫描输出是一个有价值的优化，但在某些配置下可能导致问题。开发者通过提供配置选项和底层修复，为用户提供了灵活性和稳定性之间的选择。

对于遇到类似问题的用户，建议：

1. 首先尝试禁用直接扫描输出
2. 确保使用最新的驱动程序和Niri版本
3. 关注相关项目的更新，特别是Smithay的修复进展

这个问题也提醒我们，在复杂的图形栈中，硬件、驱动程序和合成器之间的交互需要仔细的测试和调优，特别是在涉及Xwayland这样的兼容层时。