On Wed, Sep 30, 2026 at 03:36:36PM +0200, Neil Armstrong wrote:
> 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.I'm confused, is it something we do not allow today? Maxime
signature.asc
Description: PGP signature
