Linux 桌面系统故障排查指南（三） - 桌面会话与图形渲染

AI 创作声明：本系列文章由笔者借助 ChatGPT, Kimi K2, 豆包和 Cursor 等 AI 工具创作，有很大篇幅的内容完全由 AI 在我的指导下生成。如有错误，还请指正。

Systemd 及各项系统服务启动后会进入登录页面，从这一刻开始的 Linux 桌面使用过程涉及会话管理、窗口合成、图形渲染和输入处理等多个组件。

本文将探讨 Linux 桌面系统的图形架构，从用户登录到应用渲染的完整流程，包括 Wayland 和 X11 的区别，图形驱动的工作原理，以及如何诊断和解决各种图形问题。

用户从登录到进入桌面环境的过程涉及多个组件的协调：display manager 负责认证，systemd-logind 管理会话，window compositor 提供图形环境。这个阶段的故障往往表现为登录失败、权限错误或图形界面异常。

典型的图形登录流程：

显示管理器启动：greetd / GDM 等显示管理器显示登录界面
用户认证：通过 PAM 验证用户名 / 密码
会话创建：Display Manager 请求 logind 创建 session
用户服务启动：systemd 用户实例启动，运行用户配置的服务
合成器启动：获得环境变量和设备访问权限

关键观察点：

# 查看显示管理器日志
journalctl -u greetd
journalctl -b _COMM=greetd
# 检查会话状态
loginctl list-sessions
loginctl show-session <id> --property=Name,UID,State
# 查看用户服务日志
journalctl --user -b

故障排查示例：用户登录后合成器未启动

检查用户服务日志：journalctl --user -u hyprland.service
验证会话状态：loginctl show-session <id> -p Active -p State
查看 PAM 认证日志：journalctl -t login

systemd-logind 是连接登录、会话、设备权限和电源管理的核心服务。它通过 D-Bus 暴露 API，管理用户会话并分配设备 ACL。

核心职责：

会话管理：创建和维护用户会话，映射 session -> UID -> TTY / seat
设备访问：基于 udev 标签分配设备 ACL 给当前会话
电源管理：处理电源键事件，根据策略触发 suspend / shutdown
多座席支持：支持 seat 概念，管理多用户场景

https://www.freedesktop.org/wiki/Software/systemd/multiseat/

seat（座席）是 systemd/logind 引入的术语，用来表示「一组物理设备的集合」（例如一个显示器 + 一套键盘和鼠标 + 音频设备），以及与之关联的会话。
所有设备默认都会被分配给 seat0, 想再搞一个 seat1 实现多人图形化登录，必须通过 udev 规则完成如下操作：
1. 必须拥有第二张显卡，这是硬性的前提！为了让 seat1 实际可用，还必须拥有第二套键鼠与声卡。
2. 给第二块显卡写 udev 规则，打上 TAG+="master-of-seat" 并设置ENV{ID_SEAT}="seat1"。
3. 把第二套键盘、鼠标、声卡等设备也写规则改成 ENV{ID_SEAT}="seat1"。
4. 重启系统。
logind 会把 VT/图形会话绑定到具体 seat，从而按 seat 粒度做电源管理、设备访问控制、空闲检测等策略。
远程 SSH 登录不生成也不归属任何 seat；logind 仅为其建立会话对象，seat 字段留空。因此 seat 概念对 SSH 完全透明。

注意：虽然 SSH 会话不归属任何 seat，但这不影响大多数设备的访问。设备权限管理有两套并行的机制：传统的 Unix 权限模型（基于用户组，如 video、audio、input 等）和现代的 systemd-logind ACL 机制（基于 seat 和会话）。SSH 会话主要依赖前者，因此只要用户具有相应的设备权限，仍可正常访问 GPU、声卡、存储设备等硬件资源。seat 机制主要影响的是需要图形界面交互的设备（如显示器、键盘鼠标）的访问控制。

现代 Linux 桌面系统基本都是单用户使用，因此后续讨论默认聚焦单 seat 场景。

# 会话管理
loginctl list-sessions                    # 列出所有会话
loginctl show-session <id> -p Name -p UID -p Seat  # 会话详情
loginctl terminate-session <id>           # 终止会话
# seat 管理
loginctl seat-status                      # 查看 seat 状态
loginctl seat-status seat0                # 特定 seat 详情
# D-Bus 接口调试
busctl --system call org.freedesktop.login1 \
  /org/freedesktop/login1 org.freedesktop.login1.Manager \
  ListSessions

Wayland compositor 启动但无法打开 `/dev/dri/card0`（GPU 权限问题）

排查：

