RandR bugs

[Alan Hourihane]

On Thu, 2005-09-29 at 08:58 -0700, Andy Ritger wrote:
> 
> On Thu, 29 Sep 2005, Thomas Winischhofer wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Alan Hourihane wrote:
> > > On Thu, 2005-09-29 at 13:16 +0200, Thomas Winischhofer wrote:
> > >>But I question just that: Is it really the "*Resize* and *Rotate*"
> > >>extension's job to set the display mode/rate?
> > > 
> > > 
> > > It's resize and rotate with respect to the drivers validated modes from
> > > it's own modepool. 
> > > 
> > > 
> > >>It completely ignores that eventually the user wants a different display
> > >>mode than screen size...
> > > 
> > > 
> > > I'm not sure what you mean here, but when you do 'xrandr -q' it lists
> > > valid display modes to switch to. You can use 'xrandr -s ...' to switch
> > > to a different mode which is pretty much the same as using CTRL+ALT and
> > > +/- to switch, but 'xrandr -s ..' let's you jump straight to the mode in
> > > question.
> > 
> > 
> > I can have a screen of 1280x800 and a display mode of 640x480. If I
> > switch the desktop size to 1024x768, RandR currently insists on setting
> > the display mode to 1024x768 as well. Assuming the user switched to
> > 640x480 on purpose, I find RandR's behavior undesireable.
> > 
> > 
> > 
> > > The drivers own validated modepool is key to the current implementation
> > > in X.Org. If you add the rights modes with the correct refresh rates to
> > > the modepool and it's validated for the monitor then it will appear in
> > > the 'xrandr -q' output as an available mode to switch to.
> > > 
> > > So, rate, is determined from the modepool and advertised via 'xrandr
> > > -q'. And when the user asks for the specified rate - randr can deal with
> > > it properly as it's in the modepool.
> > 
> > 
> > :) Thanks, but I didn't ask because I didn't know, but in order to
> > question the current implementation's practice.
> > 
> > The mode validation is X.org's weak side as it stands. Much to static. I
> > can't just add and remove modes. Last time I checked, the vidmode
> > extension and RandR can't be re-initialized during server runtime.
> 
> I completely agree, Thomas.  It's easy to forget the
> near-independence of scanout and rendering.  What does RandR mean
> if you use TwinView/MergedFB?  It's one thing to set the size of
> an X screen; it's another thing to position an arbitrary number of
> display devices to scanout arbitary portions of that X screen.

The RandR extension has existed for sometime, and probably didn't take
account of everything.

I'm certainly open if NVIDIA has some code or comments to share here
Andy on how NVIDIA's driver deals with RandR and TwinView.

Alan.