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

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.

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

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

> 
> 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.
> 
>> - Advanced color management
> 
> For example panel-novatek-nt35510.c, my most ambitious driver:
> 
> /*
>   * These gamma correction values are 10bit tuples, so only bits 0 and 1 is
>   * ever used in the first byte. They form a positive and negative gamma
>   * correction curve for each color, values must be strictly higher for each
>   * step on the curve. As can be seen these default curves goes from 0x0001
>   * to 0x03FE.
>   */
> #define NT35510_GAMMA_POS_DEFAULT 0x00, 0x01, 0x00, 0x43, 0x00, \
>                  0x6B, 0x00, 0x87, 0x00, 0xA3, 0x00, 0xCE, 0x00, 0xF1, 0x01, \
> (...)
> #define NT35510_GAMMA_NEG_DEFAULT 0x00, 0x01, 0x00, 0x43, 0x00, \
>                  0x6B, 0x00, 0x87, 0x00, 0xA3, 0x00, 0xCE, 0x00, 0xF1, 0x01, \
> (...)
>          /**
>           * @gamma_corr_pos_r: Red gamma correction parameters, positive
>           */
>          u8 gamma_corr_pos_r[NT35510_P1_GAMMA_LEN];
>          /**
>           * @gamma_corr_pos_g: Green gamma correction parameters, positive
>           */
>          u8 gamma_corr_pos_g[NT35510_P1_GAMMA_LEN];
>          /**
>           * @gamma_corr_pos_b: Blue gamma correction parameters, positive
>           */
>          u8 gamma_corr_pos_b[NT35510_P1_GAMMA_LEN];
>          /**
>           * @gamma_corr_neg_r: Red gamma correction parameters, negative
>           */
>          u8 gamma_corr_neg_r[NT35510_P1_GAMMA_LEN];
>          /**
>           * @gamma_corr_neg_g: Green gamma correction parameters, negative
>           */
>          u8 gamma_corr_neg_g[NT35510_P1_GAMMA_LEN];
>          /**
>           * @gamma_corr_neg_b: Blue gamma correction parameters, negative
>           */
>          u8 gamma_corr_neg_b[NT35510_P1_GAMMA_LEN];
> 
> (...)
>          /* Default gamma correction values */
>          .gamma_corr_pos_r = { NT35510_GAMMA_POS_DEFAULT },
>          .gamma_corr_pos_g = { NT35510_GAMMA_POS_DEFAULT },
>          .gamma_corr_pos_b = { NT35510_GAMMA_POS_DEFAULT },
>          .gamma_corr_neg_r = { NT35510_GAMMA_NEG_DEFAULT },
>          .gamma_corr_neg_g = { NT35510_GAMMA_NEG_DEFAULT },
>          .gamma_corr_neg_b = { NT35510_GAMMA_NEG_DEFAULT },
> 
> I have added driver support for this based on the code drops from Novatek.
> 
> 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 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
>>
>> 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 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.

Thanks,
Neil

> 
> Yours,
> Linus Walleij