John Carmack Is Interested In Wayland On Ubuntu

[elanthis]

There are many myths regarding Wayland. One of them is that somehow it will lead to increased performance, because it removes the server-client model.

Interestingly enough, even some of the original X designers and current big-time contributors agree that Wayland's design does, in fact, result in more efficiency and speed.

Wayland really is just about cutting out the cruft. Nowhere does it force any Windows design on the user in any way that X does not. People who don't understand much about X or Wayland (i.e. you) tend to associate the idea that Wayland prefers client-side window decorations with a ton of problems in Windows. Basically, you are associating a particular implementation with a general idea, which is silly. Windows apps don't lock up the desktop because they use client-side decorations (and, in fact, they don't lock up the desktop ever at all in Windows 7, despite still using client-side decorations).

Besides that, GTK+ and Qt already started adding client-side decorations long before Wayland started. And many popular X apps have used client-side decorations for well over a decade, including such olden popular apps like XMMS and modern popular apps like Google Chrome.

Client-side decorations fix a TON of problems that are unfixable in the traditional X model of having a separate app draw decorations. Totally broken things like out-of-sync rendering, inextensible window border contents (and hence tons of wasted space), and poor integration between the content and the chrome.

It's worth noting that client-side decorations do NOT mean client-side window management! Many of the Windows XP bugs (which is a non-composited desktop, I might note) related to window management would not exist on Wayland with client-side windows.

As a final point, nothing in Wayland actually _forces_ client-side windows. It's just that Wayland is written optimized for that case, unlike X which isn't optimized for anything. Running a window-manager and a compositor that does server-side decorations is every bit as possible in Wayland as it is in X, it just isn't something anybody's bothering to do because anybody who actually writes toolkits and GUI apps can't stand the traditional X way of doing things; it's just clueless users who can't disassociate the Windows implementation specifics from a broad idea who actually bitch about client-side windows.

But this is simply not true. It removes significant funcionality

Except it doesn't remove anything that you don't get back in a better way. This claim is generally made by people who think X remoting is useful or interesting because of X itself. All that any of those people care about is application remoting; the fact that it's happening over the X protocol is completely and utterly irrelevant!

They then claim that it's impossible to do without X because VNC remotes whole desktops and VNC is generally crappy. In other words, they are claiming that the only remoting technologies in existence are X and VNC. That is utter bullshit, of course. Even most people who do remoting on X are doing it without using the X protocol anymore, because the X protocol is actually a really horrifically bad protocol for remoting modern applications.

The really great thing about Wayland is that it actually makes modern, efficient, and flexible remoting _easier_ than X traditionally does! The entire compositor design of Wayland makes it trivial to slap in remoting in a highly efficient manner.

The only feature that might actually be lost is remote-GL, but nobody serious uses that anymore, because GLX is utterly and completely out of date with the current OpenGL specification. You can't remote any modern GL application without using proprietary GLX extensions; and if you're already willing to use proprietary remoting protocols, why cling to X in the first place?

But if you are smart, you won't bet your money on X disappearing for a long time...

Which is the same thing that the Wayland developers themselves state. An X to Wayland transition can happen very gradually and on an as-needed basis. One of the original primary goals of Wayland wasn't to actually be the new tech apps are written against, but instead being the abstraction that X itself is written against.

Right now, X does a ton of crap directly with hardware or hardware drivers (even in the new KMS world), tying it down to specific OSes and specific technologies. You want to get a new graphics feature, you need to update your kernel and X, despite the fact that X is just a protocol, windowing layer, and event I/O dispatcher! That's silly. Worse, the entire X protocol and design makes many new desktop features impossible to implement intelligently, like a shared desktop system. (It's pulled off now with a series of hacks that has a ton of issues that degrade performance and security.) It's very non-ideal.

Instead, X can sit over Wayland. Wayland becomes the low-level abstraction to the hardware interfaces. It is even lower-level than X, allowing for much more efficient multiplexing.

So the way things will work in the future is NOT App->Gtk->Wayland but rather App->Gtk->X11->Wayland.