确认 ls -l /dev/dri/card0 的 owner/group。通常应为 root:video，并且当前会话应被授予设备 ACL。
loginctl seat-status seat0 查看是否列出 /dev/dri/card0 并显示 ACL 给当前 session。
若无，通过 udevadm info /dev/dri/card0 检查 udev 是否为 GPU 设备打上了TAG+="uaccess" 或 TAG+="seat"。
查看 journalctl -u systemd-logind，看是否在用户登录时有关于设备分配的错误。
若服务是以 system user 的方式启动，确保 compositor 的进程是在用户 session 下，而不是 systemd 服务或 root 启动的进程（起进程身份不同会导致权限问题）。

检查 logind.conf（NixOS 对应位置请用 NixOS config 来覆写）中 HandlePowerKey,HandleLidSwitch 的配置。
journalctl -u systemd-logind 查看触发事件时间点；通常按键会以 D-Bus 事件或 ACPI 事件入日志。
若某桌面环境或应用拦截了按键，会阻止 logind 行为。可以通过 busctl monitor 监听org.freedesktop.login1 的消息，看是否收到请求。
若需要监控 logind 在登录/登出时做了什么，可以用busctl monitor --system org.freedesktop.login1 或：
```
sudo dbus-monitor --system "interface='org.freedesktop.login1.Manager'"
```
这能观察到 session 创建、移除、seat 分配、锁屏请求等信号。

在深入讨论桌面会话和图形渲染之前，需要先理解 Linux 图形系统的基础组件和概念。

TTY（Teletype） 是 Linux 系统中终端设备的抽象概念，源于早期计算机的终端设备。在现代 Linux 系统中：

物理 TTY：通过串口连接的终端设备（多用于嵌入式或服务器调试）。
虚拟 TTY：通过键盘和显示器模拟的终端，通常有 63 个（tty1-tty63）。在许多经典发行版中，tty1-tty6 默认为文本 VT，图形会话（如 X11 或 Wayland 合成器）通常在 tty7 或 tty1/tty2 启动。
伪 TTY（PTY）：用于网络连接（如 SSH）或终端模拟器（如 GNOME Terminal）的虚拟终端。
VT（Virtual Terminal） 是内核中的虚拟终端子系统（drivers/tty/vt/），负责管理多个虚拟终端：
- 每个 VT 对应一个 struct vc_data 结构体。
- 维护字符矩阵、光标位置、字体等信息。
- 支持两种显示模式：KD_TEXT（文本模式）和 KD_GRAPHICS（图形模式）。
- 只有前台 VT 接收键盘输入。

Linux 内核 VT 子系统支持两种显示模式，通过 KDSETMODE ioctl 进行切换：

KD_TEXT 模式（默认）：

内核 VT 子系统负责字符到像素的转换和刷新。
使用 fbcon（framebuffer console） 将字符矩阵渲染到显存。
支持光标闪烁、滚动、字体切换等文本终端功能。
典型的黑底白字文本界面。

KD_GRAPHICS 模式：

内核停止字符刷新，fbcon 不再更新显存。
用户空间进程（如图形服务器）获得显存控制权，直接进行像素级操作。
图形界面（X11、Wayland）的基础模式。

fbcon（framebuffer console） 是内核中的帧缓冲控制台驱动，负责在 KD_TEXT 模式下将字符矩阵渲染到显存：

将字符矩阵转换为像素数据
管理字体渲染、光标显示、屏幕滚动
在 KD_TEXT 模式下持续刷新显存
在 KD_GRAPHICS 模式下停止工作

fbcon 基于 fbdev（framebuffer device） 框架工作，通过 /dev/fb0 等设备文件访问显存。fbcon 可以在不安装专用显卡驱动（如 NVIDIA/AMD 驱动）时工作，这是因为它依赖于显卡固件提供的标准化接口：

VESA BIOS Extensions (VBE)：在传统 BIOS 系统上，内核的 vesafb 驱动通过 VBE 接口（由显卡 BIOS 实现）请求一个标准的显示模式（如 1024x768），并获取一个指向显存的「线性帧缓冲区」（LFB）地址。
UEFI Graphics Output Protocol (GOP)：在现代 UEFI 系统上，内核的 efifb 驱动通过 GOP 接口实现相同的功能。

关键点在于： 无论是 VBE 还是 GOP，它们都只提供最基本的功能——设置模式并返回一块内存（帧缓冲区）地址。fbcon 驱动（运行在 CPU 上）负责向这块内存中写入像素数据来显示文本。这种方式非常可靠（因为它是固件标准，总能工作），但不提供任何硬件加速。这就是为什么文本界面（KD_TEXT）总是能显示，而图形界面（KD_GRAPHICS）则必须加载专用的 DRM/KMS 驱动，以利用 GPU 的 2D/3D 加速、高级显示设置和电源管理功能。

