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



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]