Niri项目在ARM架构设备上的DRM渲染问题解析

Niri作为一个基于Smithay的Wayland合成器，近期在ARM架构设备上遇到了DRM渲染问题。本文将深入分析该问题的技术背景、解决方案以及相关测试验证过程。

问题背景

在ARM架构设备上（包括Raspberry Pi系列和Apple M1/M2芯片），DRM子系统通常采用"split kms"架构。这种架构下，显示控制器和GPU是分离的硬件设备，分别对应不同的DRM节点：

• 显示控制器节点（如/dev/dri/card0）
• 渲染节点（如/dev/dri/renderD128）

这种分离架构导致Niri在初始化时无法正确识别和关联这两个节点，从而引发了一系列问题。

具体问题表现

测试发现，在以下设备上存在不同表现：

1. Raspberry Pi 4：直接崩溃，日志显示unwrap None值错误
2. Raspberry Pi 5：启动但无显示输出，日志显示"no primary allocator"警告
3. Apple M1：与Pi5类似，启动但无显示输出

根本原因在于Niri的DRM设备检测逻辑假设渲染节点和显示节点是同一设备，这在split kms架构下不成立。

解决方案

经过社区讨论和测试，确定了以下解决方案：

1. 手动指定设备路径：在配置文件中显式设置render-drm-device参数
2. 代码逻辑修改：放松对主GPU的检查条件，允许非渲染节点作为主设备

核心修改包括：

// 修改后的设备检测逻辑
if let Ok(node) = DrmNode::from_path(path) {
    if node.is_primary() {
        return Some((node, node));
    }
}

测试验证

解决方案在多种设备上进行了验证：

1. Raspberry Pi 5：成功显示图形界面
2. Apple M2：正常工作
3. Apple M1 MAX：功能正常

对于仍然存在问题的设备，建议：

1. 检查DRM设备权限
2. 确认Mesa驱动版本
3. 尝试不同的设备路径组合

技术展望

随着ARM设备在桌面领域的普及，DRM子系统的支持正在不断完善。Mesa项目已经着手改进对split kms架构的支持，未来这类问题将更容易解决。开发者可以考虑：

1. 增加自动设备检测的健壮性
2. 提供更详细的错误日志
3. 支持动态设备热插拔

Niri项目通过这次问题修复，增强了对多样化硬件架构的兼容性，为Wayland生态系统在ARM平台的发展做出了贡献。