On 10/1/26 08:50, Maxime Ripard wrote:
On Wed, Sep 30, 2026 at 03:37:58PM +0200, Neil Armstrong wrote:
On 9/29/26 09:55, Javier Martinez Canillas wrote:
Maxime Ripard <[email protected]> writes:
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.
Besides what Maxime already mentioned (that most general purpose Linux
distributions
built the drivers as modules anyways), it doesn't have to be mutually exclusive.
A simple panel could be supported using this BPF-based driver and then a panel
driver
added to the kernel, if is found that some applications need to have it
built-in and
earlier in the boot path.
I don't see why this would be any different than HDI-BPF or other BPF-based
infra,
such as sched_ext.
I don't want to add a supplementary maintenance burden for the sake of using a
cool
technology which has serious drawbacks and dependencies on user-space even if
looks
really cool.
Spoiler alert: v2 won't. I've got the in-kernel loader to work and thus
you can have a built-in panel driver that works without user-space
intervention. So this is not a topic of discussion anymore.
It will still have users-space dependency, meaning the BPF files will need to
exist in the fs when drivers probes.
Neil
Maxime
will work
