Re: DRM/panel: Bringing Linux DRM Display Panel support in the modern age

On Thu, Jun 04, 2026 at 03:00:59PM +0200, Neil Armstrong wrote:
> Hi,
> 
> On 6/4/26 14:52, Maxime Ripard wrote:
> > Hi,
> > 
> > On Tue, May 26, 2026 at 09:41:18AM +0200, Neil Armstrong wrote:
> > > Since the introduction of the first Samsung DSI panel, the Linux DRM panel
> > > API has been a crucial piece of software for enabling displays across
> > > diverse architectures, but it has not evolved alongside modern graphics stacks.
> > > Currently, the API lacks atomic DRM API support and the ability to adapt
> > > power setups during mode changes.
> > > Furthermore, it fails to support advanced Display Driver IC (DDIC) features
> > > that modern hardware heavily relies on, including:
> > > - Standby and advanced power states
> > > - Advanced color management
> > > - Dynamic rate switching
> > > - Command mode self-refresh
> > > 
> > > This lack of evolution has led to severe fragmentation between
> > > upstream and vendor downstream trees for advanced devices support,
> > > creating a heavy maintenance burden and making native hardware support
> > > incredibly difficult.
> > > 
> > > The goal would be to outline these architectural limitations and
> > > trigger a discussion on how to collaboratively modernize the panel
> > > API. By standardizing advanced DDIC capabilities and fully embracing
> > > the atomic DRM API, we hope to establish a unified path forward for
> > > the entire Linux community.
> > 
> > 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.
> 
> Precisely, but still panels are not like "connectors" where the actual display
> panel is something managed by the display microcontroller firmware.

I'm sorry, but I don't get what you're saying. What's the relationship
between panels (or bridges?) and a display microcontroller firmware? Or
a display microcontroller firmware and KMS in general?

> > Let's acknowledge that drm_bridge isn't just about bridge anymore,
> > make panels bridges, and we're done.
> 
> Yes, and no, those panel-bridges will still have a lot of common boilerplate
> that lies in the panel API today,

What boilerplate? the panel API itself is pretty much only
enable/disable/get_modes. bridges have that too, and then some.

> but those could be moved as helpers and remove the panel API entirely.
> And this won't solve how we implement advanced features...

No, but you'll be able to implement the advanced features with the
access to drm_atomic_state (and drm_bridge_state) bridges give you.

> > The main problem with panels imo is how obscure they are, and are pretty
> > much fire-and-forget for panel vendors, so they have no incentive to
> > spend time upstreaming.
> 
> As Linus, Doug and Dmitry replied already, this is our biggest issue and not
> only Linux maintainers issues but also product makers like Open Linux phones
> which can only discuss with panel makers and are unable to match the downstream
> Android capabilities.

The best we can do for this though is to provide the infrastructure for
them to contribute. We can't do more than that, or force them to
contribute, or release doc, or...

> > It really feels like a similar position compared to what HID was, and I
> > wonder if doing a dumb bridge driver for panels with ebpf support so we
> > can put all the panel quirks in userspace like HID-BPF would be the way
> > forward.
> 
> I don't visualize this proposal, could you elaborate ?

You can create a "generic" bridge driver, and anything out of the
regular MIPI-DSI power sequence is implemented through an optional eBPF
hook.

Maxime

-----BEGIN PGP SIGNATURE-----

iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaiaWzwAKCRAnX84Zoj2+
doZeAYC+YG7E8vMRfwAnJPUg71o1SAIvLtNVeTvlMCer2SLmbxlVVKeaBZnoultW
4ZBvjVoBf1nGpX2J6ZFx2dIz5BzYJ8MQwwXJ9GgF9byYtydUf//iUYhJusbo/81x
54aNf51cwQ==
=3B0/
-----END PGP SIGNATURE-----