DDC/CI Linux Driver Continues To Be Worked On For Managing Monitors

[phoronix]

Phoronix: DDC/CI Linux Driver Continues To Be Worked On For Managing Monitors

A Linux driver for the DDC/CI control protocol for modern displays (well, even many of those going back to ~2005) has been available out-of-tree while finally there has been recent work on getting this driver upstreamed into the kernel...

https://www.phoronix.com/scan.php?page=news_item&px=DDCCI-Linux-Driver-Patches

[caligula]

Hm, I thought EDID stuff already did something like this? Apparently there's a bi-directional link there, left unused.

[Rob72]

2005? Don't you mean 1998 for DDC/CI? And plain DDC goes back to 1994.

[MorrisS.]

I think that it's a good improvement. i have the known Acer G24 monitor which is provided by this feature. Which kernel will integrate it?

[tornado99]

I think they need to be careful about this. For example this is my monitor:

DDC/CI brightness value of 0-31 covers the full brightness range, as does 33-64. 32/65 blacks out the monitor, disables its OSD, and the *only* way I found to recover from this is to send a different brightness value. Luckily I had a second functional monitor to hook up otherwise that would be extremely tricky.

Other monitors have their own quirks depending on the manufacturer.

[Adarion]

I think they need to be careful about this. For example this is my monitor:

DDC/CI brightness value of 0-31 covers the full brightness range, as does 33-64. 32/65 blacks out the monitor, disables its OSD, and the *only* way I found to recover from this is to send a different brightness value. Luckily I had a second functional monitor to hook up otherwise that would be extremely tricky.

Other monitors have their own quirks depending on the manufacturer.

Sounds "great". So we have a 200 KiB active code driver but 15 MiB "database" full of quirks.
Well, this can be really nasty if you brick your device / lock yourself out. But then, that is a matter of manufacturer's fault, esp. if there exists a standard.

[Adarion]

Hm, I thought EDID stuff already did something like this? Apparently there's a bi-directional link there, left unused.

Afaik EDID (Extended Display Identification Data) is simply the identification of the monitor, describing capabilities (resolution, frequencies), all the stuff you were manually entering into xorg.conf back in the days from the printed manual of the screen. It can be read even if powered off, so e.g. my Gentoo boots up nicely with KMS in the right settings, even if I switch on the monitor later. But iirc. it is pretty one way, so it's read only. (someone correct me if I am wrong on that).
Though old DDC might actually be around for much longer, as Rob72 mentioned, and iirc. the old DDC did something similar plus you could have power savings (DMPS).

[tornado99]

Sounds "great". So we have a 200 KiB active code driver but 15 MiB "database" full of quirks.
Well, this can be really nasty if you brick your device / lock yourself out. But then, that is a matter of manufacturer's fault, esp. if there exists a standard.

The problem is that not all manufacturers claim to support DDC/CI, but they seem to leave in various odd implementations anyway. In my experience if there is no turn on/off DDC entry in the OSD then expect either no control or odd control.

[johanb]

Would love to be able to change brightness on desktop monitors, the same way you can on laptop screens.
I understand that it's more important on a portable computer which can often be moved to different places with different lighting, but to be able to just lower brightness during the evening on a desktop monitor without going through the horrible OSD would be really nice.

[DrYak]

2005? Don't you mean 1998 for DDC/CI? And plain DDC goes back to 1994.

1994 was when people decided to allow a computer and screen to communicate over I2C.
2005 is when they decided that they could use this communication channel also to send brightness/contrast commands (exactly like on a laptop screen).

Afaik EDID (Extended Display Identification Data) {...} it is pretty one way, so it's read only. (someone correct me if I am wrong on that).

The protocol used on the wire itself is I2C, which is quite versatile (though not very fast), to the point that several smartphone provide it for extensions in back cover (Jolla 1, PinePhone and Pro, some Motorolas, etc.), and motherboards use it for a lot of features (fan control, thermal sensors, voltage monitoring, fetching RAM modules' setting from an eprom embed in the stick, etc.).

In the case of EDID, the I2C is used to talk to an EPROM in the screen which holds all the information you mentioned (timing information per resolution, etc.)
But nothing prevents you from putting other devices on the same I2C Bus.
I2C is already used to control brightness in other (embed) devices so it seems a no brainer that somebody would decide to expose the functionnality over the I2C bus used for EDID.
All what is required is some standardization.

Note: although it is using the same pin, the stereo 3D display (either virtual headsets, or shutter glasses to use with a monitor) made popular in the past by nVidia does NOT rely on I2C. It's simply setting the pin high or low on alternating frames to designate the active eye (i.e.: the signal that would normally come on a dedicated shutter glass connector). It has no I2C meaning.