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.
>
> >
> > 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.
>
> >
> > * 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...
>
> >
> > - 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, 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 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.
Quick answer on this, because I had the very same questions regarding
HID-BPF:
- in BPF, you can require (and by default it does) that only GPL
compatible BPF programs are loaded, closing the argument of "closed
licence and distribution restriction"
- also, a BPF program can be disassembled much easier than a binary
blob, and I remember Alexei showing me an example where you get almost
the source code from the BPF object in just one pass.
Cheers,
Benjamin