evdev 是 Linux 输入子系统的事件接口：

提供统一的输入事件格式。
支持键盘、鼠标、触摸板等设备。
通过 /dev/input/event* 设备文件访问。
注意：在 KD_TEXT 模式下，键盘输入由内核 VT 子系统直接处理，绕过了 evdev；只有在 KD_GRAPHICS 模式下，图形服务器才会接管 evdev 设备。

libinput 是用户空间的输入处理库：

提供设备枚举和事件回调。
处理手势识别、边缘滚动、指针加速等高级功能。
被 X11（通过 xf86-input-libinput 驱动）和 Wayland 合成器（原生）广泛使用。
图形界面专用：需要 evdev 支持，因此只在图形模式下工作。

现代 Linux 桌面系统的图形渲染涉及多个层次的组件，从底层的硬件驱动到高层的图形 API，各层协同工作实现高效的图形渲染。

架构层次：

硬件层：GPU 和显示设备
驱动层：Mesa 图形驱动和内核 DRM
系统层：Wayland 协议和合成器 / X Server
工具包层：GTK、Qt 等图形界面库
应用层：具体的桌面应用程序

核心组件：

DRM（Direct Rendering Manager）：内核中的图形驱动框架，是现代 Linux 图形栈的基石。它将 GPU 硬件抽象为 /dev/dri/card0 等设备文件，并提供两大核心功能：
- KMS（Kernel Mode Setting）：Linux 内核中专门负责控制显卡输出、设置显示器分辨率和刷新率等模式（Modesetting）的子系统。主要特点：
  - 内核级控制：由内核直接管理显示模式，避免用户空间程序直接操作硬件
  - 无闪烁启动：系统启动时直接设置到显示器原生分辨率，避免分辨率切换时的闪烁
  - 热插拔支持：可以动态检测和配置新连接的显示器
  - 多显示器支持：支持多显示器配置和扩展桌面
  - 稳定切换：VT 切换（Ctrl+Alt+F1 等）瞬时且稳定
  - 权限安全：用户空间程序无需 root 权限即可请求显示模式切换
- GEM（Graphics Execution Manager）：图形执行管理器。DRM 提供的缓冲区管理框架，负责分配和管理 GPU 显存，并控制 2D/3D 引擎的执行。
DRM-Master：设备主控权限。这是内核 DRM 提供的一种独占锁，用于仲裁哪个进程有权请求 KMS 操作（即设置显示模式）。systemd-logind 会将这个权限授予「活动」的图形会话（如 Wayland合成器或 X Server），确保同一时间只有一个「主宰者」能控制屏幕输出。
Mesa：用户空间的 3D 图形驱动库，提供了 OpenGL 和 Vulkan 等图形 API 的开源实现。
EGL：Khronos 组织定义的接口，是 Mesa 和 Wayland（或 X11）之间的「胶水」，负责将 OpenGL/Vulkan 渲染 API 与本地窗口系统连接起来。
GBM（Generic Buffer Manager）：Mesa 提供的一个 API，允许合成器（Compositor）通过 DRM/KMS 框架，以「非 EGL」的方式直接分配和管理图形缓冲区（Buffers）。
libdrm：一个用户空间库，封装了与内核 DRM 驱动进行 ioctl 通信的复杂细节，简化了 Mesa 和合成器对 DRM/KMS/GEM 的调用。

完整渲染流程：

应用创建渲染上下文：
- 应用（如 Firefox）调用 OpenGL/Vulkan API 创建渲染上下文。
- EGL 负责将图形 API 与 Wayland 窗口系统连接。
- Mesa 驱动加载并初始化 GPU 上下文。
GPU 渲染执行：
- 应用调用 API 绘制界面内容（如网页）。
- Mesa 将 API 调用转换为 GPU 指令。
- GPU 执行渲染，将结果写入一个图形缓冲区（Buffer）。
缓冲区管理：
- GBM 负责为应用分配这个缓冲区。
- 应用将渲染完成的缓冲区（通过 Wayland 协议）提交给合成器（Compositor）。
合成与展示：
- 合成器收集所有应用的缓冲区（如 Firefox 的、终端的、输入法的）。
- 合成器将这些缓冲区组合成一个最终帧。
- 合成器通过DRM/KMS接口，请求内核将这个最终帧显示到屏幕上。

Wayland 图形架构

