alanh at fairlite.demon.co.uk
Thu Sep 29 09:15:58 PDT 2005
On Thu, 2005-09-29 at 16:27 +0200, 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.
Why do you need to reinitialize the extension ?
For RandR it works off the modepool. There's nothing stopping a driver
ripping the modepool apart and revalidating it. Thus forcing RandR to
export new supported resolutions.
More information about the xorg