Guest post by Kristian Hogsberg, Red Hat Xorg developer and the key person behind successful projects such as AIGLX, has now started working on a new project called Wayland, a tiny display server and compositing manager.
In his latest blog post, titled “Premature publicity is better than no publicity”, he writes:
The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn’t going aways anytime soon. Many more details in the NOTES file of the project.
Phoronix is running an article on Wayland. Wayland is quite small, code-wise, as it consists of only 3200 lines of C, however, as Hogsberg notes, “it’s a very young project with a lot of FIXMEs and hand waving.”
yet another useless fork
Read the article. Read the project NOTES file. It’s not a fork, not even close. It’s really just a playground for some new ideas that may be used in X in the future.
Absolutely, this is not a fork at all. It is a completely new way to design a display server. Read the article linked to by the blog – http://www.phoronix.com/scan.php?page=article&item=xorg_wayland&num…
As others said, not a fork. Could still be useless though.
No more useless than any other playground. Try telling your kids that their favourite playground is useless.
True, but that can be said of all pre-alpha software. The fact is that the old X.Org code-base is old and has a ton of cruft. One way or another, the free software community needs to consider replacing it – if Wayland merely gets people to start thinking about doing so, I say Job Well Done.
Most of the cruft has been removed from the codebase. I’m sure there’s still a lot left, but the devs are keeping pace with removing unused and unnecessary components from the codebase. Just today there were half a dozen commits removing crap from the server.
I absolutely know that is has, and I truly am grateful for the work they’ve done on it. However, speaking as a software engineer, sometimes a total rewrite is required to move ahead – refactoring has its limits. Moreover, this project appears to be a complete paradigm shift from the old-style X.Org server, and that might be what is called for to solve some of the problems mentioned in the article.
You, sir have not read This article:
http://www.joelonsoftware.com/articles/fog0000000069.html
(Or you have and disagree with it…)
well, i’m into SW engineering too, but nonetheless i believe one has to be a little more pragamatic than to unconditionally accept such conclusions as those written in that article…
maintaining an old codebase instead of rewriting it from scratch does indeed make sense – when you have a working product, when you need to maintain regular and tight release cycles, or be certain not to miss a deadline, it’s better to add features, or cleanup or optimize in a cumulative fashion instead of starting anew
Since a program is a solution to a problem, then if the problem changes, it makes sense to find a new solution instead of trying to shoehorn old solutions “just because it exists”
in the case of a GUI architecture for a *desktop* Operating system, it makes sense to try and implement a clean design when the existing one does not actually work (as in accelerated *redirected* rendering on X) or is not workable (which is not the same, meaning that the effort taken by trying and update a codebase yields too little gains) and/or does not actually fulfills requirements any more
and the requrements of today’s desktop systems – and users- are not the same as when X was conceived… today one wants to:
have a look and feel, as consistent as possible throughout the desktop;
have a desktop experience ( made of moving windows, watching media, etc )as smooth as possible;
exploit modern HW (given that even low end ones support TL and shaders) as fully as possible;
remoting the desktop, which requires network transparency (in turn, the solution to the problem of doing administration on a server without being physically in touch with it – or sharing a single machine’s computing power across multiple users ) is no more a *stringent* requirement for the average dektop user (who btw needs as much computing power as the machine can give, all for himself )and has better and OS agnostic solutions (VNC in primis)
primitive rendering in the server is no more a requirement when applications, or the major portable toolkits, already have multiple render paths, for the local or remote cases, for rendering internally or using X11, or other libraries, and in some cases aim towards full HW acceleration (via common standard such as openvg)
nor is in-server text rendering, for the same reasons and because noone else uses the X font format other than X itself
look and feel customization can be retained in a more efficient and simple way by having graphic server / app server plugins implements what is now done in the window manager
all in all, there’s no reason the FOSS world cannot look at what is done elsewhere (BeOS, NextStep, if not OSX or Haiku) and implement a streamlined app server with an optional X server for legacy support – no reason apart from NIH syndrome…
Edited 2008-11-04 17:55 UTC
The same was probably said of an unportable 386 minix clone.
1. Not a fork
2. Name some of the other useless forks you refer to?
yet another useless comment
Finally someone starts experimenting with new ways to do a graphical server, without all the obsolete stuff stuffed into X11.
I don’t expect X server to go away, there are lots of useful stuff there. Eventually this new protocol could become part of it (i.e. X server could become support layer for multiple graphical protocols).
Er, hello!? Syllable http://www.syllable.org, Haiku haiku-os.org have had slim, modern, legacy-free GUI appservers for years!
you’ve forgotten SkyOS, and the most prominent of all non – Windows desktop Os’s, Mac OS X 😉
btw, with Vista, Windows too has gained a quite similar visual stack architecture – the DWM does pretty much the same task as the “application server” of other OS’s
in reality, it is Linux that is the only one alleged “desktop operating system” still stuck with such an old and overly complex GUI system, instead of a more modern and streamlined architecture…
Edited 2008-11-04 15:42 UTC
All the OSes use more or less the same structure as Linux. Maybe X needs some optimization, but it’s not fundamentally different from what the other OSes use. They all have graphics servers and client-side APIs just like X does. Even in older Windows’ this was the case, although the graphics server happened to live in the kernel.
There is so much misinformation and hatred about X floating around the Internet these days. I wish it would stop.
Umm, don’t BSDs also use only (rarely anything else but) Xorg?
yes, as they are actual UNIXes and are bound to use it, as such
otoh, they look more like server Os’s to me, and don’t seem to claim to be “ready for the desktop” as much as Linux does 😉
Edited 2008-11-04 16:50 UTC
NetBSD uses XFree86
Openbsd uses x.org and the sames goes for FreeBSD.
If this (or X12) moves on, it will be designed around kernel graphic memory management, kernel modesetting and multiple direct rendering clients. Other OSes will have to design, or port those bits to their kernel to support properly apps that use new features. They can choose to stay with X11 as well if they wish.
Currently “classic” direct rendering and Xorg userspace driver approach is okay for BSD/Solaris except for compiz+OpenGL app combination or for some OpenGL extensions.
Yes, this looks like a playground that tries to start design of a X11 protocol successor. Complex bits needed for the new approach are landing in kernel these days.
I think there was an implicit “for Linux” in there. Obviously other OSes have different graphics systems with more or less legacy stuff thrown in. Also, any standard used by lots of apps is going to develop legacy hair. It’s just a reality of infrastructure stuff like this. Deal with it.
Any competition in the X windowing system is welcome. This will most likely inspire Xorg developers as well.
We see the same healthy competition in the browsers. It started by Google that released their Google Chrome. The next release of FireFox 3.1 (currently in alpha) has an extremely fast Javascript JIT-compiler just like Chrome does: except is even more speedy.
This is not really competition for X.org. It’s a playground test BY a Freedesktop developer. And X.org is progressing along quite quickly at the moment. So much of the stack is being replaced, rewritten and redesigned that I imagine within 2-3 years, it will be quite different from what we saw during the XFree86 days, if it isn’t already. KMS, GEM, DRI2, Composite, Gallium3D, XInput2, evdev — all these things have happened since the end of XFree86 and there’s more coming down the pipeline.
Not sure how much different this will end up looking than DirectFB – it already has a bunch of accelerated drivers, has a ‘native’ GTK+ backend for modern GUI apps without X11 and has an X server that supports compositing etc. that runs on top of it.
Its been around for many years now, and provides decent performance (at the expense of CPU), even on a non-accelerated framebuffer.
The Xorg developers regularly get rid of old stuff that’s no longer used, and they also redesign Xorg on-the-fly as they are developing other things.
I don’t know where people get this idea of “X is broken” or “X is archaic”. I don’t have any problems with Xorg, and judging by the amount of progress that was made on it recently, I’m surprised anybody still holds this view.
Having said that, if somebody wants to work on a small side-project of a different sort of graphical server, then they should go right ahead and do it.
Xorg is working fine these days. However I don’t think it is feasible to extend the protocol for something like object API (like this one), for that it has to be redesigned (otherwise you end up with very ugly workarounds). That is a syntactical argument for an overhaul.
Also there are some issues with exhausting extension ID numbers, so it’s not extendable forever (unless you go into hacks, again). Sometimes it’s just simpler to make incompatible changes (and keep around new and old protocol, separated).
If community is going to break the API, it’s the opportunity to implement some other postponed or worked-around features (reconnects and server migration, anyone?). Not that Wayland approach is going to be a new API, but whenever they decide to bump protocol number, they better fix what they have to (and at least for aesthetical reasons, get rid of that 80’s API style).
There’s no point in breaking the API. Old stuff will be unused and barely supported, being of almost no cost to the project, and new stuff can be added, heavily-used stuff can be optimized. Thanks to widespread use of toolkits, most apps can seamlessly switch over to using new features without even having to recompile.
Something is wrong with x11, I have the newest and fastest ATI graphic card, ati’s own drivers ,modern 4core + 8gb ram and Debian linux 64 bits SID, AND YET the desktop is slow with compiz. Maybe x11 has an “elegant” network transparent design, but for me and most users, its not delivering… Linux graphical layer must begin to use todays modern GPU’s capabilites and develop another separate lightweight stack for linux on old and non-desktop computers.
Edited 2008-11-05 19:11 UTC
You do know that ATI’s drivers suck, right? Especially on Linux.