How Important Is The Wayland Display Server?

[phoronix]

Phoronix: How Important Is The Wayland Display Server?

Last November we detailed the Wayland Display Server, which came about as a lightweight alternative to the X.Org Server and leveraged the latest Linux graphics technologies (primarily kernel mode-setting), and is designed elegantly with the rendering and compositing all being done by Wayland. Quite a bit of work was going on with this project early on to the point of running two X Servers within Wayland and then talk of a Clutter back-end for Wayland, but over the summer there has not been much to report...

http://www.phoronix.com/vr.php?view=NzUzMQ

[d2kx]

I don't want to guess on this topic. If Mr. Deucher, Airlie and the likes will post about how they think Wayland is really needed than I think it's important. Until then I'll follow the drastic improvements in the Xorg stack even without Wayland.

I agree with the man that all the problems of the Linux desktop are being fixed right now, except Xorg which is developing too slow (I didn't say Mesa). It will be intersting to see what Google will unleash with their Chrome OS, because rumours are they've done a new Xserver or something in that regard.

[kape]

I don't want to guess on this topic. If Mr. Deucher, Airlie and the likes will post about how they think Wayland is really needed than I think it's important. Until then I'll follow the drastic improvements in the Xorg stack even without Wayland.

I totally agree with this sentiment. It seems to be mostly people who don't understand X who criticises it.

[pabloski]

I think mr. Lowe is right.

Currently the state of Xorg is not very good and we ( linux users ) experience problems everytime and in every possible situation.

But we must take in mind that gallium is ready to change the linux ( and possibly not only linux ) graphics scenario. With gallium we'll have a complete, organic, unique graphics stack that embeds 3d, 2d, video acceleration, gpgpu and God knows what other.

So I don't think Wayland is the only solution. But it is one solution, for embedded devices it is ( will be ) probably the best solution, so why let it die?

In regards to Google they'll do for chromeos what they have done for android, a proprietary graphics stack.

Will be good? bad? the best? I don't know, but surely Google will not make use of the current Xorg.

[BlackStar]

In regards to Google they'll do for chromeos what they have done for android, a proprietary graphics stack.

Will be good? bad? the best? I don't know, but surely Google will not make use of the current Xorg.

Any source for that? I've heard many people saying it but never seen an actual official statement or other proof that this will be so.

[combuster]

I think that in many ways Xorg is a card that we sould play with. They do have problems and they lack testers but they should ease the process of testing xorg rc's, I've tried the other day, compiled everything from git, compiled xserver 1.7rc but I've stumbled upon many errors during compiling and I had to manually satisfy some deps. If we all help in testing (and those who are able in developing) I think that xserver got a pretty big chance of being a stable and mature display server...

[rohcQaH]

Again, the real question is: What's wrong with the X server? And why does everyone assume Wayland will magically fix these things?

So the release planning on Xorg could be improved, but what else? The original author claims

But if I ever have a crash, or a freeze in GNU/Linux, it has to do with Xorg

solution: generate some backtraces, submit bug reports. I really doubt Wayland is any more stable than Xorg at this point, so why is wayland assumed to need nothing more than "some polish" while Xorg needs to be replaced?
Most crashes are driver problems anyway, and wayland will use the same drivers as xorg.


Maybe I need a different approach. If nobody can explain why Xorg is fundamentally broken, let's see if there are some arguments why Wayland is better. Again, quoting the author:

It has a very simple, ingenious design, and a very advanced feature set.

The simple design is due to a reduced feature set. Some of the missing features are legacy stuff that X keeps only for backwards compatibility - wayland achieves that backwards compatibility by using an X server, so it doesn't magically enable us to get rid of the legacy cruft anyway.
Some other features are simply missing. Network support isn't planned. Wayland doesn't even care about drawing or input (the client is supposed to take care of that itself.. somehow).
Compatibility is an issue as well, wayland requires KMS and thus won't work with certain gfx cards or different operating systems. I'd expect a "replacement" to work everywhere, not just in certain combinations of OS and hardware.

It is also quite modular, which makes it more desirable to a diverse community, AND makes it essentially future proof.

xorg is quite modular since 7.0, and over time, feature after feature is removed from xorg.
Input devices move from xorg to HAL.
modesetting moves from xorg to KMS.
drawing moves from xorg to G3D.

It won't be long until xorg doesn't even touch your GPU any more. By then, it will probably be possible to build a very small, very modular x server, that isn't much more than a piece of glue between those techniques and the xorg protocol. Maybe not quite as small and lean as wayland, but close.


Wayland can work on integrated devices, cell phones etc, where the hardware is simple and compatibility with older software isn't needed. But as soon as we leave that area, we need an X server. Adding Wayland on top of the X server does not reduce complexity.


Xorg can take care of setups with multiple heterogenous GPUs, multiple concurrent X servers with different input devices (MPX) and others. Wayland never will.


Let me finish this post by quoting the author of the wayland server:

X just isn't going aways anytime soon

[Kjella]

I totally agree with this sentiment. It seems to be mostly people who don't understand X who criticises it.

Or those of us that have the displeasure of messing around with xserver/xorg.conf. I've had to deal with modelines and EDID options and resolution switching not working and absurd amounts of crap with it over the years. I just gave up in the end on making dual screens work the way they did in Windows once too.

It's slowly been fixed, better autodetection, xrandr, better multiscreen configuration but it's been very slow. My impression is still that it's an outdated framework that doesn't cover modern uses like tearfree video playback or compositing/RDR well. But given the momentum it has, I guess it's better fixed in the system and then finally some codepaths just aren't called anymore on a modern system.

[elanthis]

It's slowly been fixed, better autodetection, xrandr, better multiscreen configuration but it's been very slow. My impression is still that it's an outdated framework that doesn't cover modern uses like tearfree video playback or compositing/RDR well.

And sentiments like this against X.org are part of why trumping Wayland up is so hilarious (I realize you weren't necessarily pushing Wayland here). Before X.org solved those problems, Wayland COULD NOT EXIST. Wayland is only able to do all the things it does because of the efforts done by the X.org developers, pushing KMS, DRI2, and Mesa development.

So people who think that Wayland is the solution to X.org's shortcomings are simply misinformed and best ignored.

People who want to argue that Wayland has a cleaner architecture are, on the other hand, quite right. In the long term, I have no problem if Wayland replaces X.org as the core display server. It's really all quite irrelevent to actual users though, because both are going to be using KMS, DRI2, OpenGL over Gallium3D, video acceleration over Gallium3D, and so on. The only difference is that X.org will natively support the X protocol while Wayland will need a separate X.org-based display server to support X applications.

It's worth noting to potential users that the (planned) Wayland architecture actually has a distinct disadvantage in that the compositor and basic window management functions are expected to be built into Wayland itself. That means that more general logic unrelated to actual rendering and input is built into the display server, which increases the likelihood of a crash bringing down the whole damn desktop -- especially if users want to be able to screw around with a myriad of user-created compositor plugins. The X model of having a separate CM/WM process means that if the WM or compositor crashes it can just be restarted without affecting the other applications running on the desktop.

[whizse]

But if I ever have a crash, or a freeze in GNU/Linux, it has to do with Xorg

solution: generate some backtraces, submit bug reports. I really doubt Wayland is any more stable than Xorg at this point, so why is wayland assumed to need nothing more than "some polish" while Xorg needs to be replaced?
Most crashes are driver problems anyway, and wayland will use the same drivers as xorg.

Yeah. I've had plenty of freezes in Xorg, but Xorg itself is almost never the culprit. These are GPU hangs in the 3D driver. The same driver the author supposedly wants to use in Wayland...

Anyway, your solution is still true, the hangs ARE fixed, the developers are very helpful and quick.

Things would probably be much better off if more people were testing stuff, and filing good bug reports.