RandR bugs

Andy Ritger aritger at nvidia.com
Thu Sep 29 08:58:46 PDT 2005



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.

(and I do say *near* independence, because the two do intersect for
things like window/page flipping, AA downsampling on scanout, etc)

Thanks,
- Andy


> Thomas
> 
> 
> - --
> Thomas Winischhofer
> Vienna/Austria
> thomas AT winischhofer DOT net	       *** http://www.winischhofer.net
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDO/nkzydIRAktyUcRApnhAKDOV/1socBB2KSASQJp4iJz4swtnACfZsy5
> /Us5fF3Yof0ad9PE39l3zpg=
> =KxN2
> -----END PGP SIGNATURE-----
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 



More information about the xorg mailing list