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

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.

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?

Do we have any indication that there is interest from the companies
actually doing display controllers?

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.

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.

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

Yours,
Linus Walleij