The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013)
Mladen Mijatov13 HN recommenders · recommended in 10 months, 2013-2026
104K views · 13 years ago · talk · evergreen
Daniel Stone, a longtime X and Wayland developer, explains at linux.conf.au 2013 why X11's design became untenable and what motivated Wayland. The talk walks through X's history and accumulated cruft.
HN treats it as the definitive, funny and educational answer to why X could not be fixed, and links it in almost every Wayland vs X argument.
45:35The real story behind Wayland and X
Linux.conf.au 2013 -- Canberra, Australia
46K views • 11 years ago
45:35[Linux.conf.au 2013] - The real story behind Wayland and X
HackersOnBoard
35K views • 13 years ago
2:26Qt 5 based 3D Wayland compositor
Samuel Rødal
133K views • 14 years ago
7:42:30XDC 2020 - Day 1 - September 16, 2020
X.Org Foundation
24K views • 6 years ago
42:20Writing a Wayland Compositor in Zig - Isaac Freund
Zig SHOWTIME
26K views • 6 years ago
46:06Gtk to Qt - a strange journey [linux.conf.au 2014]
Konstantin Bläsi
46K views • 12 years ago
45:33"A Political History of X" - Keith Packard (LCA 2020)
linux.conf.au
52K views • 6 years ago
27:27Faking RTX Global Illumination vs. RTX | 100% Ray-Traced Game, Pt 1
Gamers Nexus
260K views • 7 years ago
47:18The Tragedy of systemd
linux.conf.au
1.3M views • 7 years ago
40:45Exclusive: Metro Exodus Enhanced Edition Analysis - The First Triple-A Game Built Around Ray Tracing
Digital Foundry
915K views • 5 years ago
5:05New Voxel Engine Reveal - Crystal Islands Experiment
John Lin
394K views • 5 years ago
42:382021: Year of the Linux Gaming Desktop - Andrew Kelley
Zig SHOWTIME
15K views • 5 years ago
1:11:44DebConf 14: QA with Linus Torvalds
Adnan Hodzic
737K views • 12 years ago
48:13RIP Windows: Linux GPU Gaming Benchmarks on Bazzite
Gamers Nexus
1.1M views • 11 months ago
46:54"Write a single library to handle all input devices, it'll be easy" they said...
linux.conf.au
21K views • 6 years ago
2:08:02Alto System Project: Dan Ingalls demonstrates Smalltalk
Computer History Museum
36K views • 7 years ago
58:59GuiltyGearXrd's Art Style : The X Factor Between 2D and 3D
GDC Festival of Gaming
710K views • 11 years ago
1:22:13HandmadeCon 2016 - History of Software Texture Mapping in Games
Molly Rocket
15K views • 9 years ago
55:42CppCon 2019: Matt Godbolt “Path Tracing Three Ways: A Study of C++ Style”
CppCon
77K views • 7 years ago
1:04:04LISA11 - Fork Yeah! The Rise and Development of illumos
USENIX
310K views • 14 years ago
20 comments from Hacker News
Daniel Stone from linux.conf.au 2013, The Real Story Behind Wayland and X ▶ this video You can always use XWayland if you feel that way.
Don't take it from me, Daniel Stone has a whole talk on the motivation for Wayland: ▶ this video Broadly, the X Server has a bunch of capabilities which are irrelevant. The modern model is really Window <-> Compositor based, and the X Server protocol is just a pointless middle man in that exchange.
> I live in a cave and am not a system programmer -- what's so wrong with X11 so people need to replace it with something else instead of improving it? This 12 years old video explains it better than anything I ever seen: ▶ this video
The problem is that the X11 architecture has been dead for a decade. The X11 architecture was network-transparent drawing primitives. Almost all of modern X is done via extensions. Your drawing is done using OpenGL or some similar interface, buffers are passed using shared memory, lots of display metadata and configuration is done via extensions as well. The actual rendering is done by the window manager (assuming you are doing compositing). As Daniel Stone said, all that is left of "Core X11" is really bad IPC. (As the client talks to X which talks to the window manager which talks to X which talks to the client, requiring 2 round-trips for every request) ▶ this video So saving Core X11 is a dead end. All you have is a basic IPC system with unnecessary round-trips. So all that is left to save is the extensions. You can save GLX and the Vulkan equivalent but tearing them from the IPC is leaving not much behind. So really, no. The things that could be saved are so basic (like feeding input events) that it is better to just re-implement them using a better IPC protocol. For clients that need backwards compatibility there is XWayland (although it is limited for security reasons).
> Screenshots/recording should have been on the board from day one and they could have gotten to standardizing on how to handle them in oh 2013-2015? I agree that Wayland's development has taken far too long and the transition has been rocky. But what development team couldn't use more funding? Ubuntu throwing a tantrum after the ecosystem rejected Mir and not contributing to Wayland certainly didn't help. > What other OS makes you think about display servers? I am sympathetic to arguments that Wayland/Weston could provide more functionality out-of-the-box. The bazaar's fragmented mess of "desktop environments" is certainly not a strength compared to what the Cathedrals have produced. But Linux's uniquely modular GUI stack necessitates coordination across lots of projects to develop and adopt standards. But not doing anything and sticking with X11 would have condemned us to being stuck with an insecure, buggy, and visually glitchy mess forever. > Red Hat doesn't believe in the Linux ecosystem I have my qualms with Red Hat too, but my point was that Wayland was created by Xorg developers because they tried and failed to make X11 competitive. Seriously, just go watch this XFree86/Xorg/Wayland developer's talk [1]. [1]: ▶ this video
Mandatory video to watch for all X fans: > Daniel Stone ~ The real story behind Wayland and X' ▶ this video
> when in fact the lead developers on Wayland are the actual Xorg maintainers. Daniel Stone[0] incredibly funny and educational talk[1] from 2013 could help many critics who missed the 3 decade long ongoing discussion of why X is bad . We've talked about this already in the mid 90ies (when there were no alternatives) and now 8 years after this popular linux.conf.au talk, people still having troubles understanding why X has always been a terrible tradeoff for both security and performance (well for literally everything). [0] link [1] The Real Story Behind Wayland and X ▶ this video edit: BUT X IS THE UNIX WAY! << so what is the 1 thing X does, and what is it doing well?
This talk "The Real Story Behind Wayland and X" by Daniel Stone (a longtime X developer) may debunk some misconceptions in this thread: ▶ this video
I remember finding this video enlightening, a talk on the subject by someone who has worked on both X and Wayland: ▶ this video
Not many people use X forwarding, and X isn't really network transparent anyway. The X wire protocol is so chatty that modern clients do anything they can to work around it. See this Daniel Stone talk: ▶ this video
Microsoft spends millions for backward compatibility and they charge a fortune for that. This is an open source project with not as much resources and the core protocol of X was never made for GUI. It was made for displaying a cute clock on the screen when there was no concept of GUI. They extended it to do something it was never meant to do. Youtube talk about it: ▶ this video
"X isn't network transparent anymore" according to Daniel Stone (longtime X.org and Wayland developer): ▶ this video If you use X11 forwarding with any application that uses a modern toolkit (Gtk+ 3, Qt 5, maybe also Gtk+ 2 and Qt 4) you are just pushing uncompressed pixmaps over the wire, as a bad substitute for VNC/RDP/etc. Xpra adds image compression on top, AFAIK, so it should be slightly better. The entire video ( ▶ this video ) provides a good overview as to why people that have been working on X11 for many many years decided to start Wayland.
No. It's already basically feature-complete as compared to which parts of X11 are actually used these days[1]. X11 is burdened by absurdly obsolete extensions like drawing stippled lines, a font server, etc. See the talk by Daniel Stone[2] if you're interested in the kind of crud that's been cleared out. It's basically the kind of stuff that we will never go back to wanting in any type of server process. The trade-off between bandwidth and latency has changed fundamentally in basically all areas of computing, but especially anything to do with graphics. [1] Alright, there might be a few bits and bobs that are missing, but nothing major as witnessed by the very article under discussion. [2] ▶ this video
According to people in the know[1], X is severely bloated in terms of CPU usage, interface complexity, and useless code. X spends a lot of time performing useless actions, such as drawing a gray rectangle even when it knows that part of the screen is going to be rewritten by something useful. Going full-Wayland is bound to be lighter on the system. But traditional X clients run within XWayland. I don't know if XWayland offers anything more than compatibility, but going forward, as more and more toolkits and window managers wean themselves off X, "weaker" computers will have more resources to spend on doing useful stuff. [1] ▶ this video
The larger idea this fits into is getting rid of X11 all together. The inevitable replacement is Wayland.* One of the challenges of such a switch will that once you start using wayland, you'll have some older applications that cant talk to wayland, you'd have to start an X server to run that old application. If you have a wayland session on your computer, you don't want to hit ctrl-alt-8 to switch over to an X session running that single application, and then switch back and forth to wayland to use every other program. It would be nice if there was a X server that worked as a wayland client and could put the X-only application on your wayland desktop. That's Xwayland. * For a better explanation on ditching X, and what Wayland is: see this talk from one of the X dudes working on Wayland ▶ this video
> [href] Seen it, and seen the talk[1]. > we don't really "use" X these days GTK+ and QT do not use a lot of X, as they render all their widgets with (e.g.) libcairo.so and libpango-1.0.so that only treat X as a framebuffer. Unfortunately, projecting your own usage habits onto others is an easy trap to fall into. For example, one minor data point, from my desktop system - I use the built-in font server: $ rdb -q | grep 'URxvt.*font' URxvt*font: -xos4-terminus-medium-r-normal--14-140-72-72-c-80-iso10646-1 Why? Because it's (MUCH) faster to draw, doesn't slow down even remotely, and after is much clearer to read on the screen than the blurry mess[2] that pango/etc gives you. /// that said /// As I mention briefly, I was warming up to the idea of wayland. GTK+ and QT are certainly popular, and some things DO need to be fixed. The linked phoronix article (or talk) does bring up some good points. The massive amount of (serialized) round-trips to the x-server (even locally) that are mandated by the protocol is paticularly outrageous. If backwards compatibility and remoting can be maintained through some sort of extension (or whatever), then it could even be a nearly-seamless drop in. The clipboard and selection, on the other hand, have nothing to do with any of that. They aren't a performance problem, and there is no reason to remove it. In fact, given this is a big change in general, and an opportunity to fix some of the core protocols, why not /expand/ the idea to include a full
First of all, the UI is not the same when in phone mode and desktop mode. In desktop mode it runs traditional Unity and in mobile mode it runs Ubuntu Touch, a gesture based UI that only looks similar to Unity. I spent some time on a BlackBerry 10, and I loved it. Gesture based UIs are the future for smartphones. I'm willing to cut Ubuntu some slack on Unity and Mir. Despite all the haters, the latest Unity is actually turning out to be a decent UI. For those of us on 16:9 monitors, a vertical taskbar was the right choice. Vertical taskbars were broken for over 10 years GNOME[1], so I can understand Shuttleworths frustration. I also love the search bar lense UI. The mistake they made was shipping Unity half-baked. Yes, it can get unresponsive on low-end hardware. But much of this comes from poor 3D driver support under Linux, and bloated, slow, and outdated X[2] and compiz. The sooner those two die, the sooner we can have a responsive modern 3D accelerated compositing window managers under Linux. [1] link [2] ▶ this video
Daniel Stone actually did a talk involving much of the same subject matter called "The Real Story behind Wayland and X". I'd recommend that over this article (which was partially written by the same guy). He's actually a really charismatic speaker. ▶ this video
Here's a good video explaining some of X's problems: ▶ this video Long story short: the X11 protocol (which Xorg/X is an implementation of) was created in 1980, and was made for drawing stuff like this: link The important distinction between X and any modern display server is that nowadays we separate compositor (that which composites application content into what you see on the display) and toolkit (that which draws text boxes, buttons, progress bars etc.) into two. X was designed to do both these things. This isn't practical for several reasons. So far people have worked around this issue, but many feel it's time to stop working around it (since the X codebase is a complete mess due to this "working around"), and develop something from scratch that does what we want for a modern desktop in 2013.
The Wayland people really sound like they know what they are talking about, based on decades of experience. See, for instance: ▶ this video Are these people designing a better answer to Wayland because it's really better, or because it always looks easy when you don't intimately understand the problem space? I honestly don't know, but it's a question I'd like answered before I get excited.