核心分析¶

项目定位：niri 以原生 Wayland compositor 的方式从零实现（采用 Rust），以获得对坐标、渲染与输入的完全控制，同时借助 wlr 协议兼容生态实现常用功能。

技术特点¶

• 架构控制：原生实现避免了在宿主 Shell 的全局坐标空间下做折衷，能在显示器隔离、溢出控制与工作区语义上做到一贯行为。
• Rust 的安全性与工具链：内存安全减少系统级崩溃风险；测试（随机化属性测试）、性能剖析与输入延迟测量容易集成，利于长期稳定性。
• 模块化协议兼容：通过 wlroots/wlr 协议栈兼容 layer-shell、screencopy、gamma-control 等，既复用现有功能又能保持 compositor 层的主导权。

使用建议¶

1. 在评估时关注硬件/驱动兼容性（尤其 NVIDIA）并运行作者提供的性能和延迟测量脚本。
2. 利用项目的测试与配置示例作为稳定性基准，逐步把日常工作流迁移到 niri 上。

重要提示：原生实现带来更强的控制权，但也意味着用户需承担比使用成熟 DE 更高的配置责任（状态栏、面板、扩展集成需自行搭建）。

总结：选择原生 Wayland + Rust 能在架构层面提供更严谨的语义（显示器隔离、无重排）、更高的内存安全与更易测量的性能特性，是面向长期可靠桌面体验的合理技术决策。

核心分析¶

问题核心：决定是否优先选择 niri，应基于你对多显示器可预测性、混合 DPI 的像素完美性与可视定制（动画/着色器）的需求权衡。

适用场景（优先选择 niri）¶

• 你是高级 Wayland 用户，依赖键盘/平铺工作流，且常在多显示器或混合 DPI 环境下工作。
• 需要窗口不随新窗口重排、显示器隔离和工作区断连/重连语义保持的情形（内容创作、多屏开发）。
• 希望在 compositor 层实现渐变边框、自定义着色器与细粒度动画控制的高级用户。

限制与替代方案考虑¶

• 不是完整 DE：需自行配置状态栏/面板（如 waybar）、通知与小部件；若要开箱即用，GNOME/KDE 更合适。
• 触控支持不足：触摸屏手势不完善，移动设备或触控优先工作流不推荐使用 niri。
• X11 兼容性：依赖 xwayland-satellite，对于极端 X11 特性或老旧应用可能存在问题——此类场景可考虑在 X11 下继续使用 i3 或传统 X11 WM，或使用成熟的 Wayland 兼容层。
• 替代方案对比：
• GNOME + PaperWM：易用性高但受 GNOME 全局坐标限制，可能出现溢出；适合希望在 GNOME 生态内尝试滚动平铺的用户。
• i3/i3-like (Wayland 变体)：成熟、脚本友好，适合需要极致键盘控制但不注重动画/着色器的用户。

重要提示：选择前在非生产环境对比关键用例（多显示器迁移、录屏、X11 应用）以确认满足需求。

总结：若你的核心需求是可预测的多显示器滚动平铺、像素完美 UI 与 compositor 级别的隐私/录屏控制，niri 是优先选择；若你需要开箱即用的桌面、完整触控体验或对 X11 兼容性有严格要求，则应考虑 GNOME/KDE、i3 或其他成熟方案作为替代。

核心分析¶

项目定位：niri 将录屏/投屏集成到 compositor 层并借助 xdg-desktop-portal-gnome 提供权限与数据通道，同时允许在录屏流中屏蔽敏感窗口或动态改变投屏目标。

技术分析¶

• 实现原理：
• niri 使用 Wayland 的 screencopy 协议并通过 xdg-desktop-portal-gnome 处理权限与会话；
• 在 compositor 层可为窗口设定屏蔽标记，portal 请求流时返回过滤后的图像或替代内容；
• 动态 cast target 特性允许运行时切换投屏源（窗口/显示器）或修改屏蔽规则。
• 依赖与限制：
• 功能依赖于用户空间组件（portal）的正确安装与权限配置；
• 错误配置或权限不足会导致录制失败或屏蔽无效。

实用建议（配置步骤）¶

1. 安装并启用 xdg-desktop-portal-gnome（并确保 portal 后台服务在会话中运行）。
2. 按 README 使用 niri 的截图/录屏 UI 测试录制与屏蔽行为，先在本地试验敏感窗口标记是否生效。
3. 在多用户或受限环境中，验证 portal 的权限策略（Flatpak/Sandbox 的权限）以避免录屏中断。

重要提示：不要在未确认屏蔽生效前进行实际敏感内容录制；在关键场景先做本地试验并保留回滚配置。

总结：niri 在 compositor 层面就支持录屏隐私，但其可靠性高度依赖 xdg-desktop-portal-gnome 的正确配置与权限管理。务必按照项目说明逐项验证屏蔽行为。

核心分析¶

项目定位：niri 使用 xwayland-satellite 来集成 X11 支持（自 niri 25.08 起），并声称 NVIDIA “seems to work fine”，但实际兼容性受驱动与 Xwayland 后端实现影响。

技术分析¶

• X11 支持：xwayland-satellite 可显著改善 X11 应用与 Wayland compositor 的互操作，但仍可能遇到：窗口缩放/位置异常、输入焦点问题、硬件加速或 GL 上下文差异等边缘情况。
• NVIDIA 驱动：专有驱动涉及 EGL/GBM/DRM 接口选择。某些驱动与 Wayland 后端的组合（如 GBM vs EGLStreams）可能导致性能或兼容性问题。

诊断与修复步骤¶

1. 收集日志：查看 journalctl -b 和 niri/Xwayland 日志，查找 EGL/GBM/NVIDIA 相关错误。记录时间戳以便复现。
2. 复现测试：使用作者提供的性能与延迟测量脚本或在最小配置下启动典型 X11 应用以复现问题。
3. 调整后端与驱动：尝试不同的 Xwayland 后端参数或更新 NVIDIA 驱动；若使用专有驱动，查阅发行版关于 Wayland 的建议（例如启用/禁用 GLVND、切换 GBM）。
4. 回滚与快照：在有效配置下保存启动/配置快照，便于回退。
5. 求助与报告：在定位日志后向 niri 项目提供复现步骤与日志以便开发者调试。

重要提示：在关键生产系统上先用次级账户或备份环境验证驱动相关改动，避免误操作导致无法登录会话。

总结：niri 提供了 X11 与 NVIDIA 的支持路径，但实际稳定性取决于特定驱动与配置。系统性诊断（日志+最小复现）与配置快照是应对兼容性问题的关键做法。