[gentoo-amd64] Re: SOLVED: Re: FGLRX: Option SwapScreens in xorg.conf not working

[Duncan]

Sebastian Beßler <sebastian@××××××××××××.de> posted
4A45EEAF.8090906@××××××××××××.de, excerpted below, on  Sat, 27 Jun 2009
12:04:31 +0200:

> It works again.
> All I had to do was disable xrandr1.2 support in the driver by stopping
> X and using aticonfig --set-pcs-str="DDX,EnableRandR12,FALSE"
>
> If xrandr support is enabled the driver gives all controll over the
> displaysettings to xrandr so that the SwapScreens Option in xorg.conf
> gets ignored.

Cool, thanks! =:^)

I figured it had to be something simple like that and suspected it might 
be RandR related, but as I don't do proprietary, including proprietary 
video drivers, I had no idea what sort of mangling of RandR the 
proprietary driver might be doing.

But turning it off should work, for now...

FWIW, assuming the RadeonHD driver is RandR 1.2 compliant, and the fglrx 
driver should be similar, check out the monitor section of the xorg.conf 
manpage.  In particular, the layout and screen sections work a bit 
differently with RandR and position information that was previously to be 
found there is now located in the various monitor sections.

Among other things, this facilitates monitor hotplugging, tho there are a 
few kinks still being worked out there.  But the idea is to put all the 
information used with a particular detected monitor together in the 
section for that monitor, so with a laptop for instance, you can have 
different settings for your external monitors at home and at work, plus a 
projector setup you use for presentations, plus just the laptop monitor 
itself, and once they get the kinks worked out, you should be able to 
boot your laptop into X with say the external monitor at work plugged in, 
put it into suspend, take it on the train/bus, open the laptop and it'll 
detect that you no longer have the work monitor plugged in and switch to 
laptop monitor only, suspend again, plug in at home and have it detect 
and setup for the home system, suspend again, take it on the plane and 
use it in flight with just the laptop monitor, suspend again, get to your 
presentation, plugin the projector, unsuspend and have it detect the 
projector and use the mode already setup for it, etc...

With the latest ~arch xorg (and RandR 1.3), you should get most of that.  
The caveat ATM is that xorg-server can't yet expand its virtual screen, 
or at least there are problems in some cases with doing so, so regardless 
of what's plugged in when you start X, you have to have the config set 
the initial virtual screen size large enough to enable the screen real 
estate for whatever else you might plug into the system until you shut 
down and restart X again.  Given that, the rest of the RandR based 
autodetect should work, and you'll get more or less usable configurations 
based on what you've preset... the defaults are still for a newly plugged 
in monitor to clone the existing primary display.

The second caveat is that RandR 1.3 is where it finally got decently 
usable, and even if you're running the latest xorg with RandR 1.3, 
everything else still has to catchup to X, with various window managers 
and GUI RandR apps still being somewhat behind.  

xrandr works well enough from the command line, but one either has to 
master all the various options to get it to do what one wants, or set it 
up with scripts and the like.  The more intuitive GUI RandR applets, 
krandrtray for instance, are still at RandR 1.2, semiusable, or RandR 1.1 
or earlier, more broken than usable, state, and while they might work 
well enough to change resolution on a single monitor, they are way more 
frustrating than actually workable once a second monitor is added.  Thus, 
at this point, effectively only those who have troubled themselves to 
master xrandr well enough to write scripts to do what they want have it 
working decently.

As mentioned above, window managers are the second aspect of this 
caveat.  They're behind as well, and frankly, none of them deals 
particularly well with the large virtual desktops necessary for effective 
monitor hotplugging, dynamically confining apps to just the displayed 
area when only a single monitor is plugged in, but remembering where they 
should be when a second one is plugged in and moving everything 
accordingly -- specific to what monitor is plugged in, as well, so your 
home layout, work layout, and presentation layout, can all be different 
and don't conflict with each other and with the laptop-monitor-only 
layout.  My guess is that it'll be another year or so before they sort of 
get it working, and a couple before they get it working /well/.

Anyway, there's definitely a method to the madness, with the usability 
for laptop users vastly improving, but for relatively stable desktop 
configs that seldom change, it's a pain, as the process is breaking what 
/was/ perfectly usable, working configs, forcing people to learn a whole 
new way of configuring things, with various features that used to work 
often temporarily broken in the mean time.  As I said, RandR 1.3 is the 
first RandR that's fully usable here, bringing back panning functionality 
and all, but it was a difficult transition learning how to get the new 
setup to do what I wanted.  And every once in awhile there are still 
quirks.  For instance, the full-screen-mode of many apps forces the 
system into primary-display clone mode, at whatever resolution the app 
wants for full-screen-mode.  So I get the same cloned display on both 
monitors, when what I really wanted was either a single full screen 
display spread over both, or full screen on the one, setting it to 
whatever resolution was desired, but leaving the other monitor alone, so 
it continues to display at its previous resolution and pixel 
coordinates.  I'm not sure even all FLOSS software will ultimately get 
that right, let alone ages old proprietaryware games and the like that 
won't be getting any more updates.  So it's something we'll have to live 
with for awhile.  Meanwhile, I've learned to avoid the in-app full-screen 
modes and use my xrandr scripts and normal mode window moving and 
resizing to accomplish what I want.  That almost always works, once the 
scripts are setup correctly, but it's nowhere near as simple as having 
the in-app full-screen-mode just work as it really should.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman