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.

> > This driver is fully functional and works with both 5" and 7" Touch
> > Display 2 panels for the RaspberryPi. However, it breaks away from the
> > typical panel driver in multiple ways:
> > 
> > - BPF programs can only be loaded by userspace. This leaves us with two
> >    choices:
> > 
> >    * We prevent the driver from loading until the script itself is
> >      loaded. This has the side effect of preventing any other output to
> >      be used until the initramfs is ran at the earliest, and possibly
> >      ever if the loader isn't installed for example.
> 
> This adds a dependency on user-space behavior and if somehow the
> initramfs doesn't load for a reason we won't have a way to display
> an error.

Yes, if an error happens before the DRM driver loads, it won't be shown
on the screen. This is already the case for any panel driver today on
any major !embedded distribution. And with built-in drivers, this can
also happen before or while the DRM driver loads.

The solution is always the same though: load simpledrm first, move to
the proper DRM device once it's functional. It still works with this
solution.

> > 
> >    * Or we probe the driver all the time, but only report it as connected
> >      once a program has been registered. This is somewhat unconventional,
> >      but allows the other outputs to be functional, *and* allows the user
> >      to force the output if their panel doesn't require any
> >      initialization or during debugging. I chose this solution.
> 
> Both options are not really great...

Feel free to make any suggestions

> > 
> > - It's not a panel driver, but a bridge one, which is also pretty
> >    unconventional. This is required because panel drivers don't have
> >    access to a detect callback that is required for the above, but I also
> >    think that the recent work from Luca blurs the line from panels and
> >    bridges and we'll end up going that road anyway.
> 
> On this point, DDIC _are_ bridges,

I have no idea what a DDIC mean.

> but in the current panel API we blur the line between the panel and
> the DDIC. So being a bridge is fine, but in a general way we lack a
> proper way to describe the display/panel/monitor independently of the
> DDIC.
> 
> At first glance it's a nice driver, but moving the timings into a blob

Let's not kid ourselves, it's *already* a blob. We just sugar-coated it
enough that we can be happy and call it GPL.

> moves something into possible proprietary binaries with possible
> closed licence and distribution restriction so it's a downgrade for
> the same of bringing up a panel faster.

We can already make a proprietary, out-of-tree, panel driver today. That
being said, the only license we allow for BPF programs here is GPL, so
if anything it would be less of a concern for this than it would be for
regular panels.

Maxime