On 10/1/26 09:01, Maxime Ripard wrote:
On Wed, Sep 30, 2026 at 03:49:12PM +0200, Neil Armstrong wrote:
On 9/29/26 09:27, Maxime Ripard wrote:
On Mon, Sep 28, 2026 at 09:20:12PM +0200, 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.
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.
Right, it "solve" one of my question, but doesn't really solve the issue
of vendors providing "GPL" bpf programs with source available "somewhere".
Would you be ok if I was to make a tool to decompile a BPF program into its
source file equivalent?
Not really, I don't see the point TBH.
Cool, another moving goalpost then.
Another big issue is the API, I don't want to keep the current API as-is,
we plan to support more advanced panel features and use try to use the
atomic states to support rate switching for example, and I'm not confident
it's a good idea since there's no "simple" and "forever valid" API
to initialize panels...
So, a couple of things here. First, I really don't think we should
extend the panel API, like at all. But let's discuss that at Plumbers, I
don't think it's very relevant to this discussion anyway.
It is, and I'll expose why we need to get out of this deprecated API
as soon as possible, we are seriously keeping the ability to provide
support for advanced panel features which are implemented in vendor
kernels.
I guess I'm not the one working on out-of-tree panel drivers then. But
yeah, I don't dispute that statement.
The API was ok when DSI was added and we didn't have generalized atomic
modesetting, why would you not want panels to embrace atomic ?
I don't understand, please elaborate.
Again, you're putting words in my mouth. I never said I don't want
panels to embrace atomic. I said we shouldn't extend the panel API, I
told you twice what I meant exactly by that:
https://lore.kernel.org/ksummit/20260604-grinning-determined-falcon-0e8b01@houat/
I acknowledge it might sound a bit like "let's burn the whole thing to
the ground", but what you just described sounds an awful lot like what
the bridge API already does.
Let's acknowledge that drm_bridge isn't just about bridge anymore, make
panels bridges, and we're done.
https://lore.kernel.org/dri-devel/[email protected]/
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.
So, yeah, my point is we already have an atomic API to support panels:
it's the bridge one. If your plan is to make the panel API an equivalent
to the bridge API, then it just makes no sense when all consumers are
handling bridges anyway. Just write a bridge driver for your panel IC,
and you're done. It works today, and you don't have to extend anything.
And you can embrace your atomic panel.
I have no precise plan yet, but my idea is close. Since we basically program
the DDICs in panel drivers, which are bridges, just move them as bridges with
perhaps a set of panel DDIC helpers to reduce the burden to write a full
bridge driver and then declare the actual physical panel as connected to
the final bridge connector.
Having a proper "panel" described would be the key to the move, but the more
I dig the more it needs to be a generalized solution across DRM.
I had some feedback about how this would solve issues people struggle have
with advanced monitors arrangements and advanced features like Tiled Display,
etc...
But yeah let's meet in Prague a discuss about this, I'll be pleasure to you
again in person, it has been a while !
Neil
Maxime
