Dual-head config broke with update to 1.4.2

[Alex Deucher]

On Mon, Feb 22, 2010 at 11:16 AM, Martin Cracauer <cracauer at cons.org> wrote:
> 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
> dual-screen.
>
> 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.

For the 50th time, Xorg didn't drop it support for zaphod mode, it's
just not commonly used, so it doesn't get as much testing as randr.
If it did, we won't be having this discussion now.  Intel dropped
support in their driver, and the radeon support tends to succumb to
bit-rot since it's not tested too often.

The problem is, zaphod mode (as it is currently implemented) is hard
to support.  It was something of a hack to begin with and it does not
fit well with the way hardware is designed.  The driver loads twice
(!) on the same hardware and each instance has to keep synchronized
with the each other and not step on the other's feet. Ideally someone
would write some common xserver code to implement zaphod mode without
needing driver support, but so far no one has done that.

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

It's not devhead.  The radeon driver has had xrandr support for close
to 3 years now and you are just reporting this now.  That's hardly
devhead.  Most distros use driver versions and xservers that are only
6 moths to a year old.  You don't have to run devhead.

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

The modular stuff is actually much friendlier to non standard prefixes
than the old monolith tree was.  You just pass --prefix to the
configure scripts for the various modules.  There's a howto on the
xorg website:
http://wiki.x.org/wiki/Development/BuildingX
Plus, in most cases your distro provides fairly recent versions of the
necessary bits to testing anyway.  And, yes, you are using freebsd, so
maybe they don't provide recent snapshots, but life is harder on the
fringe.

Alex

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