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

Hi,

On Tue, May 26, 2026 at 2:30 AM Linus Walleij <[email protected]> wrote:
>
> Hi Neil,
>
> I support this topic. I have hesitated to sign up as panel maintainer mainly
> because I have too much other stuff to do.

At the moment, my day job has taken me further away from interacting
with panels, but I'm still interested in the topic for sure. ;-)


> One thing we need to discuss is the hostility or active disinterest of
> panel IC vendors to the Linux community, or maybe to all their customers.
> My general impression is that they rarely publish datasheets, and if so
> under NDA, and their idea of a driver is a bunch of opaque custom
> commands sent during panel start-up and other infliction points.
>
> Has there ever been a single kernel commit directly from a panel IC
> company such as Novatek, Ilitek, Samsung (their panel business unit,
> not Samsung mobile), etc?

I share Linus's sentiments here. I've only interacted with panel
manufacturers by proxy: I've interacted with ODMs who then interacted
with panel vendors. I've always been a bit shocked by the "sequence of
opaque hex commands" and would love to see something better if we can
figure out a way to improve it.


> > 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.
>
> How do these vendor trees look?
>
> I'm curious. What I expect is more blobs of random hex digits without
> explanation writing magic into the display IC and named do_the_stuff().
> But maybe there are actually some real first class citizens here with
> proper structured drivers and a datasheet to back the code up?

The only drivers I have experience with (other than ones I've
performed random cleanups on) were ones that were part of Chromebooks,
and there were no downstream trees there. Are there example vendor
drivers you can point to? My first instinct would be for someone to
take one of the vendor drivers with advanced features and start trying
to upstream it. It would be even better to look at two (or three)
different vendor drivers that all tried to add the same type of
feature, but that might be asking too much.

...but if that's a bunch of hex blobs, then maybe that doesn't help us
much. To make progress, we'd need to find someone making a product
that cares enough about upstream drivers that they will put pressure
on a panel vendor. Unfortunately, ChromeOS mostly focused on eDP
panels, with a few cheap MIPI panels here and there. ...and Android's
GKI tends to discourage people from upstreaming driver code...

-Doug