AI观察Windows驱动写出Linux驱动：红帽开发者的逆向新方法

从一台不能用的扫描仪说起

一位Linux用户的日常困境——买了一台Plustek OpticFilm 8200i胶片扫描仪，插上Linux电脑却完全无法识别。Red Hat开发者Schaller遇到了这个典型问题：产品名称与旧型号相同，但控制器芯片已从Genesys GL845换成了GL128，SANE扫描框架根本不认识它。他尝试用Claude Code写驱动，失败了，搁置数月。

转机来自Thomas Crider（Linux游戏社区熟知的Glorious Eggroll，Proton GE Custom与Nobara Linux的开发者）的一篇帖子：他让AI代理控制Windows虚拟机来修复鼠标驱动。Schaller把帖子粘进Claude Code，要求为自己的扫描仪搭建同样的环境。

SANE（Scanner Access Now Easy）是Linux及类Unix系统上事实标准的扫描仪访问框架，其架构分为前端（如simple-scan、XSane等用户界面程序）与后端（直接与具体硬件通信的驱动库）两部分。后端通过统一的API向上层暴露扫描、参数设置、图像获取等能力，因此当某款扫描仪的后端尚未实现或未覆盖其新硬件时，应用程序即使能启动也找不到设备。genesys是SANE中负责Genesys Logic系列芯片扫描仪的知名后端，支持大量Plustek、Canon、Epson等基于该厂商芯片的机型；由于不同批次产品可能沿用相同型号名称却更换控制器芯片，后端必须逐芯片地实现寄存器操作、时序控制和数据解析，这也是新芯片长期缺支持的常见原因。

hw-harness的核心机制

这套方法的基础设施是一个USB设备直通到KVM上运行的Windows 11 Pro虚拟机，让厂商自己的驱动执行一次真实扫描操作。同时，Linux宿主机通过usbmon（内核的USB流量记录设施）捕获穿越直通层的所有数据交换——虚拟机内的系统完全不知道自己在被监视。随后用自定义Linux驱动重复同样操作，再次用usbmon记录。对比两段追踪数据，差异直接转化为一份驱动bug清单。

Schaller把这一方法通用化并发布为hw-harness工具包。据Joho no Todai确认，其README明确声明了干净室（clean-room）政策：不触碰厂商的.sys文件即驱动本身，只收集追踪数据、描述符、INF文件、注册表数据和ACPI表。README写道：“如果驱动中的每一个常量都能追溯到一次记录下来的观察，维护者就可以合并它。”通过从外部观察硬件行为而非复制或反汇编代码，这一方法刻意规避了可能阻碍上游贡献的法律风险。

对于MIPI摄像头这类无法从外部截获总线流量的设备，方法会切换为检查Windows侧的INF文件、注册表数据、ACPI表和设备属性。

usbmon是Linux内核自带的USB流量监控设施，通过debugfs或sysfs暴露接口，可在不修改设备驱动的前提下按总线和设备记录URB（USB Request Block，即USB请求块，是内核描述一次USB传输的基本数据结构）。每一次控制传输、批量传输或中断传输的请求类型、端点地址、数据载荷与完成状态都会被捕获，因此能完整还原主机与设备之间的协议对话。KVM即基于内核的虚拟机，它与QEMU配合提供硬件虚拟化，并通过VFIO等机制将物理USB控制器或单个USB设备直通给客户机，使虚拟机内的Windows驱动能够独占操作真实硬件，而宿主机侧的usbmon仍能看到流经该设备的全部报文，从而形成"设备在虚拟机上运行、流量在宿主机上被记录"的观察格局。

三个项目验证方法有效性

SANE扫描仪驱动。 用这套方法，第一次Linux扫描在数小时内成功。几天后一个近乎完整的SANE后端就绪，包含红外扫描支持：彩色、灰度、红外、彩色加红外模式；300–7,200 dpi；8/16位输出；利用红外通道的除尘除划痕；以及针对高密度底片的曝光倍数。Schaller将自己的驱动与2026年9月进入SANE上游genesys后端的实现做了对比：两者在3,600 dpi下解析出相同细节，全分辨率扫描Schaller版耗时34.6秒，上游版54.4秒。只有Schaller版支持红外除尘，上游版则提供更多分辨率档位。他提醒这是“单机单帧结果，当作一个数据点看待”，并表示待上游达到功能对齐后自己也打算切换。

Negative Vibes应用。 光有驱动还不能舒适地扫描底片。Schaller因此开发了用Rust编写的GNOME应用Negative Vibes，保留扫描仪原始的16位线性数据和红外通道，非破坏性地处理负片反转、片基校正、染料串扰校正、红外与软件除尘、基于ArgyllCMS的IT8校准，以及TIFF/JPEG/PNG/DNG导出。所有调整都以设置形式叠加在原始数据之上，可随时改变外观并重新导出。它以Flatpak分发并内置扫描仪后端。目前仅在OpticFilm 8200i上测试过，目标是支持所有SANE兼容胶片扫描仪，但这需要SANE中存在暴露红外通道的标准机制，而该机制尚不存在。

