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

Val Packett <[email protected]> Sun, 7 Jun 2026 05:24:03 -0300
Newsgroups dev.linux.lists.ksummit
Message-ID <[email protected]>
On 5/26/26 4:41 AM, Neil Armstrong wrote:

> Hi,
>
> 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

Yeah, support for *multiple modes at all* is pretty much absent in 
practice because panels tend to require configuration register writes 
over DCS when switching modes and the current API provides no way to 
make prepare/etc. sequences mode-dependent…

I have tried to make the CRTC accessible in order to be able to access 
the mode from prepare():

https://lore.kernel.org/all/[email protected]/

But my attempt to refactor that again to go through connector_state (in 
response to the review) got stuck in NULL dereference hell so far…

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

Happy to hear about this effort. This is massively important for 
everyone running mainline on phones.


Thanks,
~val