Wayland 是现代 Linux 桌面系统的图形协议，采用客户端-服务器模型。合成器同时扮演显示服务器和窗口管理器的角色，直接与内核的 DRM/KMS 和输入设备交互。

4.1 架构对比：X11 vs Wayland

X11（传统）：在 X11 架构中，X Server（例如 Xorg）是显示服务器，直接与显卡驱动和输入设备交互； 窗口管理器 / 桌面环境（例如 i3、GNOME）则作为 X client 连接到 X Server，负责窗口摆放、装饰以及用户界面。使用 startx（实际上调用 xinit）启动图形会话时，本质流程是：先启动 X Server，再在其中运行窗口管理器或桌面环境（如exec i3）。Display Manager（如 GDM、SDDM）在图形登录时会自动启动 X Server，并完成用户认证、设置 DISPLAY 等环境变量，然后再运行会话。
Wayland（现代）： Wayland 合成器本身既是显示服务器，又是窗口管理器。它直接通过内核的 DRM/KMS 控制显示模式，通过 evdev/libinput 采集并分发输入事件。Wayland 客户端应用通过 Wayland socket（通常位于 $XDG_RUNTIME_DIR/wayland-0，但具体名字可变）与合成器通信。因为合成器本身直接控制显示和输入设备，所以它可以直接从一个已登录的 TTY 启动，作为该 TTY 的图形会话的「display server」，无需先用 startx 启动一个独立的 X Server。如果使用 Display Manager 登录 Wayland 会话，则由 DM 在合适的 TTY 启动合成器并准备_会话_环境。

当从 TTY 启动 Wayland 合成器时，涉及以下关键步骤：

设备权限获取：合成器通过 systemd-logind 获得 seat 和 GPU 的 DRM-Master 权限。
显示模式切换：调用 KDSETMODE ioctl 将 VT 从 KD_TEXT 切换到 KD_GRAPHICS，内核停止 fbcon 刷新。
输入设备接管：打开 /dev/input/event* 并执行 EVIOCGRAB，或通过 logind 的TakeControl() 获得输入控制权。完成后，合成器通过 libdrm/EGL/GBM 直接渲染到 framebuffer，通常首帧显示黑屏和鼠标指针。

退出/切换 VT（Ctrl+Alt+F⟂）时：

释放 DRM-Master：drmDropMaster()
恢复文本模式：KDSETMODE 切回 KD_TEXT
释放输入控制：关闭 evdev fd，logind 收回设备控制权

fbcon 重新开始刷新，文本界面恢复显示。若合成器异常退出，logind 的 PauseDevice() 会收回 DRM-Master，系统可恢复文本模式。

安全与权限：Wayland 把合成器放在更核心的位置（它有直接设备访问），因此确保合成器运行在正确会话（由 logind 管理）下至关重要。错误地以 root 或 system service 启动合成器会导致权限/ACL 不一致（compositor 无法访问设备或安全级别问题）。
简化流程：Wayland 把多个角色合并到合成器进程，消除了 X11 时代客户端/窗口管理器与服务器的分离复杂度，令直接从 tty 启动合成器成为可行且常见的做法。
兼容性：Xwayland 提供对 legacy X11 应用的兼容，合成器负责在启动时/按需启动 Xwayland 以支持老应用。

4.2 Wayland 协议与通信

客户端-服务器架构：

客户端-服务器模型：应用作为客户端，合成器作为服务器。
Unix 域套接字：通过 $XDG_RUNTIME_DIR/wayland-0 进行通信。
协议扩展：支持 xdg-shell、text-input 等扩展协议。
安全隔离：应用只能访问自己的窗口和输入事件。

核心协议：

wayland-core：基础协议，定义 surface、buffer 等核心对象。
xdg-shell：窗口管理协议，定义窗口、对话框等。
wl_seat：输入设备协议，处理键盘、鼠标、触摸板。
wl_output：显示输出协议，管理显示器配置。

输入处理组件：

