RandR bugs

[Andy Ritger]

On Thu, 29 Sep 2005, Alan Hourihane wrote:

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

Understood.  

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

I don't have any great suggestions.  Currently, NVIDIA's TwinView
implementation just advertises the bounding box of the per-head
modes as the mode that goes into the modePool.  This works about
as well as it can with XF86VidMode and with XRandR, except that
the modetimings advertised through XF86VidMode or the refresh rate
advertised through XRandR are not really used, since the extensions
assume a 1:1 mapping of display device to X screen.

Like you mentioned elsewhere in this thread, the XRandR
implementation in the server works quite well with the driver
dynamically updating the modePool.  I've done some experimenting
with that, in conjunction with dynamically reallocating the X root
window in SwitchMode when the root window changes size.  Using that,
I've been able to do things like dynamically grow the root window
and enable TwinView on the fly.  Hopefully once this is production
quality in the driver, we can ship that in a future NVIDIA driver
release.

But as far as the intersection of XRandR and things like TwinView,
I'm not sure what the right answer is.  I don't know how much we
want vendor-specific things like TwinView/MergedFB incorporated
into specifications like XRandR.

I do suspect we'll want to update the XRandR spec at some point to
account for things like Xinerama; at that point we may want to
reconsider assumptions about 1:1 mappings of display devices to
X screens.  I hope to be involved with the spec/implemetation effort
for that, but it's unfortunately further down on my todo list.

Thanks,
- Andy


> Alan.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>