<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'Sans Serif'; font-size:12pt; font-weight:400; font-style:normal;">On Tuesday 08 July 2008 12:25:59 pm Kai-Uwe Behrmann wrote: > Am 08.07.08, 11:19 -0700 schrieb Hal V. Engel: snip > > > > According to nvidia the nv driver only has support for randr 1.2 for > > > > NV5 GPUs (8xxx and 9xxx cards). Kai-Uwe is this the type of hardware > > > > you were using? > > > > > > It's a 6200 here. > > > > OK then it should not have XRandR 1.2 support so it appears that the > > driver is incorrently reporting that it does have XRandR 1.2 support when > > it does not. Clearly a driver bug. > > > > > > Currently the only option for nvidia hardware < NV5 for RandR 1.2 support > > is the Nouveau driver which at this point is at best Alpha level code. > > It appears that NV4 GPUs (6xxx and 7xxx cards) have the most mature > > support. But until these progress some more it may be problematic to use > > these drivers. > > Perhaps, I can try Nouveau. Thanks for the pointer. I think this would be good since it will get the features we are interested in tested while the driver is still under developement and perhaps by the time Nouveau is considered stable these features will be working. By the way the Nouveau developers are actively requesting users to test XRandR 1.2 features right now. So any feedback about this should get a good response from them. On the other hand I think they are thinking multi-monitor support and they might be surprised when someone opens a bug about the RandR 1.2 LUT API. > > > > > I was told over a year ago by Aaron Plattner that they had an open > > > > ticket to add RandR 1.2 support specifcally to address the per > > > > monitor LUT issue and on the nvnews linux forums, the forum that the > > > > nvidia linux developers use to interact with users, users regularly > > > > complain about this issue. Kai-Uwe have you raised the issue there? > > > > > > We talked on nvidia@freenode IRC. > > > > And did he have anything useful to say? > > Aaron P. agreed that a unified API to set output properties is desireable. > Nethertheless nvidia people seems to have the pov of having already > covered most ground with their NV-CONTROL/metamode stuff. > > Tomas gave the following link about a previous discussion: > http://lists.freedesktop.org/archives/xorg/2006-November/019923.html This is about per output metamodes and has nothing to do with video card LUTs per say. Although it does talk about having property lists for each output which by inference should/could cover the LUTs as well as metamodes. But per output LUT manipualtion as part of XRandR 1.2 is a done deal and it has been part of the spec for a long time. We also had per output LUT manipulation as part of the XVidModeExtension API. So the open source folks have been doing this right for a long time and the only hold outs (I am not counting open source RandR 1.2 drivers that happen to have some bugs that will likely be fixed at some point*) are the propritary drivers. *In fairness to the maintainers of these open source RandR 1.2 drivers we are just getting around to trying to use these features. So this is basically untested code at this point. I am sure that we can resolve any issues that exist with these drivers without too much difficulty. > > So our desire, to have a clear set of API's without to handle driver > specific protocols, apears as a side place in the discussion. Well I would > say, with enough people making requests to support actual XRandR-1.2, > might help in our direction of reducing the set of required API's. > > In Oyranos is some code to handle special driver features. I consider this > since XRandR-1.2 as hacks and dont like to spend any more development time > in this direction, even with lately some features being lost in Oyranos. I agree with this. Going forward all of us should refuse to use anything other than the standard APIs and if a user says "but this does not work with my nvidia/ATI (or other driver that does not follow the spec) hardware" they should be told that the vendor/driver maintainer is not following standards and that they should open a bug report with the vendor/driver maintainer. Right now we are in a transition where the XVidModeExtension stuff is actually the old but fairly widely used standard and XRandR 1.2 which is the new standard. For drivers that use of any other API this should be considered bug that needs to be fixed by whoever is responsible for maintaining that driver. This is harsh but it places the responsibility where it belongs. At some point down the road we need to stop supporting XVidModeExtension as well but that is a long way off at this point. If we don't do this we will end up with code that has all kinds of difficult to maintain cruft to deal with making vendor specific calls to do something that should be handled by a common standardized API. > > > > > Are the video LUT RandR 1.2 features fully functional on any video > > > > driver at this point? > > kind regards > Kai-Uwe Behrmann </body></html>