More Work On Red Hat's Wayland Project
Phoronix: More Work On Red Hat's Wayland Project
Since publishing the world's first look at Wayland, a nano display server for Linux with an integrated compositing manager, there has been much interest in this emerging Red Hat project. While this project is still in its infancy, below are a few more notes about recent changes with Wayland. - Wayland now ships with glxgears and support for running it off this simple display server. - A README file has been published (available when checking out the code from git) on how to build Wayland from git when you have a system with kernel mode-setting and the Graphics Execution Manager...
It is not clear to me, why Wayland is made.
Is it to get rid of a legacy codebase?
Or will Wayland enable developers to do new stuff that xorg can't?
Afaik it's not even sure (or likely) that wayland will ever replace Xorg. It's more kind of a playground for ideas.
Well given the fact that qt is weighing in with their experience with qws, maybe this will becomes useful for systems with low system resources that want to maintain some sort of compatibility with xserver?
It seems to me like Wayland is to x.org (or at least the Xserver component) what Gallium3D is to Mesa. Y'know, take the latest, greatest ideas, push them to their full potential and make them do more of the heavy lifting. All the while, getting rid of all the other crap and putting it together on a limmer, trimmer code base.
That, or I'm reading it all wrong and I'm an idiot. One of the two.
Wayland isn't X. It doesn't support X clients. It doesn't support the same general concepts of X. It is possible to build an X server on top of Wayland, but Wayland itself does not replace X, and likely never will.
Wayland is a very, very simplistic (and hence very small) display system based around the concept of compositing. Some may see it as what X should have been, had X had the luxury of being designed for modern hardware capabilities and modern software requirements.
The biggest thing to note about Wayland is that it intends to build much of the functionality into the server instead of leaving it out in separate clients. The README/TODO even notes ideas like putting a panel into the server. This is great in terms of reducing resource usage and latency, but it poses some significant problems for general desktop users -- it would be the equivalent in many ways of saying "you must use X/Compiz/GNOME -- if you want to use another feature set, fuck off." It may support plugins at some point, making it possible for different desktops to offer multiple plugins... and since Wayland presumably is meant to run as the desktop user and not root, this would be relatively safe (though it would suck if a plugin was buggy and caused your whole desktop session to crash).
The second biggest note is that the Wayland has zero support for sub-windows, which are a necessary evil. The fact that it has no support for sub-windows means that excessive buffer copying is required to support video acceleration or windowed 3D, which is an obvious performance drag. It's true that sub-windows create quite a few problems and that most toolkits are getting rid of the use of sub-windows for most widgets, but they still solve a few problems that are not easily solved any other way and are simply required in a small number of important scenarios. It also means that window managers are no longer really possible.
Wayland assumes that clients draw their own window borders. This has a number of advantages, yes, but comes with some obvious downsides -- applications not written using the same toolkit are almost certainly going to look and even behave very differently in terms of window management. This is turn reinforces the point that Wayland is not meant for general desktop use, but for specialized, integrated appliances.
While an X server can be written over Wayland, it almost certainly would be less efficient on a general desktop machine than just using X with KMS/DRI2/Gallium3D/etc. In order to support modern features, X would have to emulate them over Wayland using a lot of buffers and copying.
Unless Kristian plans on altering some of the design choices to make up for these shortcomings, it's likely that Wayland is going to remain as either a research project or a highly specialized display system for embedded appliances.
@elanthis: very thanks for the enlightenment, i was pretty confused on what wayland means..
Well, so it's sad, because I really hoped of a new, modern replacement to old X... We are lagging years behind Apple with their Quartz..
Srsly,I bet Quartz is just as messed up under the hood as Xorg is.
Originally Posted by puelocesar
Well, it can be, we don't know, but at least it works WAY better! Faster and more lightweight too
Originally Posted by Zhick
I was horrified when I installed a Hackintosh on a Celeron D, using a VESA driver and it was much faster (2D at least) then my linux box, and it also could do shadows, transparency, scale and all these 2D fancy things without any lost of performance..
Don't get me wrong, freedom in linux and openness of the platform is much better then all that lock-in and arrogance from Apple, but we have to admit they really do nice graphics
Quartz might be messed up under the hood, but at the very least, they built it from scratch, based on what they needed, and based on what modern hardware can do.
X still has the problem that much of its internals are based on decades-old assumptions of needs, and trying to fix all that while maintain compatibility and continuity is a serious challenge.
I would welcome of new X implementation. Even neglecting the benefit of being able to build on a new, clean, codebase and not have the cruft and legacy code that have plagued Xorg, having choice is good, even for something as fundamental as an Xserver.
Choice is very useful in open-source software, and having choice in an Xserver might be helpful. Wayland, alas, is not quite it. (Although it is an interesting project in its own right.)