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

On 6/3/26 02:58, Doug Anderson wrote:
> 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.

We lack advanced support in DSI host driver aswell...

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

We need the whole chain cooperating: SoC, panel, DDIC, Product

The most advanced panel I know is the visionox-vtdr6130 which I upstreamed
for the SM8550/SM8650 HDK/QRD which supports Video & Command modes +
optional DSC + dynamic rate switching + self refresh in command mode.

But I don't know which DDIC is inside...

Neil

> 
> -Doug