Wine 是如何加载图形驱动的？

云水木石

发布于 2025-12-25 11:09:40

2750

在 Wine 语境下，graphics driver（图形驱动）与 Windows 内核态的显卡驱动，或 Linux DRM / KMS / Mesa 这一整套图形栈中的硬件驱动，不是同一个层级的概念。它是一个用户态的窗口系统与图形后端适配层，而不是硬件驱动。其核心职责是把 Windows 程序眼中的 GDI / 窗口 / OpenGL / Vulkan 等图形与窗口操作，映射到宿主系统的图形与窗口系统实现上。

简化后的 Wine 图形相关栈结构如下：

Windows 应用
   |
   |  GDI / USER32 / Win32 窗口 API
   v
wineuser / gdi32 / win32u
   |
   |  graphics_driver 接口
   v
-----------------------------------
| Wine 图形驱动（用户态）            |
|                                 |
|  winex11.drv       -> X11       |
|  winewayland.drv   -> Wayland   |
|  winemac.drv       -> macOS     |
|  wineandroid.drv   -> Android   |
-----------------------------------
   |
   |  宿主系统图形栈
   v
X11 / Wayland / Quartz / Cocoa / Android
   |
   v
Mesa / DRM / 显卡内核驱动

wine 图形驱动选择流程

graphics_driver 位于 Wine 内部，以动态库的形式实现，是“Win32 图形语义”与“宿主窗口系统”的桥梁。目前实现的图形驱动有：

wineandroid.drv
winemac.drv
winewayland.drv
winex11.drv

其中，Android 图形驱动目前仍处于非常早期的阶段，功能并不完整，尚无法正常使用。

既然 Wine 提供了多种图形驱动，那么它是如何决定实际加载哪一个的呢？答案是：基于优先级的回退（fallback）机制。

Explorer 进程中的驱动加载

图形驱动的选择最早发生在 explorer 进程中。

explore 模块的 load_graphics_driver 函数首先检查注册表项 HKCU\Software\Wine\Drivers\Graphics，以确认用户是否显式指定了图形驱动；如果没有设置，则使用默认的驱动列表。

默认的驱动列表定义为：

static const WCHAR default_driver[] = L"mac,x11,wayland";

注册表中的值也可以像默认值一样，使用逗号分隔，同时指定多个驱动名称。

按顺序尝试加载驱动

函数会遍历以逗号分隔的驱动名称列表，依次尝试加载：

将驱动名拼接为 wine{name}.drv（例如 winex11.drv、winewayland.drv）
调用 LoadLibraryW 加载对应的驱动 DLL
第一个成功加载的驱动即被选中并使用

写入注册表信息

一旦驱动成功加载（或使用了 null 驱动），Wine 会将 GraphicsDriver 注册表值写入以下位置：

System\CurrentControlSet\Control\Video{GUID}\0000

如果加载失败，则会记录对应的错误信息。

图形驱动初始化流程

桌面窗口创建与驱动加载

当桌面窗口被创建时，win32u 中的 load_desktop_driver 会读取 explorer 进程预先写入的 GraphicsDriver 注册表项。

随后，Wine 通过用户态回调机制来触发驱动加载。

回调加载驱动 DLL

发起回调

上面代码中 KeUserModeCallback 传入的第一个参数 NtUserLoadDriver 是回调 ID，info->Data 包含驱动 DLL 的路径，info->DataLength 是路径长度。

回调表初始化

在 user32.dll 加载时，process_attach 函数会设置 KernelCallbackTable。

static BOOL process_attach(void)
{
    NtCurrentTeb()->Peb->KernelCallbackTable = kernel_callback_table;
    RegisterWaitForInputIdle( WaitForInputIdle );

    winproc_init();
    ...
}

这个回调表 kernel_callback_table 是一个函数指针数组，包含所有的回调函数实现：

static KERNEL_CALLBACK_PROC kernel_callback_table[NtUserCallCount] =
{
#define USER32_CALLBACK_ENTRY(name) User32##name,
    ALL_USER32_CALLBACKS
#undef USER32_CALLBACK_ENTRY
};

回调分发机制

KeUserModeCallback 通过 KiUserCallbackDispatcher 分发到用户模式。在 x86_64 架构下，分发器会查找 peb->KernelCallbackTable[id] 来调用对应的回调函数。这里面使用了一段汇编指令：

#ifdef __WINE_PE_BUILD
                   "movq %gs:0x60,%rax\n\t"     /* peb */
                   "movq 0x58(%rax),%rax\n\t"   /* peb->KernelCallbackTable */
                   "call *(%rax,%r8,8)\n\t"     /* KernelCallbackTable[id] */

User32LoadDriver 实现

最终，NtUserLoadDriver 回调 ID 对应到 User32LoadDriver 函数，该函数使用 LdrLoadDll 加载驱动 DLL：

static NTSTATUS WINAPI User32LoadDriver( void *args, ULONG size )
{
    const WCHAR *path = args;
    UNICODE_STRING str;
    HMODULE module;

    RtlInitUnicodeString( &str, path );
    return LdrLoadDll( L"c:\\windows\\system32", 0, &str, &module );
}

winewayland.drv 始化流程

DllMain 初始化 Unix 调用接口，并调用 waylanddrv_unix_init。从 Windows PE 到 Unix 侧的实现，Wine 使用了一套非常精妙的实现方法。简单说就是通过 __wine_unix_call 机制，将 PE 侧调用分发到 Unix 侧函数表，借助汇编调度器完成上下文切换并执行对应的 Unix 实现。有兴趣的读者不妨进一步深入分析这一机制，在理解其实现细节的过程中，往往会由衷感叹这些开发者在设计上的巧思与工程智慧。

我们主要关注 waylanddrv 的初始化，可以先从 waylanddrv_unix_init 入口看起。

static NTSTATUS waylanddrv_unix_init(void *arg)
{
    /* Set the user driver functions now so that they are available during
     * our initialization. We clear them on error. */
    __wine_set_user_driver(&waylanddrv_funcs, WINE_GDI_DRIVER_VERSION);

    wayland_init_process_name();

    if (!wayland_process_init()) goto err;

    return 0;

err:
    __wine_set_user_driver(NULL, WINE_GDI_DRIVER_VERSION);
    return STATUS_UNSUCCESSFUL;
}