[gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31

[Duncan]

Lie Ryan <lie.1296@×××××.com> posted 4A3A621D.8010207@×××××.com, excerpted
below, on  Fri, 19 Jun 2009 01:49:49 +1000:

> I'd rather say, because laptops are the majority now, dual monitor
> support is going to be more important. I (and I'm sure many others)
> prefer doing presentations from my own laptop, rather than using the
> audience's computers (which always have issues with not having the
> appropriate programs, etc; not to mention having to move the
> presentation files, which is easier said than done).

I thought that's what I /was/ saying, with the additional bit that dual 
desktop display probably never will become the majority, because desktops 
are losing the majority, so there's no time left for dual desktop 
displays to become the majority -- the majority is now laptop, and dual 
display with a laptop is much more common than it ever became on the 
desktop.

> One thing that always bugs me is that XRandR requires some
> configuration[1] and X restart[2], which is a pity, since doing
> presentations means setting up ad-hoc/temporary settings which is just
> used for an hour or two, then tearing them apart again then doing that
> again the next day, probably on a different venue.

Well, in theory, you can setup the config once, and as long as the second 
display plugged in fits within the parameters set in the config, it'll be 
used as such, no X restart should be needed.

One of the CRITICAL bits of the config to get it to do that is to set the 
initial "Section Screen, Subsection Display, Virtual x y" size large 
enough to accommodate the maximum combined resolution, as I don't believe 
xorg yet knows how to increase that size once it's started. (But they're 
actively working on it for later xorg-server releases.)  Depending on the 
desktop environment and how it is configured, that /may/ put stuff 
offscreen.

Beyond that, everything should be hotpluggable and dynamically 
reconfigurable using xrandr or the like.  However, one of the problems 
I've observed so far is that at least the KDE krandrtray and kcontrol/
settings applets, and likely few of the other graphical applets, 
regardless of creator, have the full flexibility xrandr offers.  But 
xrandr is terminal window CLI, you have to read the manpage to groke it, 
and comparatively few people do that -- they like their GUI controls.  
FWIW I think the problem is development latency.  The RandR spec and 
featureset is developing quite rapidly in xorg, and while xrandr is kept 
upto date and shipped with xorg, the graphics widgets aren't, and must be 
developed and tested against the new xorg and RandR before they can ship, 
so they're always running behind what's actually available in the latest 
xorg release.

Meanwhile, RandR 1.3, available with xorg-server 1.6 (possibly 1.5 but I 
don't remember for sure), is finally starting to get back in RandR form 
the features, such as viewport panning, available pre-RandR.  When the 
viewport is smaller than the virtual desktop, panning can be rather 
useful, even critical, but it simply wasn't available with early RandR 
versions.  RandR 1.3 brings it back, in an even more advanced and 
flexible form than pre-randr panning, with a lot more configurability.  
With that, RandR is finally maturing into something actually reasonably 
useful for non-uniform resolution multi-monitor support.  I do hope that 
the graphical RandR clients catch up and support RandR 1.3 very well, as 
it does finally seem to be relatively mature, functionally, now.

Anyway, at least using xrandr, once RandR 1.3 and xorg-server 1.6 hit, as 
long as you start xorg with a large enough virtual desktop, you should be 
able to configure everything else without restarting again.  I know I've 
been able to activate and deactivate one or the other of my monitors 
here, without issue, except that when I reactivate one it starts out in 
clone mode and I have to run my xrandr script to get the two viewports 
set back to the normal configuration.

The other problem is that a lot of apps aren't particularly RandR aware 
yet, or only expect to be using it with a single monitor, so putting 
stuff in full-screen mode can have unexpected consequences, as it often 
changes the resolution for BOTH monitors, and either puts the full-screen 
app centered between them (but at the size of only one of them, so it's 
not really full-screen), or clones to both, instead of only cloning to 
one and leaving the other one alone.

But that's not xorg's or RandR's problem, that's the application's 
problem.  And with the appropriate scripted and hotkey invoked xrandr 
calls, as I have setup, it's relatively easy to get the system back to 
its proper configuration, even when the apps screw it up.

> Mirrored is okay, but I prefer Xinerama/extended desktop. Now that
> OpenOffice 3 starts having support for Presenter View (where the
> projector displays the presentation and your laptop's your notes), not
> being able to just plug the cable in and have the whole thing set up
> automagically is a big loss.

Indeed.  My config is dual monitor desktop and I'm not a "mobile 
warrior", but I can certainly see the use for that in mobile warrior 
presentation situations.

> [1] not to mention I never get all the settings right, either hardware
> acceleration or Xinerama. A separate X display is acceptable, but still
> no hardware acceleration.
> [2] to move between single display to Xinerama and back.

It'll be nice when the xrandr based graphical monitor/desktop config 
applets catchup, and Linux/X finally catches up to what MSWindows was 
doing over a decade ago back with Windows 98!  Linux/X has been more 
flexible in some areas, but unfortunately, that has never been one of 
them.  But it's getting there, FINALLY!

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