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

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.

> 
> 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, but those could be moved as helpers and remove
the panel API entirely. And this won't solve how we implement advanced features...

> 
> 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.

> 
> 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 ?

But the goal for this proposal is to have a conversation and it seems it's
an interesting subject to discuss in person.

Thanks !
Neil

> 
> Maxime