libinput：从 /dev/input/* 读取事件并做预处理（手势识别、触摸板边缘、键盘元键处理等）。
合成器使用 libinput 的 API 进行设备枚举与事件回调。

设备访问：

合成器通过 /dev/dri/card0 与内核 DRM 交互。
通过 /dev/input/event* 访问输入设备。
通过 PipeWire 处理音频、视频和屏幕共享（详见后续多媒体章节）。

4.4 xdg-desktop-portal：Wayland 桌面访问控制

XDG Desktop Portal 是一套用于在 Linux 桌面环境下提供统一安全接口的框架，最初为 Flatpak 等沙盒应用访问沙箱外部资源而设计。它通过 D-Bus 暴露一系列「门户（Portal）」接口，让沙箱化或受限应用能够安全地请求文件选择、截图、屏幕共享、打开 URI 等操作。

在 Wayland 环境下，每个应用程序只能访问自己的窗口、键盘鼠标事件等等，无法随意截屏或访问全局资源。在 Wayland 发展过程中，早期各 DE 与 WM 各自为战，实现了许多私有协议去完成这些工作，碎片化严重、客户端程序兼容困难。之后社区逐渐形成了使用 XDG Desktop Portal 作为桌面访问控制框架的共识，如今几乎所有的 DE/WM 与客户端应用都广泛采用了这一框架，它已成为 Wayland 中资源访问控制的事实标准。

如今绝大部分应用在 X11 环境下仍然会使用 X11 原生接口（如 XShm、XRecord、XSelectInput 等）实现屏幕共享、文件选择、打开 URI 等功能，而在 Wayland 下则必须使用 xdg-desktop-portal.

NOTE: 许多命令行截图/录屏工具（如wl-screenrec,wf-recorder）选择了使用 wlr-screencopy-unstable-v1 / ext-image-copy-capture-v1 等 Wayland 原生的协议来实现截图功能，这些工具完全绕过了 XDG Desktop Portal, 通常只在 wlroots-based compositors 上能正常使用，Gnome/KDE 目前都要求走 Portal 接口、不支持此类协议。

https://flatpak.github.io/xdg-desktop-portal/docs/api-reference.html

文件操作：

文件选择器：org.freedesktop.portal.FileChooser 统一的文件选择对话框
文件传输：org.freedesktop.portal.FileTransfer 通过拖拽或复制粘贴等方式在 Apps 之间传输文件

屏幕与媒体访问：

截屏：org.freedesktop.portal.Screenshot 安全截屏功能
录屏：org.freedesktop.portal.ScreenCast 屏幕录制和窗口共享，视频会议应用的核心依赖
摄像头：org.freedesktop.portal.Camera 摄像头访问控制

系统访问：

打印机：org.freedesktop.portal.Print 统一的打印接口
通知：org.freedesktop.portal.Notification 跨桌面环境的通知发送
位置服务：org.freedesktop.portal.Location 地理位置信息访问

账户与权限：

账户信息：org.freedesktop.portal.Account 获取用户基本信息
密码管理：org.freedesktop.portal.Secret 与系统密钥环集成
设备授权：org.freedesktop.portal.Usb USB 设备等外设访问控制

xdg-desktop-portal 是框架本身，具体的功能实现由各个桌面环境提供：

xdg-desktop-portal-gtk：实现了 Portal 最基础的功能，是 Niri/Hyprland 等大部分 Compositors 的默认 Portal.
xdg-desktop-portal-wlr：wlroots 的通用 portal 组件，实现了通用的屏幕共享与截图两项功能，所有基于 wlroots 的 Compositors 都可使用它。
xdg-desktop-portal-gnome：被 Niri 等部分 Compositor 用于实现屏幕共享与截图功能。
gnome-keyring: 实现了 Portal 的密码管理 API, Niri/Hyprland 等 Compositor 都使用它作为密码管理组件。

在后续的多媒体章节中会详细介绍，PipeWire 的屏幕共享功能完全依赖 xdg-desktop-portal：

屏幕捕获流程：视频会议软件 → PipeWire → xdg-desktop-portal → 用户授权 → 合成器提供屏幕内容
权限管理：用户可以精细控制哪些应用可以访问屏幕，以及访问的范围
安全保证：即使应用获得了屏幕访问权限，也只能在用户授权的范围内工作

这种设计解决了 Wayland 隔离原则与实际功能需求的矛盾，是典型的"安全与便利的平衡"方案。

典型交互流程：

应用发起请求：应用通过 D-Bus 调用相应的门户接口
门户服务转发：xdg-desktop-portal 根据配置将请求转发给对应的实现
用户界面显示：具体实现显示原生对话框，请求用户授权
权限授予：用户确认后，门户服务返回授权令牌或结果
资源访问：应用使用令牌通过受限接口访问资源

D-Bus 架构：

# 查看已安装的门户实现
ls /usr/share/xdg-desktop-portal/portals/
# 或在 NixOS 上
ls /run/current-system/sw/share/xdg-desktop-portal/portals/

# 查看当前激活的门户
busctl --user list-units | grep portal

# 监控门户活动
busctl monitor --user org.freedesktop.portal.*

优先级配置：

系统按优先级选择门户实现，优先级文件通常位于：

# 系统级配置
/etc/xdg-desktop-portal/*-portals.conf
# 用户级配置
~/.config/xdg-desktop-portal/*-portals.conf

常见问题排查：

# 检查门户服务状态
systemctl --user status xdg-desktop-portal
systemctl --user status xdg-desktop-portal-gtk
systemctl --user status xdg-desktop-portal-gnome

# 查看门户日志
journalctl --user -u xdg-desktop-portal -f

# 测试门户功能
gdbus introspect --session --dest org.freedesktop.portal.Desktop \
  --object-path /org/freedesktop/portal/desktop

# 检查特定门户支持
gdbus call --session --dest org.freedesktop.portal.Desktop \
  --object-path /org/freedesktop/portal/desktop \
  --method org.freedesktop.portal.Request.Response

NixOS 配置示例：

{
  # 启用 xdg-desktop-portal 服务
  xdg.portal = {
    enable = true;
    extraPortals = with pkgs; [
      xdg-desktop-portal-gtk  # GTK 门户
      xdg-desktop-portal-wlr  # Wayland 合成器门户
    ];
    xdgOpenUsePortal = true;  # 使用门户处理 xdg-open
  };
}

GUI 应用程序是用户与 Linux 桌面交互的主要方式。在 Wayland 环境下，应用通过标准化的协议与合成器通信，实现窗口管理、输入处理和图形渲染。

标准启动过程：

环境准备：
- 设置 WAYLAND_DISPLAY 和 XDG_RUNTIME_DIR
- 加载图形工具包库（GTK/Qt）
- 初始化 Wayland 连接
窗口创建：
- 创建 Wayland 表面
- 设置窗口属性和装饰
- 注册事件监听器
渲染初始化：
- 创建 EGL 上下文
- 加载 Mesa 驱动
- 配置图形缓冲区
内容绘制：
- 应用调用 OpenGL/Vulkan API 绘制界面内容
- Mesa 将 API 调用转换为 GPU 指令
- 在 GPU 上执行渲染，生成帧缓冲数据
- 应用将渲染完成的缓冲区提交给合成器
合成与展示：
- 合成器接收缓冲区后进行最终合成和显示
- 合成器将多个应用的缓冲区组合成最终帧
- 通过 DRM/KMS 将最终帧提交到显示设备

调试启动问题：

# 查看 Wayland 环境
echo $WAYLAND_DISPLAY $XDG_RUNTIME_DIR
# 检查应用日志
journalctl --user -u <application>.service
# Wayland 调试变量
export WAYLAND_DEBUG=1
export MESA_DEBUG=1
# 跟踪系统调用
strace -f -e trace=network,ipc <application>

GTK 应用：

GTK3/4 原生支持 Wayland
自动检测运行环境
可通过 GDK_BACKEND 强制指定后端

# 强制使用 Wayland
GDK_BACKEND=wayland gtk-application
# 强制使用 X11（通过 Xwayland）
GDK_BACKEND=x11 gtk-application

Qt 应用：

Qt5/6 支持 Wayland
需要安装 Wayland 平台插件
自动选择最佳后端

# 查看 Qt 平台插件（NixOS）
ls /run/current-system/sw/lib/qt*/plugins/platforms/
# 传统发行版
ls /usr/lib/qt*/plugins/platforms/
# Qt 调试信息
export QT_LOGGING_RULES="qt.qpa.*=true"

