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

On 03/06/2026 10:10, Neil Armstrong wrote:
> Hi,
> 
> On 5/26/26 11:30, Linus Walleij 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.
>>
>> 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.
> 
> I agree, but on the Camera Sensor side they had the same issue and started
> speaking directly to some vendors which actually accepted to provide docs
> and even write sensors drivers themselv es.

Unfortunately, for display panels you need two counter parties, the DDIC 
vendor and the glass / panel vendor, with the panel vendor usually 
having the NDA with the DDIC vendor.

>> 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?
> 
> Not that I'm aware of.

Not that I'm aware of too. Some vendors (like Waveshare) contribute 
their patches to the vendor kernels (RPi).

>> Do we have any indication that there is interest from the companies
>> actually doing display controllers?
> 
> They mainly speak to panel makers so I don't think they really care.

We have been going through this for all other classes of hardware. What 
would be the selling point that would make panel vendor learn about the 
upstream Linux process?

>> My view of them is that they seem to be a bunch of company in
>> Asia who are deeply suspicious of each other and just think their
>> competitors will copy everything they do, but this may be prejudice
>> from my side.
> 
> Yes, but if we could speak to the DDIC makers directly to support those
> in a generic way, we could simply take the panel parameters from the ODM
> which got them from the panel makers.
 > >>
>> On Tue, May 26, 2026 at 9:41 AM Neil Armstrong
>> <[email protected]> wrote:
>>
>>> Furthermore, it fails to support advanced Display Driver IC (DDIC) 
>>> features
>>> that modern hardware heavily relies on, including:
>>> - Standby and advanced power states
>>
>> There are at least some standard DCS commands for this.

How would that map to the DRM power states? The feature that would be 
interesting to support is the per-brightness power states.

>>
>>> - Advanced color management
>>
>> For example panel-novatek-nt35510.c, my most ambitious driver:
>>
>>
>> I have added driver support for this based on the code drops from 
>> Novatek.

I'd say, it's pretty unique.

>>
>> So what we want is being able to actually adjust these curves, like we
>> do for professional monitors.
>>
>> However without the datasheet how am I supposed to do anything with this?
>> I can't just trial-and-error such stuff. Novatek need to back any 
>> attempts
>> and provide feedback to do such stuff.
> 
> We also need to provide APIs for this over multiple DDICs, but what 
> publicly have
> is very limited and most of the commands are not documented and we can't
> compare between multiple vendors and implement some generics helpers.

I think we need at least a second implementation before considering to 
turn that into the API.

>> I guess adding gamma correction to the panel frameworks and using
>> the existing infrastructure in DRM for this is our problem, but then 
>> we at
>> least need to know what we are doing.
>>
>>> - Dynamic rate switching
>>> - Command mode self-refresh

Also, the HDR-related features and quirks.

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

https://android.googlesource.com/kernel/msm/+/android-msm-bluecross-4.9-pie-dr1-release/arch/arm64/boot/dts/google/dsi-panel-sw43408-dsc-fhd-cmd.dtsi

> 
> I only have experience with Qualcomm and they have an ultra-generic driver
> which can run any panel in the universe (spoiler: no) with some super 
> complex
> DT entries and support all those super complex self-refresh and dynamic
> rate change.
> 
>>
>> 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?
> 
> There's some stuff with the DDIC but some are in the DSI spec, but since
> we can't any of them publicly it's hard to implement those stuff without
> a vendor willing to implement all those features in the DSI host driver
> first.

-- 
With best wishes
Dmitry