Open-Source Driver Hardware Relay
A hardware-lending test node lets owners of obscure devices give open-source maintainers short, controlled access to test drivers, capture logs, and automatically roll back failed flashes.
When an open-source driver maintainer receives a bug report for an obscure graphics card, they often do not have the hardware. The device owner has the card, but may not know how to compile a driver, capture serial logs, or recover from a black screen. The owner installs a test node on a small host and registers the card model, ports, available times, and permitted test scope. A maintainer brings a bug report and reserves a short session rather than taking ongoing control of the device.
Once a reservation begins, the maintainer can push signed builds, reboot into a test system, and read serial logs, display-identification data, and HDMI handshake results. After each boot, the node automatically captures the screen and key logs. A job page ties together the build version, display mode, test steps, and results into a reproducible record. The hardware owner can see the current activity on a local display at any time and immediately disconnect the remote session by pressing stop.
The recovery path is the critical piece. If a new driver cannot light the display or the machine repeatedly fails to boot, a watchdog switches back to a known bootable version after a set number of attempts and packages the pre-failure logs for the maintainer. The first release supports Linux graphics devices with serial access or remote power control, including build flashing, display capture, and automatic rollback. It does not expose private file systems or turn the device into an unrestricted remote desktop.
Why now
When observed on August 31, an experimental driver for a single SM750 HDMI board ranked 16th on Hacker News, with 61 points and 32 comments. S1 The project also explicitly asks testers to retain a recovery path, putting the lack of physical hardware for obscure graphics cards and recovery from black screens directly in front of maintainers. S2
Target user
The core users are independent maintainers of Linux display drivers who do not have the relevant graphics card. They have just received a bug that reproduces only on a particular PCI ID, monitor, or port. Buying and shipping old hardware is too slow, while a conventional remote desktop cannot survive a black screen. On the other side are device owners willing to help but unwilling to surrender their private system or grant persistent control.
Minimal entry point
On the node side, start by reusing labgrid’s resource export, reservation locks, power, and serial interfaces rather than building a complete hardware-control layer from scratch. S3 After maintainers submit a kernel package, modules, and test checklist, verify build signatures and commit identity with Cosign. The job system exposes only predefined actions, not an unrestricted remote desktop. Limit the first release to one A/B test system and an external HDMI capture card. Save serial output, kernel logs, EDID, screen captures, and exit status for every boot. An independent watchdog counts failed boots and returns to a known-good boot entry.
Punching above its weight
Find the first nodes through issue trackers in graphics-driver repositories. Build indexable directories by PCI ID, output port, and region. When maintainers lack hardware, they can paste a reservation link back into the original issue; device owners receive a clear contribution record through a reproducible report. Demonstrate the service to DRM/KMS mailing lists and distribution hardware-bug trackers rather than trying to build a general hardware community first.
Competitors & gaps
- LAVAGoogle
- LAVA can already schedule physical devices and control power, reset, and serial connections. Devices can run health checks, and failures can change their health status. S3 It suits continuous-integration labs and can handle complex test definitions. Its existing capabilities cover much of the underlying device automation. The gap is that deployers must still configure servers, worker nodes, and device dictionaries. Owners of obscure graphics cards typically lack lab-operations experience. Issue-linked permissions, reservations, and local stop control are not its core interaction model. Display-driver testing also needs captured screen output, EDID, and results from every boot, which require additional test definitions and supporting scripts. LAVA could provide the execution layer, but a separate product layer is needed for individual nodes.
- KernelCIGoogle
- KernelCI connects multiple hardware labs to a unified testing system. It can receive jobs through LAVA and accept results from existing test systems. S4 The system is well suited to automated builds and regression testing for upstream kernel trees, so it need not reinvent result aggregation or kernel-event subscriptions. Its participants are primarily labs or operators of existing test systems. Device owners must still maintain their own testing infrastructure, and maintainers do not reserve a private device around a specific bug report. Temporary permissions, permitted actions, and an on-site stop control would need to be built separately. The platform also does not uniformly provide screen evidence after a graphics-card black screen or automatic rollback. This concept is better understood as a lightweight device-exchange layer before KernelCI integration.
- labgridGoogle
- labgrid provides a coordinator, resource export, and device-reservation mechanisms. Its clients can control power, booting, fast flashing, and serial consoles. S3 It is well suited to assembling distributed physical resources into automated test setups. Using it for reservation locks and a node agent is more reliable than building a hardware abstraction layer from scratch. Its documentation is still aimed at lab engineers and test-script authors. An ordinary graphics-card owner would need to understand serial access, power control, and resource configuration. It has no short-term authorization flow directly tied to a GitHub issue. Build signing, screen capture, and failure rollback also need to be added above it. Owner-visible action prompts and an emergency stop require separate design as well. An initial version could hide labgrid behind the node service and expose only a small set of installation options.
How it makes money
Hardware owners list nodes for free, and open-source maintainers receive a small allotment of free testing time. Enterprise driver teams, hardware vendors, and paid-support providers subscribe for private queues, concurrent reservations, and longer record retention. Usage beyond the plan is billed by node-hour, with credits or hardware-maintenance stipends for device owners.
The case against
Device owners must add serial access, independent power control, and capture hardware, so setup is not trivial. Boot behavior, PCIe topology, and recovery capabilities vary widely by motherboard. A false failed-boot detection can trigger unnecessary rollback, and if rollback itself fails, the owner still has to repair the machine on site. Signed builds verify origin but cannot prevent a faulty kernel from damaging files or hardware. Letting maintainers submit arbitrary code also creates network and same-subnet risks. The platform must physically or logically isolate the test system from private disks. Power issues, reservation disputes, and unattended failures will also consume support time.