Re: LUT loading with TwinView bug in nvidia driver X API support
I just looked through the xorg thread about xrandr 1.2. It looks like the plan is to move xinerama and some XFree86-VidModeExtension functionality to xrandr. The author of ArgyllCMS was part of that thread and I have included some quotes from the xorg thread by him below. He is in fact the only reason that monitor calibration/profiling issues were even part of that xorg thread. There are three areas that need to be handled to correctly calibrate/profile monitors in color critical systems that were talked about in the thread.
1. The ability to correctly set the gamma curves (LUTs) for each device. It appears that at least based on that thread that xrandr 1.2 would not be getting the ability to make these settings.
" > Most of the utility of this extension is subsumed by RandR version 1.2,
> except for the gamma adjustments. If this features continue to be useful,
> either some relationship between the screen indices used in the
> XFree86-VidModeExtension and the screen/monitor pairs used int RandR or an
> incorporation of this functionality into RandR might be needed.
The latter is in fact essential if color calibration, and consequently high quality color profiling, is to be supported. To not support this disqualifies RandR/X11 systems from consideration for color quality critical work.
Might a way of incorporating the output LUT adjustment into RandR be a set of LUT read/write functions that identify the target by the CRTC ID ? [The CRTC being where I assume the underlying RAMDAC hardware is].
2. The ability to use DCC/CI to automate monitor calibration functionality by allowing the calibration/profiling software to set various monitor settings (black point, contrast, white point, RGB gun gain ....) without user intervention beyond running the calibration software. This is currently poorly supported by all OSs. But Vista will have an API for this when it ships. All current FOSS monitor calibration/profiling software has the user do this setting by taking measurements with a color meter/spectrophotometer and telling the user to increase/decrease the contrast/brightness/Red gain...
3. Being able to specify a ICC profile for each display device and having support for reporting this information to any software using those devices that can use that information. If available this would be used by programs like GIMP, Krita and Scribus among others. And could be set by profiling software such as ArgyllCMS or LProf.
"Keith Packard wrote:
> Hmm. With all of the informative data about outputs that people want,
> how about I just add the ability to set properties on the output. Then
> we can build conventions about what that data looks like as we need it,
> without needing to rev the protocol, server or client libraries.
That would probably work nicely with adapting the current
convention for identifying the appropriate ICC profile for the display as well - simply set it as a property of each Output, rather (or as well as for backwards compatibility) the Screen.
My question in this thread is about #1 and my reading of the xorg thread is that this is outside of the scope of xrandr 1.2. But may be in scope for later versions. In addition, it appears to me that like XFree86-VidModeExtension with xrandr 1.x (whatever x turns out to be when this is supported) the drivers would need to at the very least provide hooks for this to work correctly. After all wouldn't the driver need to be able to both report the current LUT settings to the x server as well as have a hook to write any new values to the LUT(s) that would be called by the x server or by monitor calibration software?
I guess I might need to ask a different question. How do I set the LUTs for each individual display when I have a TwinView machine since XFree86-VidModeExtension does not work? If I know how to do this I can modify dispwin to make it work but I would prefer to use a standard API such as XFree86-VidModeExtension or xrandr instead of using some low level driver specific calls since doing this makes for very messy and difficult to maintain code.