Slashdot Mirror
RandR Support on XFree86 4.3
Gentu writes "Great news from our favorite windowing system: [Hewlett-Packard] engineers committed a new extension to XFree86, called RandR. XFree86 4.3 (to be released in late 2002/early 2003), will have the ability to truly resize (not via the pseudo-resize CNTRL+[+/-] command), rotate, reflect and change the refresh rate of each screen of an X display on the fly. And KDE seems to be the first desktop environment to add support for the RandR extension."
I would like to be able to redirect running xwindows applications. Let's say I am running a copy of bzFlag, or some other type of productivity application. Wouldn't it be good to be able to transfer the running application to a different computer if I suddenly have to change terminals?
Is changing bpp on-the-fly also covered by this new (très cool) extension? I skimmed through the announcement but could not find anything about this. Anybody know if color depth switching is planned?
Reminder: find a new sig
Games.
Being able to change resolution and color depth dynamicly, you no longer have to see a game designed for a lower resolution than your desktop run with in a small window with a black border around it. Resolution could be changed before, but not on all chipsets.
Also running in a different color depth required emulation wich is slow. And this could'nt be changed dynamicly before.
This is the only thing I've hated about X, so I'm quite happy now.
Rotation is used, for example, on the iPAQ PDA,
so that you can choose either landscape or
portrait mode. It is also useful on tablets,
some other circumstances.
Keith and I discussed mirroring when we originally
designed RandR, but couldn't come up with a
plausible need.
Then at a conference, someone came up to me and
said they wanted to implement a Heads-UP display
using a Laptop on their dashboard.
I said: "Sold!".
So we implemented it.
- Jim
However, centuries passed (of computer time, which is rapider than the Julian calendar) before this fundamental capability appeared. Microsoft Windows(tm) has done this since 1996 (or earlier?). Apple surely did it long before. The fact that it took so long led me to doubt the soundness of the X11 system design- either no one else noticed those obvious deficienies (unlikely!), or the vast complexity of the protocol prohibited the creation of new functionality without the developer first learning each little secret of the large xfree86 codebase.
We now see that the latter interpretation was somewhat correct, as this paper explains that the creation of RandR was possible only due to new software (TinyX, etc) that isolated the RandR guys from needing to deal with all of the complexities of X itself. Of course, the relentless increase in processing speed (fruit of Moore's Observation) helped too.
I hope that changes like this have "lowered the hackivation energy" enough so that XFree86 can quickly get some other useful improvements added- within a short time, it might be possible to regain a little Wow Factor over the Microsoft and Apple GUI interfaces. I'll list some improvements I'd like to see. The RandR writeup mentioned some of these, hopefully the same team is already planning work on them) Others of these things can be done already, but with awkward, unstable configurations, or through VNC. We need these capabilities in popular linux distributions, and without VNC's least-common-denominator slowness.
- Migrate a program from one Xserver to another We should be able to use a utility program or a window-manager icon to select a window to send elsewhere. This should be possible from a remote command line login as well (so that if I wander into another person's office I can show him either a single program I'm running, or my whole desktop). It should be your option whether or not the program permantently relocates to the new server (or returns when the window is dismissed). This brings up another feature,
- Run the same program on multiple X displays aka xfork. Operator's choice as to whether the remote display is read-only, or also accepts input. The default should be read-only, unless the toolkit has coded support for this feature, in which case it should default to allowing the remote to provided logically read-only input only (scroll around in the window, but not change the document).
- Lock your desktop without locking the Xserver When I run xlock, it shouldn't only allow MY password to reactivate the display- other persons should be able to walk over and login as well. I can either wait for her turn to be up, or find another Xserver and use the above features to migrate my display to my new desk. This is a natural match for X11's capabilities, but one that Microsoft got last year. *nix has to catch up quick!
- Dynamically reassign input devices Now that a user can change his resolution without restarting X, he should be able to do the same with his input devices. Boot your computer without having any mice installed, get to X, run mozilla to see a web-page on how to configure your Wacom table, and get that working, without needing to restart. (Linux does this to some extent with things like symlinks in
/dev and the /dev/input/mice devices, but it could be better).
- Resurrect the multi-headed display In ancient times, one computer would run 16 interactive sessions on terminals attached to its serial ports. Those capabilities were lost as displays became more complicated and PCs and fat clients emerged. But now, with the rise of USB peripherals and multiple active PCI video cards, commidity hardware could again support this functionality. On an Athlon 1500, I should be able to install a 2nd video card, 2 usb mice, and one usb keyboard, and get a fully independent GUI desktop. (Yes, this usage is a geek stunt- its real-life utility will be bounded by the length of a VGA cable)
- Support joysticks in X This should be an easy one, right guys?
- And many more Any ideas?
An interesting consequence of some changes like this is that users might tend to leave X11 programs running for weeks at a time, with virtual memory becoming like a form of application serialization/persistence. That could have negative implications for efficiency and design. ("Oh, I don't need to put XMMS in my startup folder, I just left it running from last year")(I've heard Microsoft's Netmeeting software does something like this. Probably just a screen scraper, but still a workable feature.)