Lie Ryan <lie.1...@gmail.com> posted 4a3a621d.8010...@gmail.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
