The Wayland Situation: Facts About X vs. Wayland

[GreatEmerald]

Question for everyone else: Would you guys be interested in a systemd / SysV / Upstart comparison as well? I was toying around with the idea in my head, hadn't made up my mind yet.

It would surely be interesting (and add OpenRC as well). Also, thanks for the nice article.

[blackout23]

So wayland only needs EGL + that one extension? What about KMS? I'm pretty much a noob, when it comes to technical details but what's the reason why only open source drivers support KMS to begin with? Sounds like it can't get implemented into closed-source driver due to legal issues. So will we every have prop. NVIDIA drivers with KMS?

[Moiman]

What is status of xwayland and when is it getting merged upstream?

[frign]

Little errors

VIII) The window tree is a complete mess. Under X every input and text box was its own window which was parented by the window above it. Which is why no one understands the function that validates the window-tree. REAL (Eg: Not Core X11) Toolkits threw this out the the window a long time ago. No pun intended.

V) “Wayland can't do remoting.” Wrong. Wayland should be BETTER than X at remoting, partially do ( --> due to) its asynchronous-by-design nature.

VI) “Wayland breaks everyone's desktop.” Also wrong. Once XWayland is finalized and merged we should have more-or-less perfect backwards compatibility because every X app just gets its own mini X-server to deal with. There is one known snag and thats with window transformations because an app thinks its in the top right corner of the screen (yay global coordinates) [...]

I) “Every frame is perfect.” Wayland's main goal is that no matter how high the system load is,

Let the clients handle things(,) they can change - they can break (things all) everything they want because it's THEM who (has) have to deal with the fallout of (that) such a breakage.

III) Hardware specific backends. I'm sure some people saw that the Rasberry Pi has got a Wayland specific backend(,) and how it allowed the hardware to be taken advantage of more fully. It wont be necessary for all things(,) as most things WON'T need a hardware-specific backend...but it sure (its) is nice to have it available. It means we have freedom, we have the choice to make specific tweaks if we need to. Or if we realize down the road that the main backend has some architectural flaw in it, we can (change) swap it out with one that doesn't.

Seems like a case of German English. And before you start attacking me for being an obvious grammar-Nazi: I am German myself and of the opinion that those sent-in articles need some more proof-reading before being published.

@Article: Great work on wrapping it all up that nicely!

[b3nn0]

What will happen to the several less frequently used X extensions in XWayland?
I'm especially thinking of stuff like Xtest or Xrecord. Will stuff like that still work in XWayland? I imagine that this is not possible, because the X client can't "break out of its virtual X server"?

Also, right now it is possible to - in addition to using Xtest - send custom X events via XSendEvent() to other clients. I guess it will not be possible to send e.g. key events from Xwayland to a real wayland client, right? Or from an XWayland client to another XWayland client?

Asking this because I'm developing Robotux, which is a macro recorder that heavily relies on this functionality.
I think a complete rewrite will be required to get this running on wayland, right?
And then again, will it be possible to inject input events the other way round (i.e. sending events from Wayland to an xWayland client)?

Thanks

[frign]

Events

What will happen to the several less frequently used X extensions in XWayland?
I'm especially thinking of stuff like Xtest or Xrecord. Will stuff like that still work in XWayland? I imagine that this is not possible, because the X client can't "break out of its virtual X server"?

Also, right now it is possible to - in addition to using Xtest - send custom X events via XSendEvent() to other clients. I guess it will not be possible to send e.g. key events from Xwayland to a real wayland client, right? Or from an XWayland client to another XWayland client?

Asking this because I'm developing Robotux, which is a macro recorder that heavily relies on this functionality.
I think a complete rewrite will be required to get this running on wayland, right?
And then again, will it be possible to inject input events the other way round (i.e. sending events from Wayland to an xWayland client)?

Thanks

The event-control will be handed out to the compositor.

[GreatEmerald]

Seems like a case of German English. And before you start attacking me for being an obvious grammar-Nazi: I am German myself and of the opinion that those sent-in articles need some more proof-reading before being published.

You're right about some of those, but the last two were actually mostly correct as they were in the article. "No matter the system load" is fine by itself (not necessary to emphasise high load, as the point is that it works perfectly no matter what the load is, high or low). Many commas that you have added are also completely unnecessary (English is a very liberal language when it comes to punctuation, to the point where you can create complex sentences without any punctuation). In fact, a comma after "things" makes no sense whatsoever, and you don't put commas before "and" unless it's to end a subordinate clause or connect two different clauses. "Break things all they want" is also valid, "all they want" is a phrase and "break things" is valid on its own. "it's THEM who has to deal with the fallout" is wrong in both cases, it should be "it's THEY who have to deal with the fallout". "Of that breakage", while not the nicest way to put it, is still valid. "I'm sure some people saw that the Rasberry Pi got a Wayland specific backend" is correct, because "got" means the same as "received", and it's referring to a specific action in the past.

[curaga]

I'll try to address the remoting issue as clearly as possible. Please correct me if I'm wrong at any point.

1. Saying "please draw this text here" is much more efficient than sending a rendered image of the text. Especially when scrolling.

2. Wayland (compositor)-level remoting can never do anything better than send images. Any optimizations still only work at rendered image level.

3. Having such efficient remoting built-in, thus available with all apps, is a great advantage for a platform.

4. X was originally designed like that, but due to limits ended up sending images.

Thus..

5. The proper course to keep this platform advantage would be to design a remotable protocol usable by modern apps.

6. Wayland people proposed remoting at a toolkit level, and image-level remoting at the Wayland level. As established above, image-level remoting is inefficient, and toolkit-level remoting would forgo the platform advantage, by only enabling efficient remoting for certain apps, not all.

--

This is the core issue.

[m0nt3]

How will wayland handle alt+tab a full screen app, like a game?

[cmr~]

How will wayland handle alt+tab a full screen app, like a game?

Up to the compositor. Just like in X, where it's up to the window manager.