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."
And it will work?
The statement below is true.
The statement above is false.
Hrm, neat. so what though? What does this really mean? Will it make Linux/BSD closer to being "ready for the desktop?" How is this going to affect your average user?
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
So far, we have great 3D acceleration, direct video, anti-aliasing,
Okay, I'll buy that.
and now dynamic sizing/resizing in X.
Everyone is treating this like it's some super great accomplishment. Windows has allowed this since Windows 95, and the Mac since System 7.x.
And all with excellent performance that is equal to or better than the performance offered by Windows.
Ok, that is where I'm starting to laugh. X11 is S.L.O.W. slow. Windows GDI is lightning fast. I can click the start menu and it draws instantly. I can still see Gnome and KDE menus paint across the screen chunkily -- yes, this is on a P-4 machine with whizzy graphics cards, a gig of RAM, etc. And don't blame it on the graphics card manufacturers for releasing no or shitty drivers for Linux. (I didn't say you did, but that's the usual excuse around here.) Windows can wipe my ass too, but the capability to do that well hasn't been written into it. Yet.
And we retain the network-centric features and flexible, modular configuration that make X so powerful.
True, but when Windows Terminal Server came out, that takes a back seat. Try running an X11 session over a slow network link vs. a Windows terminal server session (especially over Citrix ICA) and let me know how it goes. You may want to stop after the 3-4 minutes it takes to partially transfer all the KDE graphics over the line. X11 needs to really work on this big time. Makes you wonder why all those thin clients that boot Linux + X11 do it not to connect to an X server, but to run Citrix's ICA client for Linux to connect to a Windows 2000 server.
This is fine work, I'm sure this will be useful.
Personally I like the X *feature* that make the display resolution change but not the size of the desktop. I find it invaluable as a global zoom feature, when developing GUIs or watching movies on systems without hardware zoom built in the display card (Xv extension).
I wish windows could do the same, but no. If you try to zoom in windows the desktop gets messed up. I wonder if windows users will ever get that feature?
"and now dynamic sizing/resizing in X."
Everyone is treating this like it's some super great accomplishment. Windows has allowed this since Windows 95, and the Mac since System 7.x.
Well, not exactly... What we're saying is that all the faults in useability/functionality that you may have been able to say X had are slowly and surely being whacked out. That they happen without disruption at all in compatability is a sign that there is no fundamental reason for these flaws, they are simply there because they haven't been done yet.
True, but when Windows Terminal Server came out, that takes a back seat. Try running an X11 session over a slow network link vs. a Windows terminal server session (especially over Citrix ICA) and let me know how it goes.
Depends... are we running it through ssh, telnet, or vnc? Vnc sessions are about as snappy as TS (minus the unfortunate remotely-rendered mouse of vnc). Of course Vnc suffers from the same advantage as TS, which is that it can render everything locally and compress and transmit the results.
But certainly X could use improvement in this area. That doesn't mean it won't come, or that we need to -start over-. It could be as simple as another extension.
The enemies of Democracy are
The Mac solved a much simpler problem: given a proprietary GUI toolkit running on a single machine, let people rotate the screen. You can do that with a quick hack.
X11 is a protocol, not an implementation. People can't just go in, hack the XFree86 implementation, and be done with it. If you add something to X11, it needs to be defined, discussed, and then implemented. People need to think about lots of different kinds of possible hardware and scenarios. That takes time.
When will somebody free the world of X11 and write a light-weight fast and efficient graphics layer for Linux,
Have you done a "ps" on your Mac lately? Have you done any kind of graphics benchmarks? X11 runs rings around the Macintosh display system, both in terms of performance and in terms of memory footprint.
but I strongly believe 2/3 of the functionality of the X11 architecure is just a big waste of time and disk space
Oh, and what functionality would that be? Please tell us.
Besides, do you think that putting a PDF or Postscript interpreter into the display server is the epitomy of efficient design?
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
I see, it is somewhat confusing because most people have never used a lightweight window manager. OS X has a 20K process called "Window Manager", all it knows how to do is keep track of where windows are, where the mouse is, keystrokes, etc. It is the clients responsibility to actually draw stuff. The client asks the Window Manager for a shared piece of memory to draw to. When the client is done it tells the server and the server then blits this pixmap and keeps it in memory for later use (double buffering). This is basically what Xrender does. Note that it is the client which also draws the window frame, decorations, etc, there is no "Window Manager" like there is on X11.
Now, the clients do have access to PDF intepreters, but they run in the client only. no "code" is sent to the server. This is the fastest way to do this. ala XRender stuff. Of course, this type of graphics system does not work with remote connections.
I thought XRender prevented remote display functionality?
X11 is ok, but something like quartz does it so much smaller, simpler, and faster.
> I would like to be able to redirect running xwindows applications.
That would be nice, Tee'ing the remote display as a multicast sort of thing would be cool too.
But what I would really like to see is for them to fix backing store and re-enable it as the default. Backing store worked great in XFree 3.3.x and it doesn't use that many resources and most programs don't use it. For some reason it was disabled as the default when 4.0.x arrived. What happened?
-1 Redundant
+1 Well Deserved
Do you have a habit of smoking somethign when you use X?
I'm typing this on a Dell Inspiron 7000. Pentium 333, 190 MB ram, 4 MB ATI video card. Both Windows and X take a second to read the menus and render them the first time, but that time is nearly equivilant. Afterwards, X renders instantly.
However, I don't notice a load-time on my other machine (XP 2000+, 768 MB DDR, MSI GeForce4 Ti 4400).
Are you running an old version of Nautilus? I don't think even that would do it, but that's all I can think of.
Sure, like everything, X has it's problems, but I prefer flexibility and configurability over the simplistic, inflexible crap from Microsoft that passes as a desktop.
~Dalcius
Rome wasn't burnt in a day.
I, for one, would love this feature. I don't care or often even know how many pixels across something needs to be for me to find it comfortable to read. And if when change to a screen with a higher resolution, I hate having to reconfigure all my applications to make the fonts readable again.
If I can specify everything in some absolute measurement - millimetres, inches, whatever - everything'll remain the size I want it and as readable as I want it no matter what display I happen to be sitting at. This is one of the very few reasons I liked the original MacIntoshes
I have Red Hat 8.0 right now on my computer and when I switch to a game that runs at a different resolution depth then my current one it switches to it. Though, it may be if it is running at a resolution lower than my current one (1152x864), but it defeintly will got to full screen for 640x480, 800x600, and 1024x768. Does this have to do with that emulated thing they were talking about on the story? Just curious.
This page was generated by a Barrel of Circus Midgets, and that is the way I like it!!!
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.)
I have a high resolution, something I cannot do without, the sad thing however is, with this high resolution I don't have enough memory for DRI (Direct Rendering Interface). What I'm curious about is that if/when I start using RandR and decrease my resolution on the fly, will it re-initiate things like DRI that where disbled on start due to low memory or will it just change my resolution?
But neither one will get any design awards
Of course the x86 won't get a design award. The x86 wasn't created with extensibility in mind. It has been handicaped from the very beginning. It wasn't designed thinking that they could use more registers in the future, or that it could end up using any register for any purpose. In contrast, the X system has been designed for extensibility, network transparency, multiuser systems and isolation from the kernel.
Extensibility allows adding functionality to the system. The common example is the Renderer extension, but that is just a small example. They could have been created a widget set as an extension to reduce network traffic (not that it would be a good idea). The problem with extensions is not the proper extensions but standarisation. A non standarised extension is useless.
Network transparency allows to use any machine (that uses X) from a single location. You can have a desktop with several apps from different machines. You can move to another location and use the same machine you used before.
Multiuser systems allow various users to be logged into the same machine at the same time without interfering one to the other except for some level of resource competition. This allows to reduce the number of systems to be configured and mantained.
Isolation from the kernel allows to execute the X server in a separate process. The implications of this are that if for any reason there is any operation that will cause a crash, it will only crash the X server and not the entire operating system.
I understand that these features are of no use to the average user of a computer. In the other hand they are completely transparent to the user. I like it's design very much. What problems do people find in X?
Is this being tested in GTK only, or is it also being applied to X overall? There is nothing worse than moving to a new terminal, shutting off the current, and then finding out that the KDE,OpenOffice, Mozilla, and a few other apps did not move.