On 9/29/26 09:41, Maxime Ripard wrote:
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.
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".
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...
That's exactly where BPF shines. The simple rule of thumb is: there is
no API stability guaranteed. Basically, thanks to the verifier and CORE
(Compile Once Run Everywhere), you don't need to keep the API stable and
available forever. There are multiple ways of dealing with it, but the
gist is that if a BPF is trying to load an "old" API, it will be
rejected by the verifier.
Then it's a matter of being nice enough in the kernel and provide ways
to deal with those.
To give you a few examples:
- in HID-BPF, in userspace, we keep old versions of APIs in separate
compiled objects. Each is incremented (by 10 so we have a little bit
of room in the middle). Then the loader tries first
0020-device-with-new-api.bpf.o, and if it fails, it tries
0010-device-with-old-api.bpf.o
I'm not saying we should do the same here, but that's one idea
- recently, a BPF commit broke the ABI of a function while removing
implicits: bpf_wq_set_callback_impl() was replaced by
bpf_wq_set_callback() with a different number of arguments. I simply
had to add a new function in my header which basically does:
static inline int
hid_bpf_wq_set_callback(struct bpf_wq *wq,
int (*callback_fn)(void *, int *, void *),
unsigned int flags)
{
if (bpf_ksym_exists(bpf_wq_set_callback))
return bpf_wq_set_callback(wq, callback_fn, flags);
if (bpf_ksym_exists(bpf_wq_set_callback_impl))
return bpf_wq_set_callback_impl(wq, callback_fn, flags, NULL);
}
And then I changed the bpf.c to use hid_bpf_wq_set_callback() and the
bpf is compatible with both APIs
- with CORE, struct fields are relocated on the fly when you load the BPF
So for instance, if my BPF only accesses fields .name, .phys and .id
in the BPF, I can define:
struct hid_device {
char name[128];
char phys[64];
unsigned int id;
}
Then when loading the bpf, the verifier replaces all offset to the
ones actually used by the running kernel, and the program loads
transparently, even if you add fields before/after or change the
fields order in the kernel.
Changing the mindset is the hardest part of it. But once you are making
the shift, it's actually much better to work with. It doesn't mean you
can go yolo. You still need to be careful in your choices knowing the
impact on your users. But the API at version 0 is not frozen and you
don't need to maintain it forever, especially if you control the loader
and the headers used to compile the BPFs.
It's really impressive, but there's no way this would become the de-facto
way to program the panels
Nobody said it would? And like I said in my previous mail, I actually
expect us to keep merging panel drivers. Do I think it should become the
go-to solution for simple panels? yes. But we can always make
exceptions, and for more complex panels we should totally do a more
complex driver. Like HID has been doing.
and if the motivation is to make it simpler this implementation
requires adding bindings and bpf programs which that are the same as
native panel drivers, but won't be able to work until user-space
starts and will require to be in initramfs or rootfs to have
functional display.
Not sure to understand what are the positive features here except
isolating the panel code in a safe bpf program (is this really needed
?).
From the cover letter:
"""
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.
"""
You can disagree with the solution, that's fair, we can also discuss on
how to solve this problem, but I'd appreciate it if you weren't claiming
it's all useless.
I did read the cover-letter and I got the arguments from Benjamin, and
while in theory it could indeed solve the issue described, in reality
it won't for the reasons I exposed.
And since it's basically allowing to accept out-of-tree downstream
driver instead of upstreaming, I'm kind against TBH.
But I'm open to discussion, and I'll talk about display Panel in
XDC today, Plumbers and ELC next week so I hope we'll find time to
discuss about this in person!
Neil
Maxime
