On Wed, Sep 30, 2026 at 03:37:58PM +0200, Neil Armstrong wrote: > On 9/29/26 09:55, Javier Martinez Canillas wrote: > > Maxime Ripard <[email protected]> writes: > > > > > On Mon, Sep 28, 2026 at 10:36:18PM +0200, Neil Armstrong wrote: > > > > On 9/28/26 21:48, Benjamin Tissoires wrote: > > > > > On Sep 28 2026, Neil Armstrong wrote: > > > > > > On 9/28/26 19:24, Benjamin Tissoires wrote: > > > > > > > On Sep 28 2026, Neil Armstrong wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On 9/28/26 18:22, Maxime Ripard wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > Besides what Maxime already mentioned (that most general purpose Linux > > distributions > > built the drivers as modules anyways), it doesn't have to be mutually > > exclusive. > > > > A simple panel could be supported using this BPF-based driver and then a > > panel driver > > added to the kernel, if is found that some applications need to have it > > built-in and > > earlier in the boot path. > > > > I don't see why this would be any different than HDI-BPF or other BPF-based > > infra, > > such as sched_ext. > > I don't want to add a supplementary maintenance burden for the sake of using > a cool > technology which has serious drawbacks and dependencies on user-space even if > looks > really cool.
Spoiler alert: v2 won't. I've got the in-kernel loader to work and thus you can have a built-in panel driver that works without user-space intervention. So this is not a topic of discussion anymore. Maxime will work
signature.asc
Description: PGP signature
