jg at freedesktop.org
Fri Sep 30 05:51:33 PDT 2005
On Thu, 2005-09-29 at 17:29 -0700, Andy Ritger wrote:
> I think I've seen some window manager bugs when growing the root
> window; it's on my todo list to track that down and propose patches
> to the major wm's. Haven't gotten to that, yet.
There certainly may be a few bugs lurking in some window managers,
though since I'm a Gnome user and I think metacity works properly, I
don't know which ones.
> > Putting together (real) Xinerama and RandR is assumingly a bit more
> > complicated. Xinerama with its fixed "screen"-boundaries is a real
> > problem for RandR, I can imagine.
> > Andy, does the Nvidia driver support rotation in TwinView mode? I have
> > been thinking about this, but it's logically somewhat beyond me yet,
> > especially when it comes to non-rectangular screens.
> Yeah, this is somewhat problematic. Today, it sort of works by
> accident, depending on what you want to do. People who want two
> rotated displays positioned horizontally can configure something
> like this:
> 1280x1024+0+0, 1280x1024+0+1024
> to position the unrotated displays vertically, and then rotate the
> whole X screen.
> Having per-display device control of rotation is something that
> I don't think RandR can currently do. I've been leaning towards
> handling the rotation control within the driver, and just exporting
> MetaModes out to RandR that are the bounding box; eg:
> 1280x1024, 1024x1280
> (and yes, you'd end up with a dead region... could use a panning
> domain "1280x1024 at 1280x1280, 1024x1280" such that you can pan the
> first display to access that region of the screen, but ick)
> RandR would unfortunately no longer know about the rotation, though.
Sounds like a problem. We ought to figure out some solution.
Conceptually, RandR is about manipulating the root window, and doesn't
know or care about Xinerama.
And as Xinerama may go away someday (once composite is fully deployed,
it may provide better methods to accomplish the goals of Xinerama than
Xinerama, including display across quite unlike display types), it seems
to me that packaging a solution by extending the Xinerama extension is
more appropriate than doing so in RandR, but as I've never looked
closely at Xinerama (mea culpa), I'm not completely certain of this.
It's also a bug (the last time I checked) that the XAA implementation of
RandR is not rotating the coordinate system of the input devices to
match. This should be in the generic code, rather than the individual
device drivers. Kdrive does so, and it makes life so much easier.
More information about the xorg