Niri 屏幕共享功能故障分析与解决方案

问题现象

在使用 Niri 窗口管理器时，用户报告屏幕共享功能出现异常：当尝试通过 Discord 或 Firefox（Google Meet）进行屏幕共享时，系统仅捕获并传输第一帧画面，后续画面保持静态不变。这一问题在 Niri 25.02 版本及 2025 年 4 月 1 日的构建版本中均存在。

技术背景

Niri 是一个基于 Wayland 的可滚动平铺窗口管理器，其屏幕共享功能依赖于 PipeWire 多媒体框架和 xdg-desktop-portal 实现。在 Wayland 环境下，屏幕共享通常通过以下组件协同工作：

1. 窗口管理器：负责提供屏幕内容
2. PipeWire：处理多媒体流传输
3. xdg-desktop-portal：提供标准化的桌面服务接口
4. D-Bus：用于组件间通信

问题分析

从日志和用户反馈来看，屏幕共享流程能够正常启动，PipeWire 流也能进入 Streaming 状态，但实际传输的画面却停滞在第一帧。这表明：

1. 初始帧捕获成功，说明基础功能正常
2. 后续帧更新机制失效，可能是帧同步或数据传输环节出现问题
3. 问题同时出现在 Mutter 和 wlr 两种 portal 实现中，说明问题可能出在更底层的共享机制

深入调查

多位用户报告了类似问题，其中一位用户发现：

1. 使用 Niri 25.01 版本时功能正常
2. 在 NixOS 环境下，当混合使用稳定版和不稳定版软件包时容易出现此问题
3. 特别是当覆盖构建依赖关系（如 libgbm 和 mesa）时，问题会显现

这表明问题可能与运行时环境或依赖版本不匹配有关，而非 Niri 本身的代码缺陷。

解决方案

经过验证，以下方法可以解决此问题：

1. 保持依赖一致性：确保所有相关软件包（特别是图形驱动和多媒体组件）来自同一发行版通道
2. 避免手动覆盖构建输入：特别是 libgbm、mesa 和 pipewire 等关键组件
3. 使用标准配置：在 NixOS 中，直接使用发行版提供的 Niri 包而非自定义构建

技术建议

对于基于 NixOS 的用户，建议：

1. 避免混合使用不同稳定性的软件源
2. 如需使用新功能，建议整体切换到不稳定通道，而非选择性覆盖个别软件包
3. 特别注意图形栈（驱动、Wayland 组件、多媒体框架）的版本一致性

总结

屏幕共享功能停滞问题通常源于运行时环境的不一致性，特别是在 NixOS 这类提供细粒度包管理的发行版中。保持系统组件版本的一致性，避免手动覆盖关键依赖，是确保 Wayland 环境下屏幕共享功能正常工作的关键。虽然问题表现看似复杂，但解决方案相对简单，体现了 Linux 桌面环境中依赖管理的重要性。