SDL 应用：

SDL2 内置 Wayland 支持
主要用于游戏和多媒体应用
自动适配运行环境

首先，需要判断您当前所处的环境。在终端中运行 tty 命令：

输出 /dev/pts/0 等：您在图形界面下的伪 TTY (pts) 中。
输出 /dev/tty1 等：您在 Ctrl+Alt+F1 切换的虚拟 TTY (tty) 文本控制台中。

在伪 TTY 中，您查询的是整个图形界面的内核 DRM 驱动：

lspci -k | grep -A 3 -i vga

示例输出：

01:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1)
	Subsystem: ZOTAC International (MCO) Ltd. GP107 [GeForce GTX 1050 Ti]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Kernel driver in use: nvidia：表明 NVIDIA 专有驱动正在使用。
常见的驱动有：i915 (Intel), amdgpu (AMD), nouveau (NVIDIA 开源), nvidia (NVIDIA 专有)。

在虚拟 TTY 中（或在 pts 中查询 TTY 的日志），您查询的是帧缓冲驱动：

常见的输出及含义：

现代 DRM 驱动 (最优情况):
```
[   20.709925] fbcon: nvidia-drmdrmfb (fb0) is primary device
```
或
```
[    1.512345] fbcon: i915drmfb (fb0) is primary device
```
含义：fbcon 已绑定到主内核图形驱动（nvidia-drm 或 i915）提供的帧缓冲区（drmfb）上。这表明 KMS 已正常启动，文本控制台将使用显示器原生分辨率，且 TTY 切换（Ctrl+Alt+F...）会非常平滑。
UEFI 固件驱动 (UEFI 回退情况):
```
[    1.234567] fbcon: efifb (fb0) is primary device
```
含义：fbcon 正在使用 UEFI 固件提供的帧缓冲区（efifb）。这通常发生在内核的 DRM 驱动尚未加载或被 nomodeset 参数禁用时。
传统 VESA 驱动 (legacyBIOS 回退情况):
```
[    1.345678] fbcon: vesafb (fb0) is primary device
```
含义：fbcon 正在使用 vesafb 驱动，通过 VBE 接口工作。

