Sebastian Beßler <sebast...@darkmetatron.de> posted 4a45eeaf.8090...@darkmetatron.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
