On Sep 29 2026, Maxime Ripard wrote: > Hi Neil, > > On Mon, Sep 28, 2026 at 06:39:58PM +0200, Neil Armstrong wrote: > > On 9/28/26 18:22, Maxime Ripard wrote: > > > Panels in general, and MIPI-DSI panels in particular, are pretty > > > difficult to support and require pretty much a panel driver for each > > > panel produced. Most of them are pretty simple, and require an opaque > > > initialization sequence that is usually poorly documented. > > > > > > This creates a tension between OEMs and distros because OEMs will > > > typically get a new panel to react to a sourcing issue during > > > production, and thus need some swift turnaround between getting their > > > new panel and it being operational in the OS. Distributions on the other > > > hand can take years to ship a kernel with that new panel driver. > > > > > > To solve this, I followed the example of HID-BPF and wrote a panel > > > driver that will rely on BPF programs to perform the panel > > > initialization. That way, we can ship the programs separately from the > > > kernel, and with a different lifecycle. If this driver is accepted, the > > > plan is to have a userspace component started by udev to identify and > > > load the right BPF program for the panels found on the device. > > > > This is kind of late for serious applications except if we manage to > > solve the bootloader to Linux display engine transition. > > Virtually all "generic" distributions are shipping the panel as modules > today anyway, because anything else is nothing but impractical. But > maybe you don't consider them serious enough. Also, applications live in > userspace already, so can be ran after this driver would be initialized > anyway.
To add a little bit to what Maxime said, about the "userspace loader". One thing I initially worked on on HID-BPF was a kernel-side loader. Because BPF allows you to run the syscalls from the kernel itself, nothing prevents you to make an extra "loader" module with the bpf.o embedded in it that would do the loading of the BPF from within the kernel itself. On HID-BPF, my userspace loader was too fancy at some point and the kernel loader started to be too big. Especially because we depend on "potentially" connected devices, and embedding all the BPFs in the module started to be way too much. But for panels and embedded systems, it would totally make sense to have a Kconfig that cherry picks which BPF needs to be embedded in the panel-bpf-loader module, and that module gets loaded/included in the vmlinux directly, and at probe time, it just attaches the struct_ops. Well, of course this surely can be integrated with some DT definition somewhere, but I haven't pushed the thinking too much. Anyway, no userspace/initramfs required in this case! Cheers, Benjamin