# 查看 DRM 设备文件
ls -la /dev/dri/
# 查看 Mesa/OpenGL renderer 信息
glxinfo | grep "OpenGL renderer"
# 查看 Vulkan GPU 信息
vulkaninfo | grep "GPU id"

# GTK 应用渲染器选择
export GSK_RENDERER=vulkan     # 使用 Vulkan 渲染
export GSK_RENDERER=opengl     # 使用 OpenGL 渲染
export GSK_RENDERER=cairo      # 使用软件渲染

GSK_RENDERER=vulkan：使用现代低级别图形 API Vulkan，提供更好的多线程支持和更低的 CPU 开销。性能最佳，支持现代 GPU 特性，适用于现代 GPU 和需要最佳性能的应用，但需要支持 Vulkan 的 GPU 驱动。
GSK_RENDERER=opengl：使用传统硬件加速渲染 OpenGL，兼容性好，性能稳定。支持广泛的硬件和驱动，适用于大多数现代 GPU 和需要稳定兼容性的应用，特点是单线程渲染，CPU 开销相对较高。
GSK_RENDERER=cairo：使用 CPU 软件渲染，不依赖 GPU 硬件加速。兼容性最好，不依赖 GPU 驱动，适用于 GPU 驱动问题时的备选方案，或对性能要求不高的应用，缺点是性能最低，CPU 占用高。

# Qt 应用渲染器选择
export QT_OPENGL=desktop     # 使用桌面 OpenGL
export QT_OPENGL=software    # 使用软件渲染
export QT_OPENGL=angle       # 使用 ANGLE（Windows 兼容层）

QT_OPENGL=desktop：使用桌面版 OpenGL，支持完整的 OpenGL 功能集。功能完整，性能良好，适用于大多数桌面应用，需要完整 OpenGL 支持。
QT_OPENGL=software：使用 CPU 软件渲染，完全绕过 GPU。兼容性最好，不依赖 GPU，适用于 GPU 驱动问题，或需要确保兼容性的场景。
QT_OPENGL=angle：使用 ANGLE 将 OpenGL ES 转换为 DirectX，主要用于 Windows 兼容性。在某些 Windows 兼容层环境下性能更好，适用于 Wine 等 Windows 兼容层环境。

# Mesa 驱动版本覆盖
export MESA_GL_VERSION_OVERRIDE=4.5
export MESA_GLSL_VERSION_OVERRIDE=450
# 调试信息
export MESA_DEBUG=1            # 启用 Mesa 调试信息
export LIBGL_DEBUG=verbose     # 启用 OpenGL 调试信息

MESA_GL_VERSION_OVERRIDE=4.5：强制使用指定版本的 OpenGL，解决某些应用的兼容性问题。覆盖应用请求的 OpenGL 版本，适用于应用要求过高 OpenGL 版本导致无法启动时。
MESA_GLSL_VERSION_OVERRIDE=450：强制使用指定版本的 GLSL 着色器语言，确保着色器兼容性。覆盖着色器编译器版本，避免版本不匹配问题，适用于着色器编译错误或版本不匹配时。
MESA_DEBUG=1：启用详细的 Mesa 调试信息，帮助诊断图形问题。
LIBGL_DEBUG=verbose：启用 OpenGL 库的详细调试输出，用于深入分析 OpenGL 调用问题。

6.3 调试 Wayland 通信

# 查看 Wayland 环境变量
echo $WAYLAND_DISPLAY $XDG_RUNTIME_DIR
# 启用 Wayland 调试输出（客户端）
export WAYLAND_DEBUG=1
# 检查合成器支持的协议
wayland-info | grep text-input
# 跟踪系统调用（查看 socket 通信）
strace -f -e trace=network,ipc <application>

登录失败排查：

# 检查显示管理器状态
systemctl status display-manager
journalctl -u display-manager -b
# 查看用户会话
loginctl list-sessions
loginctl show-session <session_id>
# 检查 PAM 认证
journalctl -t login -f

