RandR Support on XFree86 4.3 532
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."
WHOOOOHOO!!! (Score:2, Insightful)
What? No more hacking XF86Config (Score:3, Funny)
Now how will I prove my 3733T skillz?
Re:What? No more hacking XF86Config (Score:5, Funny)
Your eteet skills?
The trolls aren't what they used to be.
Re:What? No more hacking XF86Config (Score:3, Funny)
An abstract (Score:2, Redundant)
The Resize and Rotate extension (RandR) is a very small set of client and server extensions designed to allow clients to modify the size, accelerated visuals and rotation of an X screen. RandR also has provisions for informing clients when screens have been resized or rotated and it allows clients to discover which visuals have hardware acceleration available.
RandR needs to be discussed in concert with recent developments in X server implementation and the new Render extension to understand the implications of the aggregate. In isolation, RandR seems to provide a limited but useful improvement, but together with the Render extension and reimplementation of the X server rendering code, RandR provides part of a key change in X Window System capabilities.
'doze like "Apply" button? (Score:3, Interesting)
And it will work?
so what? (Score:4, Interesting)
Re:so what? (Score:4, Insightful)
Personally, I don't really care what affect this will have in bringing Linux to the desktop. I don't care about the "average user" either.
I care about me, and I'm glad I'll be able to switch resolutions without having to hack at a config file. I'm sure most people will be too, whether they're chatting with friends or coding. It's good for everyone.
Re:so what? (Score:5, Interesting)
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.
RandR not *that* big a deal. (Score:4, Informative)
Of course, you can't run in a windowed mode, but if you're running a game, it's a fair bet that you aren't running windowed.
Let's all go to the article, (Score:3, Informative)
For example, you should be able to tell an application running on your handheld computer to use a nearby desktop display, keyboard and mouse, or a projector on the wall. This should not require stopping and starting the application. You should be able to go home, and decide to import applications you left running at work. There are obviously security, authentication and authorization problems left to work out, but these are generally independent of the base window system.
Holly network is the computer, Batman! I gotta think about that one, but I'm sure it will not be comming to platforms that are still trying to extort per seat licensing and worry about more than one person running a word processor at one time. How's that for "ready" for the desktop"?
MMM, don't like frame buffer, it's been slow. The article talks about this frame buffer being faster than other frame buffers, but that does not make it as good as non frame fuffered servers, no?
Thinking over. Your turn.
Re:Let's all go to the article, (Score:3, Informative)
Re:so what? (Score:3, Insightful)
This is absolutely critical for Linx to be a useful desktop/laptop OS.
Scientists the world over have to use windows for presentations because of this limitation.
Cheers
Martin
Re:so what? (Score:4, Informative)
Or you could add another layout section to your current file, and just call startx -- -layout blah. (Only tried on Debian with X4.)
Gnome support (Score:5, Informative)
6. RandR is coming
Jim Gettys doesn't only work on getting GNOME some nice fonts, he mailed the GNOME-hackers list this week to say that he and Keith Packard had checked in RandR into the main XFree tree. RandR is an extension to X which will allow dynamic resize, rotate and reflect. This will for instance solve the issue of having to define tons of resolutions of your X server manually in order to be able to change resolution. Keith and Owen Taylor is already working on adding the needed support in GTK+ and GNOME Control Center maintainer Jody Goldberg responded saying he would take on the task of eventually adding a RandR GUI configuration tool to the GNOME Control Center package. Links below to Keith's RandR paper and Jim's announcement.
Re:Gnome support (Score:5, Informative)
http://mail.gnome.org/archives/gnome-hackers-re
http://www.xfree86.org/~keithp/talks/randr/
Jim Gettys (Score:2, Informative)
Re:Gnome support (Score:5, Informative)
KDE not first! (Score:4, Informative)
ChangeLogs:
2002-10-04 Havoc Pennington
* src/display.c (event_callback): do XRRUpdateConfiguration()
if we have RandR extension, else poke in Xlib's screen struct to
update the screen size.
* configure.in: fix a bogus overwrite of cppflags,
add a check for RandR extension
2002-10-07 Mark McLoughlin
Support RandR extension by resizing the toplevel panels
if the screen size has changed. Based on patch from
Keith Packard - #94561. Requires gtk+ HEAD.
* basep-widget.[ch]: (basep_widget_screen_size_changed):
* foobar-widget.[ch]: (foobar_widget_screen_size_changed):
resize the toplevels when the screen size changed.
* multiscreen-stuff.c:
(multiscreen_screen_size_changed): re-initialise and request
a resize on the toplevels.
(multiscreen_support_init): connect to the "size_changed"
signal on all screens.
(multiscreen_reinit): re-initialise the monitor geometries.
Re:KDE not first! (Score:5, Informative)
Who cares who did it first. (Score:3, Insightful)
What's important is that both KDE and Gnome will be able to support this feature in the next 0.x version, which is great!
This isn't a friggen pissing contest...
Re:KDE not first! (Score:2)
The change I want to see... (Score:5, Interesting)
Re:The change I want to see... (Score:5, Informative)
Re:The change I want to see... (Score:2)
My, what an interesting life you must lead!
Daniel
Re:The change I want to see... (Score:3, Informative)
Tt creates a "virtual" Xserver ; you run your apps in the virtual server, and then you can attach the virtual server to a real Xserver, and detach/reattach it to another real Xserver.
There are some limitations (real servers must have same bpp, for instance...).
Re:The change I want to see... (Score:4, Interesting)
Sun already does this with their Sun Ray terminals. Your X session is attached to an ID card you stick in the terminal and when you move to another machine your session state moves with you. When you plug your card in your screen pops up where you left it and how you left it.
I don't have an Enterprise 45 and some Sun Rays lying around but I'll make a guess that in order to do this they just did a little transparent tweaking on top of X. The session could be attached not to a network address but instead to an alias. The terminals could send out an alias release packet to the alias manager on the server with the X client whe na card is removed and an alias set packet when the card is inserted. All the server would then need to do is reassign the alias wherever you moved to and your screen would show up on the next screen update.
X is already maintaining your state on the machine hosting the client. The tricky part is just attaching the session to something other than a specific network address or physical port. Resolution and colour depth can be translated by the server running on your terminal. I've never seen an open source implementation of whatever Sun does, maybe someone else can correct me if I was wrong about that or how it works. Just because I haven't seen it doesn't mean it doesn't exist.
What about bits per plane (bpp)? (Score:5, Interesting)
Re:What about bits per plane (bpp)? (Score:3, Informative)
Re:What about bits per plane (bpp)? (Score:5, Informative)
It will then emulate, using the Render extensions compositing features, any visuals used by apps that are no longer accelerated. ( eg switch from 16 to 32, emulate 16 bit visuals.)
This means clients which don't know about RandR, and don't change visuals, will not break.
Re:What about bits per plane (bpp)? (Score:5, Informative)
RandR as implemented and integrated into the XFree86 server differs in
one substantial fashion from the design discussed in that paper: that
is, RandR 1.0 does not implement the depth switching described in that
document, and the support described for that in the protocol in that
document and in the XFree86 implementationhas been removed from the
protocol described here, as it has been overtaken by events.
These events include:
o Modern toolkits (in this case, GTK+ 2.x) have progressed to the point
of implementing migration between screens of arbitrary depths
o The continued advance of Moore's law has made limited amounts of VRAM
less of an issue, reducing the pressure to implement depth switching
on laptops or desktop systems
o The continued decline of legacy toolkits whose design would have
required depth switching to support migration
o The lack of depth switchin implementation experience in the
intervening time, due to events beyond our control
Additionally, the requirement to support depth switching might
complicate other re-engineering of the device independent part of the
X server that is currently being contemplated.
Rather than further delaying RandR's widespread deployment for a
feature long wanted by the community (resizing of screens,
particularly on laptops), or the deployment of a protocol design that
might be flawed due to lack of implementation experience, we decided
to remove depth switching from the protocol. It may be implementated
at a later time if resources and interests permit as a revision to the
protocol described here, which will remain a stable base for
applications. The protocol described here has been implemented in the
main XFree86 server, and more fully in the TinyX implementation in the
XFree86 distribution, which fully implements resizing, rotation and
reflection.
Huh (Score:5, Funny)
Pfff! And I wanted to have my aterm at a weird angle.
graspee
Not true! (Score:2, Informative)
Wow... (Score:5, Insightful)
it's not the same (Score:5, Insightful)
This extension, together with other X11 features, has a much grander vision: letting applications move seamlessly across displays and devices. This requires defining standard protocols by which different implementations can interoperate and communicate. It also means coming up with standards that work across a wide range of devices.
I frankly don't know when, or even whether, X11 will be able to deliver on this vision--it's hard and there is still a lot of work left. But I do know that few other systems are even trying, and that functionally, X11 is already far ahead of the alternatives. For all their visual glitz, Windows and MacOS, for example, are just minor variations on the "applications running on my desktop" theme.
When they say rotate.... (Score:2)
Re:When they say rotate.... (Score:2)
'Bout time... (Score:2)
KDE/Gnome (Score:2, Insightful)
Re:KDE/Gnome (Score:3, Informative)
screenshots (Score:5, Informative)
2) kcontrolmodule [monash.edu.au]
3) notification [monash.edu.au]
4) popup [monash.edu.au]
KDE and RedHat (Score:2, Insightful)
One less thing for windows users to complain about (Score:2, Interesting)
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?
Mirroring (Score:4, Funny)
Unsuspecting boss: Eeeeek! My computer just got a virus! Fix it!
Me: Sure... [types a command]... all fixed.
Boss: That was amazing! What would I ever do without you?
Me: About that raise I was asking about...
other boss pranks ... (Score:5, Funny)
Anyway it was the boss's birthday and the night before he carefully locked his office and set traps in the door so he could tell if anyone had been in .... the next morning he comes in, everything seems OK, he checks the door, his chair, his desk, doesn't find anything ... sits down to work with his computer .... nolthing happens .... about 1/2 an hour later he realises his screen is slowly getting greener and greener ... aha he thinks looks in his system folder, removes a couple of suspicious INITs and reboots, it comes right ..... about 1/2 and hour later kit starts going green again .... he pulls some more stuff, reboots again, but no luck .... he's just about to reformat his disk and reload the OS when lunch came around and we explained ....
Of course reloading everything wouldn't have done him any good ... we'd burned him a custom ROM for his graphics card
Does this mean I get colour cycling in 32-bit? (Score:3, Funny)
for everything else. Is this good enough for that?
What a great feature! (Score:4, Funny)
This is important (Score:4, Insightful)
Of course, changing the display resolution itself has always been possible using control-alt-+/-, but without resizing the desktop.
Full screen games can run at any resolution and color depth supported by the hardware, and included in the XF86Config file, regardless of the desktop resolution, on almost any recent card, if the program itself supports the existing DGA extensions.
Real-time mode line (ie, refresh rate, dot clock, etc.) tweaking has always been possible with xvidtune and other utilities (the very nice PowerDesk tool with Matrox cards, for instance, which is GPL'd).
What this does is allow resizing (and less significantly, rotation, reflection, and other similar permutations) of the desktop itself without restarting the X11 server.
Moreover, this does not automatically mean that an easy to use Windows-style control applet will exist--this is a separate task, as it should be in the Unix tradition, but one which these extensions will make closer to possibility (notwithstanding, I can't see why some tool like this hasn't been developed already by one of the large commercial distributions using functionality already present--see the PowerDesk applet I mentioned above for an example of how this should work).
Rotate and Resize (Score:4, Funny)
Rotate screen to view centerfold...
Resize pants.
I'm a bad bad person.
The anti-pro-X debate is missing the point! (Score:5, Insightful)
But people who say such things about X are missing the point. X is ugly, in the same way that x86 is ugly. I think the analogy is a very apt one. Both are rather old designs, both are the most prevalent, both have had to be extended numerous times (and successfully), and both work, and work quite well. But neither one will get any design awards: the only thing we're doing at this point with either of these is leveraging the existing code base (i.e., the millions of x86 binaries on the one hand and X applications on the other) and avoiding duplication of past work by building something from scratch. And frankly, I think both are beginning to reach the end of the line: the further we go, the more effort we need to expend for an increasingly marginal return.
For the x86 example, Intel perceives this, and wants to jump ship now, even though its replacement is not as robust, fast, or powerful as its last top of the line. Once again, people who point this fact out are missing the point: Intel is laying down a roadmap, to service a broader goal of an architecture it can grow with for the next decade or more.
Why can't we do the same with X? It's going to get harder and harder to grow with X, so lets lay some groundwork now for a window system we can grow with for the next decade or more.
I am shocked and amazed that more comments are not mentioning Berlin [berlin-consortium.org], that is, Fresco [fresco.org]. Do people not know about this? This is the only project I've found that has half a chance of being a suitable replacement for X. There's a framework there, a coherent vision, and even a basic running system. This isn't vapor, folks, or are these people a bunch of anti-X whiners with no code to back up their pointless bitching. They're not FUD-mongers; at least listen to their well-balanced (I think) justification [fresco.org] as to why they're working on this project. It's quite easy to see that they're not at all motivated by hatred of X, but by a desire to design an elegant and network-transparent window system.
Why don't we have more of that nowadays? Half the OSS movement seems to be driven by hatred of Microsoft (or simply closed-source software), rather than love of elegant, useful, robust code born of honest work. At some point someone is going to have to worry about more than simply getting things done as quickly as possible, be-damned-how-it-works, and think more about design and the way things should be. The former type of attitude breeds stuff like MS Windows. Is that really what you want your windowing system to become? If something isn't done before long, X is going to be just like Windows: pasted and taped together and building on a merely serviceable codebase. This, I think, would be a great injustice to X. Let it die a peaceful and honorable death now, rather than a violent and hate-filled one later when it becomes so horrible, so monstrous, that the issue of replacing it is forced upon us and we throw its head on the guillotine.
Remember that at its inception X itself was merely a design framework by people who wanted to do a windowing system the right way. That X has served so well for so long is a testament to that foresight. But please, let us have the foresight to know when to design something new on that same basis, learning from what we have done. A rejection of the code does not mean a rejection of the vision or of the talent that bore that code.
Re:The anti-pro-X debate is missing the point! (Score:3, Insightful)
Until all those goals are reached, Berlin and Fresco are only useful to show off how l33t you are, but serve no practical purpose.
It's funny how you praise Berlin. Berlin communicates via CORBA. And guess what all the anti-GNOME/anti-ORBit trolls and the KDE people say about CORBA? It's slow!
And X was *designed* to be extensible. The designers back in the 80s realized that their work will once be outdated. Sure, there will be a day when X *must* be replaced, but that day is nowhere near today. X can be extended for a very long time.
Re:The anti-pro-X debate is missing the point! (Score:4, Informative)
<eliza>Why do you think that it is going to get harder and harder to grow with X?</eliza>
(For that matter, why do you think X is bloated, or ugly, or slow, or obsolete, or inefficient?)
I suggest you check out the X extension mechanism. You know, the thing that makes possible such things as the RandR extension, which is what we're ostensibly talking about here. The original X11 design did not make any provisions for:
and much, much more. Yet these things all work fine today, without loss of any backward compatibility to older applications.
I agree with Jim Gettys on this one: people who say X is bloated and/or outdated are usually underinformed - meaning they have not really evaluated the alternatives or tried to design their own alternatives. Either that, or they are looking for something with a lot less functionality, like a simple framebuffer for a PDA.
(One thing I do think XF86 could still use is a widget set extension. I'm thinking individual toolkits like gtk2 or motif2.1, when installed on an X server, would register sub-extensions with it. The client-side libraries would use them if present, so most widget UI interaction would happen entirely on the server side. I think this would be very good for perceived UI latency. This is something I'd start investigating and hacking on if I had a lot more time than I do, but alas....)
Re:The anti-pro-X debate is missing the point! (Score:3, Interesting)
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?
We need more extensions! (Score:5, Interesting)
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.)
Why aren't menus managed by the window manager? (Score:3, Insightful)
An application would define a property, WM_MENU, on any window that needs a menu. The property would be a list of menu items, each similar to the structs used in just about every windowing system, and allowing recursive definitions of other menus by pointing to other window properties. Applications wouldn't have to respond to the menu events, only to the final selection. The advantages would be many.
- Applications could be smaller, since they won't have to manage the menus.
- Applications, especially those running remotely from the display server, would seem more responsive to the user because the menu would be handled locally.
- Best of all, window managers could offer more choice in menu bars.
Right now, every X11-based system has to use Microsoft's look-and-feel for application menus. If the WM handled menus, the WM could offer choices, such as putting the menu bar along the top of the display [asktog.com]. Or by changing one preference, you could implement pie-menus [piemenus.com] in all of your applications. Or someone could come up with something even better!Re:This is not a rhetorical question. (Score:5, Insightful)
Mirroring may be reflection, but it could also be mirrored video for multihead setups.
Re:This is not a rhetorical question. (Score:5, Funny)
Re:This is not a rhetorical question. (Score:5, Interesting)
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
Re:This is not a rhetorical question. (Score:3, Funny)
Re:This is not a rhetorical question. (Score:3, Insightful)
I'm not saying most people will do this, but most people don't run multiple monitors either.
Re:This is not a rhetorical question. (Score:4, Insightful)
Re:This is not a rhetorical question. (Score:3, Informative)
Re:Just how bad is X? (Score:5, Insightful)
X gives you a base. You can reimplement everything X already does to get the features X doesn't have, or you can implement extensions to X, or rewrite core parts, to correct the faults X has. Guess which is less work?
Re:Just how bad is X? (Score:5, Insightful)
Re:Just how bad is X? (Score:5, Informative)
Which means Apple may have a Unixish personality of their Mach core, but out of the box, no Unix GUI tools work.
And if you think Apple, who routinely sue people for producing OS X look-a-like themes would stand for you cloning the Quartz API, you can pass me some of whatever you've got.
Re:Just how bad is X? (Score:2, Informative)
Sure, people complain how slow Quartz can be and I admit that it is very slow when resizing windows, but XFree86 is actually slower on hardware with similar speeds, Don't believe me? Run the newest KDE with all the effects on (like animations) and AA fonts on a 500MHz machine, then play with OS X on a 500MHz iMac, You'll find Quartz to not only be faster, but better looking to boot.
Don't diss Quartz, it can do awesome stuff (microsoft's GDI+ doesn't stack up to it either.)
Using Quartz, you can actually draw things at theSUB-pixel level, it does this by varying the intensity of what you draw and can be very useable in real world appliations. Imagine software for planning projects and suchusing timelines. With Quartz, you could zoom in and out of the timeline in real-time AND be able to actually READ and see the diagrams even at 10% of their normal size!
To sum it up, Quartz is good sh*t!.
Re:Just how bad is X? (Score:2)
Or you could use X render which allows all of this to be easily implemented very efficiently in client side libraries. Basically the X framework is powerfull enough to give you choice and see which method works best.
Re:Just how bad is X? (Score:5, Informative)
Anyhow, Display Postscript was not intended to be an extension to X11, that came AFTER it was implemented on NeXT. Remember OpenStep on Sun and HP, thise systems only had Xwindows, so a XDPS system was needed for them only.
Another point, XRender works very similarly to how Quartz does. That is, clients draw in a pixmap and ask the Server to draw it (vs. asking the Server to just draw it). The WindowServer in OS X is kinda like a XRender only X11. Drawing commands are not sent to the WindowServer, only the client's pixmap of what their windows should contain is "sent" (shared really) to the Server. Hence, a lightwieght Window Manager.
Re:Just how bad is X? (Score:3, Interesting)
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.
Re:Just how bad is X? (Score:5, Funny)
Which means Apple may have a Unixish personality of their Mach core, but out of the box, no Unix GUI tools work.
Good point. The Mac has no GUI tools and Unix's GUI tools are world-renowned. Mac users are clamoring to use those Unix GUI tools. or was that vice versa?
Re:Just how bad is X? (Score:2, Insightful)
Re:Just how bad is X? (Score:2, Informative)
Sadly, none of these have anything to do with X windows. You can install OroborOSX (great software) on OS X, which gives you an x client and server, but you still can't acces Mac apps from another X-box.
I love Mac OS X, and a native X windows on it is my fondest wish for the thing. But I don't see Apple doing that any time soon.
Re:Just how bad is X? (Score:3, Insightful)
Well, that sounds like pretty gratuitous judgement to me. Would you please care to enumerate 'Is faults'[sic] ?
X might not be perfect, but it does the job. We can't allways break things so they get better easily.
Propose a better solution, implement it, make an easy migration path, become rich and popular and get all the chicks. (That's the Profit!!! part)
Re:Just how bad is X? (Score:5, Insightful)
So far, we have great 3D acceleration, direct video, anti-aliasing, and now dynamic sizing/resizing in X. And all with excellent performance that is equal to or better than the performance offered by Windows. And we retain the network-centric features and flexible, modular configuration that make X so powerful. And all of this while maintaining backward compatibility over a decade-and-a-half of software.
We'll replace X when it makes sense to do so and not before. Right now, there is no better (or even close to equal) solution.
Re:Just how bad is X? (Score:3, Insightful)
Re:Just how bad is X? (Score:2, Informative)
Re:Just how bad is X? (Score:4, Insightful)
Perhaps your setup is faulty. On my system (Athlon 900 with 1GB of RAM - granted I have a GeForce 4...) the KDE menu pops in, with no redraw at all. And this is in 1600x1200, 24bpp.
Honestly, XFree86 has never seemed slow to me. It does seem to be the weak link as far as system stability is concerned, though: X has been involved in nearly every one of the (few) system hangs I've experienced.
Re:Just how bad is X? (Score:5, Informative)
I then reclicked it, and there is no perceptable painting whatsoever. It's either there or it isn't. I can click over and over on it, and it pops back and forth (if I do it quick enough, I get a flicker effect and I think I can see where it is painting, but I'm not sure if it's just a optical effect of flipping back and forth).
KDE caches it's menu, and does a rebuild when you click it after n seconds of activity (the value is in a Properties panel somewhere, iirc). My guess is that the "repainting" is actually KDE rebuilding its menu after a period of inactivity.
--
Evan
Re:Just how bad is X? (Score:3, Informative)
I have a set of boring-ass old PII/400 workstations with 128MB memory here running original GeForce256 cards using the NVidia driver. Everything in KDE -- window decorations, menus, anti-aliased text, scrolling content -- draws instantly, just as it does in Windows. There is none of the 'paint across the screen chunkily' problem you describe. Maybe it actually is the drivers. Did you ever think of that?
And on this same network, there are two headless Slackware 8 servers on which I often log in to KDE remotely. This is only a 10 megabit network and yet the KDE desktop works wonderfully; there are no real slowdowns whatsoever compared to the Citrix clients I've used elsewhere on the campus network.
Something is clearly broken on your setup.
Re:Just how bad is X? (Score:3, Interesting)
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.
Re:Just how bad is X? (Score:3, Informative)
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.
Windows has never had -- and still doesn't -- rotation, which the XRandR also provides. Cool, now I can tilt my monitor on its side and view things in portrait mode.
The Mac supported this with certain display hardware (the Radius Pivot comes to mind), but most Mac hardware (of System 7 vintage, anyway) didn't support any resizing, dynamic or otherwise.
I can click the [Windows] 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.
Then something is seriously fucked up with your Linux/X server configuration. I'm typing this on a P-III 550 with 512 MB RAM and a Matrox 200 graphics card, and "instant" is the word I'd use for the graphics. On a P-166 with 64MB and cheap S3 ViRGE graphics, it's a little slower to start drawing a menu, but once it does start the menu appears quickly, none of this "chunkily" stuff.
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.
Umm, maybe because Windows 2000 server doesn't speak X Windows? (So, how do I set the DISPLAY variable in Win2K?)
Re:Just how bad is X? (Score:4, Interesting)
+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.
Re:Just how bad is X? (Score:2)
>>>>>>>>>>>
That's like claiming GDI has "user usability" issues!
Re:Just how bad is X? (Score:5, Insightful)
Re:Just how bad is X? (Score:3, Insightful)
Free software development has a different set of standards to work by than commercial software. What this article says is probably true for commercial software, but there the motivation is to make it work and sell it. Free software is different in that selling isn't a factor. Usage is nice, but the most skilled open source programmers are artists. And it shows! We may not have produced a full MSOffice clone, but I'm writting this from a Linux box in Galeon, using Mozilla. I don't have Windows on my machine, and don't want it - Linux is an excellent system. Mozilla is a tremendous piece of work - in my estimation, the rewrite has done a lot of good. Yes we had to wait, but in the end it produced results.
Maybe the results are not so good for Netscape the company, but Netscape the browser is a lot better off. In free software, the program means more than the company, which is a very foreign mindframe to corporate types. Understandable.
But that's why people are interested in a total redesign of X - we don't have to care whether or not it takes five years or ten, whether we will have enough market share to pay costs. It's developed as a hobby by people who love doing it. We aren't sweating timelines or market share. Berlin is very slow, and may or may not ever replace X, but so what? They like developing it, it undoubtedly has advantages and flexibility, and may someday change the world of free software. Same with GNU Hurd or EROS. Totally cool ideas, total rewrites of everything, not fully developed but really neat and potentially very useful.
So while it wouldn't make sense IN A COMMERCIAL SETTING to replace X, in the artistic world of free software it does. And since both X and whatever replaces it can be maintained and work together (Both DirectFB and Quartz can handle X running alongside them, for example, and if Berlin can't yet it will surely be able to) we can be backwards compatible and functional while reaching for the stars feature and style wise.
Re:Just how bad is X? (Score:2)
Long live X11
Re:Just how bad is X?-X trolls (Score:2, Insightful)
I think the XFree86 guys are better aware of what's needed than any 'X' Troll.
Re:Just how bad is X? (Score:2)
Quartz [apple.com] seems to work pretty well for me. Of course, it's proprietary.
The problem with replacing X is, the biggest problem is not X itself, but inconsistency between applications. UNIX/Linux needs a consistent toolkit that everybody can use, with enough UI features (such as a standard Open File dialog, for example) that application developers will use all the standard APIs instead of making up their own stuff. Want to customize your desktop? Hack the toolkit so the Open File dialog suits your taste across all apps, instead of hacking each app one at a time. Hack Qt and gtk+ to act as wrappers on top of the standard toolkit, so a KDE or Gnome app will look the same as anything else.
Once the toolkit is in place, every application would have to be updated to support it. This means adhering to specifications that seem arbitrary (for example, what should "Options" or "Preferences" be called in every application, and what menu should it be in?). Apple's gotten a lot of things right over the years (and then broken a few things in Aqua).
Why won't this happen? Because A) not enough of the right people see a need, and B) every X application would need to be rewritten to do this properly, which isn't really possible.
Re:Just how bad is X? (Score:5, Insightful)
(Yes that's right. Only because of a fault in the architecture you should "give up and replace" something.)
The awkardness of changing resolutions (which I personally don't think being such a big deal. How often do you change resolutions anyway? And with the advent of TFTs you shouldn't change them at all) was a flaw in the implementation, not the architecture. And this will be fixed soon which is good news.
Re:Just how bad is X? (Score:2)
Re:when, oh god when (Score:3, Informative)
Re:when, oh god when (Score:3, Informative)
or just the post, for christsakes.
The feature you're asking for is exactly
what this extention allows.
Comment removed (Score:5, Insightful)
Re:Fix this (Score:3, Insightful)
Clipboard (was Re:Fix this) (Score:5, Insightful)
In every serious X app you should be able to do both of the following:
1) Cut, Copy and Paste things through the system clipboard using menu options, keyboard shortcuts etc. as appropriate. e.g. Ctrl-X for cut in most GNOME, KDE apps. This works almost exactly like Windows.
2) Quick copy using the middle mouse button, select text in any application, then press the middle mouse button to paste that text in any other application.
If they don't work in your favourite apps, check for a new version. If that doesn't work either, file a bug, post to the mailing list, write to your democratic representative or complain ABOUT THE SPECIFIC APP on Slashdot. If you aren't specific no-one can help you.
Caveats:
Old KDE (pre 3.0) and Qt (ditto) apps (e.g. Opera and many installs of KOffice) don't work because Trolltech screwed up. Upgrade
Venerable old xterm doesn't have Cut/Copy/Paste menu items (most users don't even know it has a menu) so you can't use the clipboard only the fast copy feature. Use one of the many other modern terminal apps if you
Earlier (e.g. few months old) stable releases of Gnumeric make the same mistake as Qt2.x. Upgrade to the latest release.
GNU Emacs (but not XEmacs) has totally bizarre clipboard behaviour unrelated to any standard, principle or sense of reason. Use XEmacs or complain to your favourite Emacs maintainer.
Re:Proof of concept (Score:4, Insightful)
But now that we have more and more normal desktop users at least considering Linux, it's become more pressing.
I think you'll find that from deciding to do the work, to actually finishing did not take very long at all, in the scheme of things....
Re:Proof of concept (Score:4, Interesting)
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?
Re:XFree 2002 = Windows 95 (Score:4, Insightful)
I can see why this kind of feature would be important for Windows users. Afterall, if you had to reboot every time you changed your resolution you'd never get anything done.
Re:This is Silly... (Score:5, Insightful)
In that sort of world, it's a lot easier to specify how big you want things to be than to specify how many pixels anything should be.
Re:This is Silly... (Score:3, Insightful)
Um, if I were a limey, I would be using metric. Americans are the only people still using Imperial units like inches.