Dual-head config broke with update to 1.4.2

Martin Cracauer cracauer at cons.org
Mon Feb 22 08:16:38 PST 2010

Alex Deucher wrote on Mon, Feb 22, 2010 at 10:48:39AM -0500: 
> On Sat, Feb 20, 2010 at 7:05 AM, Attila Kinali <attila at kinali.ch> wrote:
> > On Mon, 15 Feb 2010 17:35:14 -0500
> > Alex Deucher <alexdeucher at gmail.com> wrote:
> >
> >> The number of zaphod users is relatively
> >> small and the amount of developer resources to support it is
> >> relatively high. ?More people want to be able to use and dynamically
> >> switch between all their connectors than want to use zapod.
> >
> > I disagre with you here.
> > There are quite a few people who use that mode.
> > Many of my friends use it that way and i was too
> > until the mga driver got so horribly broken with noone
> > caring to fix bugs, even if patches were avaibale,
> > that i pulled my G550 out after 10y of use and replaced
> > it with a radoen. Now i'm waiting for the driver evolve
> > enough so i can use it again (there are more bugs in
> > the currentl release that i've hit within a few hours
> > of using, than you can count).
> >
> > As such. I strongly suggest, taht the xorg developers
> > should think about providing a way to use zaphood mode
> > with xrandr, for all those people who use their computer
> > differently than you do.
> >
> > I mean, it cannot be that difficult to do that. After all
> > xrandr provides the more difficult technique to move windows
> > back and forth between the screens. It should be an easy thing
> > to decouble them and put each of the physical screens into
> > its own X11 screen.
> Dualhead as implemented by xrandr is actually much less complex than
> zaphod mode.  It's basically one huge desktop with two monitors
> pointed at different parts of it.  zaphod mode is relatively complex
> to implement.  You basically have two approaches:
> 1. Use the existing method where the driver loads twice for one card
> and resources are split.
> 2. Write/modify a window manager that behaves like zaphod mode.

But there is only one Xorg but many window managers.  And even if you
use a window manager which does this emulation that still doesn't
change anything about any of the hundreds of other clients you might
use not necessarily be aware of the xinerama extensions, or use them
only partially.

You use, just earlier this morning I was using xine on a xrandr screen
and sure, for things like "full screen" it knows about cinerama.  But
the initial position of the control window is completely random and it
comes up on the other screen.  That's a Xinerama-aware client for you.
Same, as mentioned for the GIMP, which comes up with half the windows
on one display and half on the other.

And as I said earlier, although there is xrandr support in the KDE and
GNOME that are in Debian/stable as of today I found little things in
both that are then still not Xinerama aware, just starting from the
battery status floating thingie which is drawn half on one screen and
half on the other.  In the Xinerama aware GNOME.

I am still confident to say that I'll never use a Xinerama/xrandr
setup on my desktops as long as there is a driver that does classic

It is unrealistic to expect that *all* clients are made fully Xinerama
aware and even those who do only do it partially.  There is no way
that these clients take Xinerama into account on every single thing
they do, witness GNOME battery display.

I still don't get why you (Xorg) think that it is overall better for
you to drop classic dual-screen, a thing that is or was already
working in all Xorg drivers, and expect every single X11 client out
there to be recoded.

> I agree some people like zaphod mode, and it would be nice to support
> it better, however, I only have limited spare time.  It would be nice
> if someone with some interest in zaphod mode would step up to help out
> instead of just complaining when it breaks.

But how do you expect people to notice all these devhead Xorg
breakages when nobody runs Xorg devhead? You made it very hard to even
have a Xorg devhead even for people who'd like to have an alternate
install.  That little python script you provide didn't even make it
through a 10th of the build when I initially started building Xorg

The whole thing is also not very friendly towards non-standard
--prefix locations.

Martin Cracauer <cracauer at cons.org>   http://www.cons.org/cracauer/
FreeBSD - where you want to go, today.      http://www.freebsd.org/

More information about the xorg mailing list