[Openicc] XRandR and nv/nvidia was: [Re: [argyllcms] Re: ArgyllCMS Version 1.0.0 released]

[Hal V. Engel]

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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20080708/cc71ddb3/attachment.htm