BPF-driven MIPI-DSI panels proposed to speed OEM display support
Maxime Ripard’s generic DRM bridge would load panel init sequences from userspace, echoing HID-BPF, but reviewers flag early-boot and upstream risks.
Maxime Ripard has posted a fully working generic MIPI-DSI panel driver for the Linux DRM subsystem that moves opaque initialization sequences into BPF programs loaded from userspace. The goal is to break the long-standing mismatch between OEMs, who often swap panels mid-production and need same-day OS support, and distributions, which can take years to ship a matching kernel driver.
Most MIPI-DSI panels differ only in regulator timing and a vendor-supplied command stream. Ripard’s driver, modeled explicitly on HID-BPF, registers as a bridge that stays disconnected until a matching BPF program is attached. A planned udev helper would identify the panel and load the right program, letting support ship on a userspace lifecycle instead of a kernel one. The code already drives the Raspberry Pi 5-inch and 7-inch Touch Display 2 panels.
Because BPF can be loaded only after userspace starts, the design trades away early display. Laurent Pinchart asked how the scheme would interact with fastboot hand-off from the bootloader and whether kernel oopses or splash screens could still appear before the root filesystem is mounted. Neil Armstrong called the approach “kind of late for serious applications” unless the bootloader-to-kernel transition is solved, noting that a failed initramfs would leave no path to show an error.
On the supply-chain side, Pinchart worried about a flood of out-of-tree BPF blobs. Benjamin Tissoires, drawing on HID-BPF experience, pointed out that the kernel already requires GPL-licensed BPF programs and that an official collection can live in-tree; distributions can then refuse to load anything not built from that source. Ripard chose the “probe always, connect later” model so other outputs remain usable and so a panel that needs no init sequence can still be forced on for debugging.
The series is an early RFC. Whether the early-boot and licensing questions can be answered will decide if the idea moves from prototype to a supported path for new DSI panels.