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