Re: Sending VCGT data to wide gamut monitors using i2c?

[Graeme Gill <graeme2 argyllcms com>]

Richard Hughes wrote:
> Right, I've looked at doing this in X (or the kernel, via KMS) and it
> basically comes down to ic2 being so slow. X can't run threaded, and
> using i2c means we have to block for huge amounts of time. Doing it in
> the kernel makes threads possible, although it makes things much
> harder in other ways.

Hmm. A way around this would be to expose the i2c bus at a very
low level through X, and rely on the caller to do the timing.
(I think that the OS X stuff almost works at this level).

> Right, agreed. I've been looking at the database table in ddcontrol
> and it only supports a few monitors out of the thousands of different
> kinds ever made. With no agreed standard, I agree this is a classic
> chicken and egg thing. I've been trying to use the standard (no
> quirks) mode of ddcontrol and it seems to work kinda-okay, although
> that could be me getting lucky.

As I understand it, there isn't LUT access though ddcontrol, since
it's not in any VESA standard. There is access to other typical
controls (brightness, contrast etc.), but each monitor seems
to do that differently too from what I've been told.

Some of the higher end monitors use USB to access the LUTs.

(One of the display profile vendors offered an VGA breakout
 cable that allowed the i2c to be accessed via USB, simply
 because the i2c access via the video drivers on MSWin were
 so unreliable.)

> Whether it's worth doing, I'm not sure. Maybe effort is better put
> into putting the color conversion into a GLSL shader rather than
> poking about with VCGT-type data.

Anything is possible, but without a largish budget for buying and
testing monitors, or being so important that they ship them
to you for free (as one guesses happens with Microsoft),
it's a tough problem to offer a known working piece of code.

Graeme Gill.