权限问题排查：

# 检查设备权限
loginctl seat-status seat0
ls -la /dev/dri/card0
# 查看 ACL 分配
getfacl /dev/dri/card0

应用崩溃诊断：

核心转储分析：

# 查看核心转储
coredumpctl list
coredumpctl info <pid>
# 调试核心文件
coredumpctl debug <pid>

GPU 问题诊断：

# 检查 GPU 重置
dmesg | grep -i "gpu hang\|reset"
# Mesa 调试信息
export MESA_DEBUG=1
export LIBGL_DEBUG=verbose

Wayland 协议错误：

# Wayland 调试输出
export WAYLAND_DEBUG=1
# 合成器日志
journalctl --user -u <compositor> -f

性能问题分析：

# GPU 使用率
nvidia-smi  # NVIDIA
radeontop   # AMD
# CPU 使用率分析
perf top -p <pid>
# 内存使用
smem -p | grep <application>
# 帧率监控
export __GL_SHOW_GRAPHICS_OSD=1  # NVIDIA

兼容性问题：

Xwayland 问题：部分 X11 应用在 Xwayland 下运行异常
Wayland 协议缺失：某些功能需要特定的 Wayland 扩展
驱动兼容性：GPU 驱动可能不完全支持某些 Wayland 特性

解决方法：

更新 Mesa 和 GPU 驱动
检查合成器对必要 Wayland 扩展的支持
对于顽固问题，可临时使用 X11 会话

从用户登录到画面显示，这一整套流程确实挺复杂的，展开说那可能得好几本大部头了。

Wayland 虽然还在发展中，但确实比 X11 要现代化很多，性能和安全性的提升是实实在在的，而且在 2025 年的今天 Wayland 生态的可用性已经很不错了。

下一篇文章我们会聊聊多媒体和中文支持，看看系统是如何处理音频视频和中文显示的。

# 会话管理
loginctl list-sessions                    # 列出所有会话
loginctl show-session <id> -p Name -p UID -p Seat  # 会话详情
loginctl terminate-session <id>           # 终止会话
# seat 管理
loginctl seat-status                      # 查看 seat 状态
loginctl seat-status seat0                # 特定 seat 详情
# 设备权限检查
ls -la /dev/dri/card0                     # GPU 设备权限
ls -la /dev/input/event*                  # 输入设备权限

# 图形驱动信息
glxinfo | grep "OpenGL renderer"          # OpenGL 信息
vulkaninfo | grep "GPU id"                # Vulkan 信息
lspci -k | grep -A 3 -i vga               # 显卡驱动
ls -la /dev/dri/                          # DRM 设备
# Wayland 环境
echo $WAYLAND_DISPLAY $XDG_RUNTIME_DIR    # 环境变量
wayland-info | grep text-input            # 协议支持
# 调试变量
export WAYLAND_DEBUG=1                    # Wayland 调试
export MESA_DEBUG=1                       # Mesa 调试
export GSK_RENDERER=vulkan                # GTK 渲染器
export QT_OPENGL=desktop                  # Qt 渲染器

# 会话相关
/etc/systemd/logind.conf                  # logind 配置
~/.config/systemd/user/                   # 用户服务配置
# 图形相关
~/.config/wayland/                        # Wayland 配置
~/.config/gtk-3.0/                        # GTK 配置
~/.config/qt5ct/                          # Qt 配置
~/.config/mesa/                           # Mesa 配置
# 设备权限
/etc/udev/rules.d/                        # udev 规则
/dev/dri/                                 # GPU 设备
/dev/input/                               # 输入设备
# 显示管理器
/etc/gdm/                                 # GDM 配置
/etc/lightdm/                             # LightDM 配置
/etc/sddm.conf                            # SDDM 配置

推荐订阅源

X11 - 标签 - This Cute World

Wayland compositor 启动但无法打开 `/dev/dri/card0`（GPU 权限问题）

Wayland 图形架构

4.1 架构对比：X11 vs Wayland

4.2 Wayland 协议与通信

4.4 xdg-desktop-portal：Wayland 桌面访问控制

6.3 调试 Wayland 通信

推荐订阅源

X11 - 标签 - This Cute World

Wayland compositor 启动但无法打开 /dev/dri/card0（GPU 权限问题）

Wayland 图形架构

4.1 架构对比：X11 vs Wayland

4.2 Wayland 协议与通信

4.4 xdg-desktop-portal：Wayland 桌面访问控制

6.3 调试 Wayland 通信

Wayland compositor 启动但无法打开 `/dev/dri/card0`（GPU 权限问题）