ThinkPad MIPI摄像头。 第三个项目修复了Schaller自己Lenovo ThinkPad X1 Carbon Gen 14（Aura Edition）上的MIPI摄像头——Sony IMX471传感器搭配Intel IPU7，在Linux下产生发暗画面、严重暗角和黄绿色偏。他说早上开始，到当天结束时已经有了内核和libcamera两边的补丁。内核侧IMX471驱动修复了三个问题：裁剪选择bug、测试模式寄存器宽度错误、模拟增益上限过低（损失约1.8档灵敏度）。libcamera软件ISP侧修复了完全缺失的镜头阴影校正（边缘暗约2.7档）和白平衡统计的位深不匹配，后者适用于RAW10/RAW12传感器而非该摄像头专用。受控低光测试中，帧亮度从31.1升到90.9，红/绿比从0.890到1.047，蓝/绿比从0.672到0.823，接近USB摄像头参考值。Schaller将低光下剩余约17%的蓝色欠缺归因于灰世界白平衡的局限。内核补丁已提交给Kate Hsuan，libcamera补丁由Wim Taymans审核中。

MIPI指移动产业处理器接口联盟制定的系列规范，其中MIPI CSI-2是摄像头与处理器之间常用的串行图像传输协议，广泛用于笔记本内置摄像头、手机和嵌入式设备。与USB摄像头不同，CSI-2通常不经过可被usbmon这类通用工具直接抓取的USB总线，链路往往位于SoC内部或通过专用接收器连接，物理上难以像USB那样简单搭线嗅探，因此无法沿用"录制总线流量再对比"的路径，只能退回到解读Windows侧的INF、ACPI与注册表等静态配置信息来推断寄存器写入序列。软件ISP（Image Signal Processor）则是把传统上由专用硬件完成的镜头阴影校正、白平衡、去马赛克、色彩矩阵等处理改由CPU在libcamera等用户态框架中实现，其参数正确性与位深假设一旦出错，就会表现为画面发暗、偏色或暗角，这正是ThinkPad摄像头案例中修复的那类问题。

AI承担中间苦力，人类做决策

为无文档硬件写驱动传统上意味着捕获总线流量、盯着hex dump、对每个寄存器或控制传输的含义形成假设，再逐个测试，周而复始。概念上简单，却需要极大耐心和技巧。Schaller认为这类工作适合AI。

“它能读取数千行USB捕获数据，注意到某个序列重复出现且只有一个字节变化，并推测那个字节的含义。它能写测试来确认。而且它不会感到无聊。”

人类决定构建什么并在真实硬件上验证结果，中间那段艰苦工作大幅缩短。Schaller坦承自己缺乏驱动开发的深厚专业知识，写道他“尽管缺乏这类工作的深入知识，仍能取得进展”。

他对参考捕获决定性作用的观察同样有趣：“让AI把一条已知正常的追踪与一条失败的追踪做比较，能把模糊的‘它不能工作’变成一份具体的差异清单。”MIPI摄像头修复的突破就来自同时连接一个USB摄像头，让Claude Code对比两者捕获。

在AI与Linux驱动的争论中占据不同位置

2026年围绕AI与Linux驱动的争论在多条战线展开：内核staging树采取了自动拒绝AI生成补丁的政策；AI识别出死代码促使移除一个27年前的驱动；用AI在一个月内写出M4 Mac Mini GPU驱动的开发者被Asahi Linux排除在外。当AI修改现有驱动代码时，质量控制和审查负担已成为尖锐问题。

Schaller的方法在这场争论中占据不同位置。它不修改现有代码，而是观察硬件行为从零写新驱动，既不复制也不反汇编代码。AI处于流程中段，人类提供参考数据并在真实硬件上验证结果。其价值在于让专业领域之外的开发者也能取得进展。

当硬件在Linux上无法工作时，此前选择接近于等待支持和自学到能写驱动之间。hw-harness与AI的结合指向了第三条路。

干净室（clean-room）是软件与硬件逆向工程中用来隔离"理解"与"实现"的法律惯例：一组人分析原始产品或二进制并写出规格说明，另一组人只依据该规格从零实现，确保最终代码不含受版权或商业秘密保护的表达，只体现不受保护的功能与接口事实。在驱动开发语境下，厂商的.sys文件、固件和文档通常以专有许可发布，直接反汇编并翻译其逻辑可能引发许可或版权争议，也会让上游社区因法律不确定性而拒绝合并。Schaller方法强调每一处常量都能追溯到一次记录下来的外部观察（如USB报文中的字节），从而把知识来源限定在公开可测的硬件行为上。需要说明的是，这一做法降低而非完全消除风险，硬件接口本身的专利、固件再分发等问题仍可能独立存在。