Niri项目下Firefox与Chromium屏幕共享失败问题分析与解决方案

问题现象

在Niri窗口管理器环境下，用户报告使用Snap打包版本的Firefox和Chromium浏览器进行WebRTC屏幕共享时出现"no more input formats"错误。具体表现为：

1. 能够正常弹出屏幕选择界面（xdg-desktop-portal-gnome提供）
2. 选择屏幕/窗口后无视频流返回
3. 日志显示格式协商失败
4. 非Snap应用（如LibreWolf、Discord、OBS等）工作正常

根本原因分析

经过排查发现，该问题主要由以下因素共同导致：

1. Snap容器限制：

   • Snap的严格沙盒机制限制了浏览器对底层图形管道的访问
   • 无法正确识别NVIDIA专有驱动（550.120版本）
   • 导致回退到软件渲染模式

2. 格式协商失败：

   • 由于硬件加速不可用，浏览器无法提供有效的视频采集格式
   • PipeWire在格式协商阶段返回错误

3. 门户服务交互异常：

   • 虽然能启动xdg-desktop-portal对话框
   • 但后续的DMA-BUF/EGLStreams传输通道建立失败

解决方案

推荐方案

1. 移除Snap版浏览器：

   sudo snap remove firefox chromium
   

2. 安装原生.deb包：
   • 通过官方PPA或下载直接安装
   • 确保使用系统级图形驱动

验证步骤

1. 安装后检查浏览器about:support页面
   • 确认"Compositing"显示为"OpenGL"
   • 而非"Basic"（软件渲染）
2. 测试WebRTC示例页面
   • 应能正常捕获并传输屏幕内容

技术背景补充

Niri与屏幕共享机制

Niri作为Wayland合成器，通过以下组件实现屏幕捕获：

1. PipeWire：负责多媒体管道管理
2. XDG桌面门户：提供标准化的捕获接口
3. DMA-BUF：高效的内存缓冲区共享机制

Snap的限制

Snap应用默认使用严格沙盒，会导致：

1. 无法直接访问GPU设备文件
2. 受限的IPC通信能力
3. 特殊的XDG_RUNTIME_DIR路径映射

最佳实践建议

1. 在Wayland环境下优先选择原生打包应用
2. 开发测试时注意区分Snap/Flatpak环境差异
3. 对于必须使用容器化浏览器的场景：
   • 可尝试调整snap权限
   • 但稳定性无法保证

总结

该案例展示了Snap容器在Wayland复杂图形场景下的兼容性问题。通过改用原生安装包，不仅解决了屏幕共享问题，还能获得更好的图形性能表现。建议Wayland用户谨慎选择软件分发格式，特别是在涉及硬件加速的多媒体应用场景中。