At some much more distant point in the future, the X11 stack may start to fade away. This will only happen when all the popular apps implement more pluggable toolkits (which means LibreOffice/OpenOffice in particular needs a shitload of work) and someone shows the world that remoting on Wayland is every last bit as easy as it is on X but even more efficient (this is more than possible, it just hasn't been written yet, as Wayland is still in early development, obviously).

What is more likely to happen is that a handful of apps will transition to natively using Wayland to bypass X. For instance, full-screen games would not need a single feature that X offers, and can run way more efficiently without the bottlenecked X design by talking to Wayland directly. Your standard desktop apps are less likely to be made native Wayland clients because there's significantly less to gain there, but the incompatibility with current common X desktops would be annoying for some users. X sticks around those apps for the foreseeable future.

You could argue that X can keep evolving, sure. Anything Wayland does could, in theory, be added directly to X. At some point, though, that stops being feasible in the current Xorg implementation. To get Xorg up to speed with what Wayland is capable of basically requires rewriting huge portions of the internals of Xorg... which is basically saying, "we don't want Wayland because it's written from scratch which is dumb, so instead we're going to write something else from scratch but claim that isn't dumb because we said so." Oh, except that Xorg rewritten would have to have all that old crufty protocol code rearchitected to support the X protocols that almost nobody uses anymore as well, because that's how the protocol works and it has to be there.

Instead, the intelligent thing to do is to Wayland running, get the hardware abstractions moved there, and then gut all the hardware crap out of X and let it sit as a protocol veneer over Wayland. You get to keep all user-visible features of X and all of its ABI compatibility, but you also get a better and more modern graphics stack that can actually continue improving without being stuck with the design decisions of X.

Finally, the X-on-Wayland idea rubs people wrong who bitch that X on Windows or X on OS X is such an awful experience. They for some illogical reason think that it's because X is not talking directly to the hardware on Windows that X on Windows sucks. That's incredibly idiotic. X on Windows sucks because Windows apps look and feel one way and X apps look and feel a different way. And that's because X apps are written with X toolkits and Windows apps are written with an entirely different set of toolkits. On the other hand, a Wayland GTK+ app is going to look and feel identical to an X11 GTK+ app. The underlying protocol used to talk to the hardware/window/IO abstraction layer is totally irrelevant.

There may well be technical problems with the design of Wayland, but nobody has actually pointed any out yet. At best, all that any of the nay-sayers have managed to do is scream "I don't understand what I'm talking about!" at the top of their lungs (in slightly different words).

Wayland is obviously not going to replace X entirely, or even mostly, anytime in the near future on consumer desktops. It's going to take years at best before X becomes irrelevant, yes. Nobody involved with Wayland has ever said otherwise.

[movieman]

I'd certainly agree that there are good reasons for wanting to replace X. The big problem with Wayland is that it's a huge step backwards, tying you heavily to local hardware and local configuration in an era where network connectivity has never been better or simpler.

When X was released it was a huge step forwards from the kind of things that existed at the time (e.g. Sunview, where each application had to include all the code to render its own windows direct to the framebuffer). Whatever replaces X should be at least as far ahead of what X does as X was at the time, not a reversion to technology from the early 80s.

[movieman]

Interestingly enough, even some of the original X designers and current big-time contributors agree that Wayland's design does, in fact, result in more efficiency and speed.

Talking to local hardware is always going to be more efficient. But there are good reasons why we implemented multiple abstraction layers between that hardware and the applications running on it; having every application write directly to GPU registers would be more efficient, but a lousy design.

Client-side decorations fix a TON of problems that are unfixable in the traditional X model of having a separate app draw decorations. Totally broken things like out-of-sync rendering, inextensible window border contents (and hence tons of wasted space), and poor integration between the content and the chrome.

So what do you do when I'm running a Wayland application from one machine and displaying it on another with a completely different user interface? Why should remote applications look completely different to local applications?

Ah, but you don't support that anyway.

Except it doesn't remove anything that you don't get back in a better way. This claim is generally made by people who think X remoting is useful or interesting because of X itself. All that any of those people care about is application remoting; the fact that it's happening over the X protocol is completely and utterly irrelevant!

Yes, but they also don't want it to suck.

Even most people who do remoting on X are doing it without using the X protocol anymore, because the X protocol is actually a really horrifically bad protocol for remoting modern applications.

Most people doing remote X are using SSH, which forwards the X protocol over SSH. SSH may be doing some tweaks to remove the inefficient round-trip messages, but X goes in at one end and X comes out of the other end.

The entire compositor design of Wayland makes it trivial to slap in remoting in a highly efficient manner.

How? Everything I've read about Wayland says it just gives buffers to applications and then composites whatever the application writes into them. How can you implement remote rendering in a 'highly efficient manneer' with such a design?

[Djhg2000]

I'm actually all for the switch to Wayland since it will doubtlessly push graphics vendors to release decent open source drivers.

Forget about NVIDIA for now, but ATI might put more effort into the Rx00 drivers and Intel is pretty much there already.

[hiryu]

What I'd like to know is how many the problems with Xorg are actual problems with X11 itself, or simply problems with the Xorg implementation of X11? I really have no problem if things such that Wayland becomes the renderer for X11. If that would improve things while letting us keep full ABI compatibility with X11/Xorg, then fantastic!

If Wayland can truly bring us a faster, more responsive, and a more modern composited desktop, then I think switching to Wayland while dropping all remoting capabilities (except rootless X11 for legacy) apps would still be a net win (but not a very big one). If Wayland ends up simply handling input, rendering, talking to hardware, etc (but Xorg still does everything else) while managing to address many/all of today's issues, this is a big win.

Also, if X11 is, by today's standards, a terrible protocol for remoting, perhaps the X12 draft could be finalized and implemented as a/the modern remoting protocol for Wayland? Perhaps this would be the best win.

[FunkyRider]

Well, who the hell wants to run a remote application and have it's interface rendered in local machine nowadays?

The latency spent transmitting rendering commands and bitmaps are far higher than just running it locally. This design is so 1950's.

It's a good wish but in the real world, it doesn't really work. It never worked for me.

[Adarion]

As long as Wayland lacks network transparency I think it would be a bad idea to replace X11 by it.

[Michael]

Maybe short stories like these should be put on twitter/identi.ca. Then people who want news now can find it there. Later on you can create a story on this site which sums up all the little stories with links to further information.

Is that doable?

Nope, no ad revenues from Twitter/Identi.ca.

[ethana2]

Canonical needs to hire this guy and put him on Wayland full time. When he's done with that, they should hire him to port every major 3d game to it, and then get Tremulous 1.2 out before DNForever :P

[drag]

What I'd like to know is how many the problems with Xorg are actual problems with X11 itself, or simply problems with the Xorg implementation of X11? I really have no problem if things such that Wayland becomes the renderer for X11. If that would improve things while letting us keep full ABI compatibility with X11/Xorg, then fantastic!

What ABI do you want to be compatible?

X is complicated

X Clients = Your applications
X Server = Your renderer/display manager
X Windows = Networking protocol
X DDX = Device Dependent X. Your '2-D driver'
X DIX = Application libraries and network API


Which part do you want to keep?