I’m sorry if it sounds harsh, but honestly.
I'm only frustrated that I can't get a straight answer as to what problems Wayland is solving that can't be solved with less difficulty and breakage by repairing X11. I'm sure the X.org developers have an answer, and I would love to know it, but I'm not getting it here in this comment tree.
Basically, X has a fundamentally misaligned abstraction of the underlying hardware - which is expected based on its age. When used with a compositor, it is basically a middle-man with no function whatsoever. So Wayland decided to cut out the middle man and pass events directly between client and compositor. But please watch the video, I think it will answer all your questions.
Also, it’s not like X will be totally deprecated, XWayland is an API implementation of it that will be supported forever.
Like, I'm fully supportive of having the X server simply manage DRI3 for a bunch of clients and composite the results. That's all well and good.
I'm less supportive of doing this while also removing all support for the other things that the X server provides the ecosystem:
* Unified input/event capturing and forwarding
* Unified screen capturing/recording
* Window management
* Clipboard
* Structured IPC (on top of which you get ICCCM and NetWM)
* Xrdb
* Xprops
* Notions of windows in general (everything's now client-side)
* Fonts
* Drawing APIs
These were all standardized things that users could count on always being available, regardless of which GUI programs they used. Wayland completely punts on these things and defers them to extensions.
Before you ask, I've already seen the "Wayland is a protocol; these are all extensions" song and dance routine. That's a cop-out. Dropping these things means that there will now be multiple incompatible implementations of the same concept, and no way to mix-and-match them because they now all have to be built into the same process that does your window management. Wayland implementations completely destroy this digital commons, for no apparent reason or gain for the users. The only people I see potentially benefiting from this are full-fledged DEs who can leverage their compositors' incompatible implementations to enact a form of lock-in (i.e. your GNOME programs are no longer guaranteed to run in KDE, and vice versa). So, why do this?
This is simply insecure. “It is easier to cut holes into a solid block than to patch something that looks like swiss cheese”. What reason does a random app has to see each keypress, when it doesn’t have focus? Do you trust eg. the teams app or the million other app to be a good citizen?
Screen capture is implemented with pipewire in a better way than before.
Fonts: noone uses the old font API of X, even under X. And third party libs like cairo work on both wayland and x, so nothing is lost here.
Drawing APIs: show me any app that uses it and was upgraded in the last two decades. Feel free to use a CPU only drawing API, I prefer not watching the line getting rendered.
Also, as I already mentioned XWayland is important for exactly this reason - it is a completely backward compatible X implementation, on top of a better display protocol. What’s the actual problem, because I still don’t see it.
There is no need to have incompatible implementations of each, and just look at the three main wayland implementations: they share many of the work.
Up-thread I was asking why X.org doesn't simply firewall apps off from one another, and ship with an extension to control this firewall. Adding this capability to X.org (or any X11 implementation) could be done without throwing X11 away. Having a unified way to decide which programs get to see which events would be lost in a transition to Wayland, since each compositor would ship with its own incompatible way of doing this.
> Screen capture is implemented with pipewire in a better way than before.
It also requires that the given Wayland compositor works with it. So, you're SOL if the window manager you're using happens to be welded to a Wayland compositor that doesn't. This wasn't the case before with X11, where screen capture was handled by the X server.
> Fonts: noone uses the old font API of X, even under X. And third party libs like cairo work on both wayland and x, so nothing is lost here. > Drawing APIs: show me any app that uses it and was upgraded in the last two decades. Feel free to use a CPU only drawing API, I prefer not watching the line getting rendered.
I wonder why the server still has them, then. Surely the X.org developers would have simply deleted old code without throwing the whole server away if they were as certain as you are that no one uses them?
Also, I see you haven't addressed the other points I raised (Xrdb, clipboard, ICCCM, NetWM, xprops, window management, etc.).
> Also, as I already mentioned XWayland is important for exactly this reason - it is a completely backward compatible X implementation, on top of a better display protocol. What’s the actual problem, because I still don’t see it.
It's not 100% compatible -- things still break. Distros are up-front about this (I have a sibling comment with sources).
> There is no need to have incompatible implementations of each, and just look at the three main wayland implementations: they share many of the work.
So now if I want to go and build a window manager, I have to go and re-implement a whole crap-ton of extensions myself that the X server used to do for me? And I have to do it perfectly, so apps written for other DEs won't just break? Sounds like a walled garden to me -- it raises the barrier to entry for new players.
Nothing is thrown away -> xserver is there for exactly this reason. Adding the extension for a system with bad abstraction is not too wise, but if you wanted to understand it, you would have done so already based on the video.
> Having a unified way to decide which programs get to see which events would be lost in a transition to Wayland
Why would it be lost? There is a core protocol that absolutely specifies it.
> This wasn't the case before with X11, where screen capture was handled by the X server.
And when you had only one player in the whole game.. which is pretty contradictory to your last sentence.
> I wonder why the server still has them, then.
Backward compatibility. Show me any desktop app that uses eg. xmotif or something. And with xwayland even these 30 years old apps can be run.
I didn’t address these things because basically everything has a solution under wayland nowadays. Please have a look at the wayland-protocol repo and see for yourself the state of it. Also, wayland is a display manager, just because the X server was a monolith, it had no place to eg. manage clipboard. Actually, Wayland is the one that fulfills the UNIX philosophy of do one thing (although I don’t find the UNIX philosophy a good thing in every case)
> It's not 100% compatible -- things still break. Distros are up-front about this
Such is life, I really can’t say anything else to this.
> So now if I want to go and build a window manager, I have to go and re-implement a whole crap-ton of extensions myself that the X server used to do for me?
No, you just use wlroots that implemented the “crap-ton” of extensions for you already, and be on your way.
I did watch the video, and while I was convinced that the X.org reference implementation was crusty, I was not convinced that there was anything inherently wrong with X11-the-protocol. Like, if there existed an X extension whose responsibility was just to get clients set up with their own video buffers that it could composite for them, then it sounds like it would address 90% of Wayland's value proposition. Is there a particular point in the video you want me to pay extra attention to that clarifies this?
> Why would it be lost? There is a core protocol that absolutely specifies it.
I read through the stable interface definitions in the wayland-protocols repo [1], and did not see anything related to controlling which programs get to see which events. Is this still in development (or unstable)? If so, is there an ETA at which point I can expect every correct Wayland compositor to faithfully implement it?
> And when you had only one player in the whole game.. which is pretty contradictory to your last sentence.
That's because the X server implements the mechanisms, not policies, for multiplexing the screen and input devices. In the service of this, it provides tools to enumerate, identify, query, modify, and extend properties of windows, as well as route messages between them. There was never a compelling need for multiple competing incompatible X servers because X is the narrow waist (i.e. an unopinionated digital commons) shared by software that competed on policy.
> I didn’t address these things because basically everything has a solution under wayland nowadays. Please have a look at the wayland-protocol repo and see for yourself the state of it. Also, wayland is a display manager, just because the X server was a monolith, it had no place to eg. manage clipboard. Actually, Wayland is the one that fulfills the UNIX philosophy of do one thing (although I don’t find the UNIX philosophy a good thing in every case)
I read through the unstable interface definitions, and see that Wayland is indeed trying to implement not only the same kinds IPC facilities and input device multiplexing that X provided, but also is trying to impose stronger opinions on what types of windows exist and how they behave (e.g. Wayland has a notion of pop-ups, text inputs, and so on). So if Wayland's goal is to avoid being as "monolithic" as X, it appears to be failing.
Also, putting core functionality that everyone must implement the same way into extensions just so they can call Wayland "just a protocol" or "just a display manager" is disingenuous. They might as well just say that they're part of the core protocol.
> No, you just use wlroots that implemented the “crap-ton” of extensions for you already, and be on your way.
Does the wlroots project define what extensions are standard and required for a piece of software to call itself a Wayland compositor? No? Then "just use wlroots" isn't addressing the problem of making sure these compositors are compliant to a set of common, useful standards. Like, maybe wlroots should be the standard-definer, just as X was? What happens with window managers built with a compositor that is not wlroots?
Anyway, I don't want to waste your time. If you can't help me understand why Wayland could not have been implemented as an X extension (including why isolating client input could not also have been implemented as an X extension), then I don't think we're going to get anywhere in this thread.
[1] I was looking here: https://github.com/wayland-project/wayland-protocols
If you are expecting every Wayland server to implement things exactly the same way, that will probably not happen, the point with having different implementations is that they can choose which parts they want. It's currently not looking like there will be any one standard-definer, you can build a monolithic implementation if you want but you don't have to. Yes this might cause some fragmentation but realistically, has X really helped there? The huge proliferation of clones and forks of various X window managers that are incompatible in various ways is another kind of fragmentation.
So why redesign the core protocol if the selling points of Wayland can be had without going through all that hassle? What are the true selling points of transitioning to Wayland, if they can be had for far less work?
> Yes this might cause some fragmentation but realistically, has X really helped there? The huge proliferation of clones and forks of various X window managers that are incompatible in various ways is another kind of fragmentation.
There was only ever one dominant X server implementation for the past 30 years (XFree86, then X.org), so yes, I'd say it helped a lot to keep the video/input multiplexing system out of the hands of window manager and desktop environment developers. This ensured that your graphical programs would always work, regardless of what desktop environment or window manager you used, because they all spoke the same protocol and relied on the same reference implementation. A proliferation of Wayland compositors would take all of that away.
The situation isn't that much better in X, the window manager and desktop environment can break clients in other subtle ways that have nothing to do with the X server. There's no guarantee that graphical programs would always work if your setup does something strange.
The mere existence of Wayland does not justify removing X11. I'm not trying to say that the X.org and fd.o developers shouldn't do as they please; I'm saying that I'll keep X11 until I see a compelling reason to drop it for Wayland.
> The situation isn't that much better in X, the window manager and desktop environment can break clients in other subtle ways that have nothing to do with the X server. There's no guarantee that graphical programs would always work if your setup does something strange.
I'll have to take your word for it, since I have literally never seen this happen (been using Linux as my daily driver since 2006 and have used dozens of WMs and all the major DEs). I agree that something inconsequential like the visual appearance of widgets or some such might not be consistent with the overall WM or DE theme, but X11 programs in general can run on a bare X server.
The only kind of non-trivial breakage I could imagine happening is accessibility features malfunctioning due to the absence of a particular DE, but I don't know to what extent this is the DE's fault, the program's fault, or the toolkit's fault.
> I was not convinced that there was anything inherently wrong with X11-the-protocol
There is, the non-existant security model that can’t really be backfitted without breaking every program - in which case they can just as well fix all the bad parts.
> Is there a particular point in the video you want me to pay extra attention to that clarifies this?
I found the graphics of the client-compositor-Xserver vs client-compisitor under Wayland really informative. In modern usage, the Xserver actually acts more like a library and IPC bus, and is bad at the latter. Also, related to the API thing, there is no way to signal that a buffer is ready. You may not be interested in the “every frame is perfect”, but I like that I can watch a video in vlc without tearing. Also, a wayland compositor can be much more lightweight than the whole xserver, because it is not as chatty (there is no useless communication to the xserver that communicates to the compositor for no reason) It’s not without reason that wayland is/can be used in embedded systems.
> and did not see anything related to controlling which programs get to see which events
There is a one-to-one communication with the compositor and the client. Keyboard events, window resize and the like are sent to only a specific client. I may have worded it incorrectly that it is specified — I would rather say it has an inherent model for it, that can be changed with extension protocols when needed. But the default should not have been the everyone listens to everything and find what is interesting. (For example it is now possible that a global hotkey have to be registered and the compisitor will react to that based on the registration. But there can’t be a clash now and it will work reliably) Also, in my opinion this flexibility (with which clients should not worry about) lets you create novel ways to interact with windows, that was not possible with X.
Also, you seem to think that there is all that much difference between compositor families —- it is not the case. The core and many extension libraries are while implemented multiple times, work in the same way. Thus a traditional client with some windows will just work. Some compositor have some custom extension for eg. having a specific status bar, which you may find bad since under X there could be cross-wm status bars etc. But realistically you could not have them eg. under gnome or kde without tinkering, so the status quo doesn’t really change.
> Also, putting core functionality that everyone must implement the same way into extensions just so they can call Wayland "just a protocol" or "just a display manager" is disingenuous
How would you create that API of X you mentionod? Wayland is a protocol, the core is mandatory. And it is in a repo, so that it can have versions — this is yet again an area where x is flawed. Even the core api can continue to evolve, and eg the compositor/client can both decide to support for example an older version — although in practise the core api is backward compatible. But a new feature for example can be used by a fresh client when available, with a proper way to fallback — due to the wl_registry.
> Does the wlroots project define what extensions are standard and required for a piece of software to call itself a Wayland compositor
That is the core protocol. You seem to have a misunderstanding around it. Otherwise, how would a wayland app work on every wayland compisitor? Wlroots can have some custom extensions and it does have , but you seem to misunderstand the point of those/scope of them. They are simple things like “a specific window that can work as a widget, eg don’t loose focus etc”. Everything buffer related is core, and for example full screen WAS not part of the core initially, but an implementation that all compositors agreed on was merged and everyone implemented it many years ago.
> If you can't help me understand why Wayland could not have been implemented as an X extension
I’m trying to but you seem to have some grudge against the project. I am no X developer so unfortunately I don’t have more knowledge on the topic than what I have already shared, but for example X developers tried to retrofit HiDPI to X, and things like mixed HiDPI over multiple monitors (hell, the whole multi-screen setup) simply can’t be done realistically — from what I gathered due to X API’s lack of semantic informations like scale. Wayland corrected the many many failings of the API in a future proof way that can avoid. Also, why do you think that basically every OS already changed to a compositor-based display server 2 decades ago? It is simply the better abstraction and this is a simple answer, but it is the fundamental one.
> There is, the non-existant security model that can’t really be backfitted without breaking every program - in which case they can just as well fix all the bad parts.
Most X11 clients only care about receiving input events for their own windows, no? Making it so the X server only sends input events to the window(s) that are in-focus and all belong to the same app by default wouldn't be nearly as disruptive as ripping out the entire X11 protocol, would it? If the mechanism that does this is well-designed, you could restore the "see all input events" feature on an app-by-app basis.
> I found the graphics of the client-compositor-Xserver vs client-compisitor under Wayland really informative. In modern usage, the Xserver actually acts more like a library and IPC bus, and is bad at the latter.
Is it, though? The X server is uniquely positioned in the graphics stack to (1) maintain a database of which windows (and associated metadata) exist and their parent/child relationships, (2) store global configuration state for applications with a graphical concern to query, and (3) route IPC data between processes on a window-by-window basis. This isn't something you can easily move into a separate process, since the state of all windows and input events mutates pretty quickly, and stale data is useless, or even dangerous for downstream apps to consume. I suppose the X server could delegate IPC responsibility to a trusted downstream process, but the X server would still need to be the authoritative source for all state-updates.
> Also, related to the API thing, there is no way to signal that a buffer is ready.
Can't there be an X extension that allows the X server to notify compatible clients when a buffer is ready? If we're not worried about old clients or infrequently-refreshed clients continuing to tear, then this would be no worse of a proposition than moving everything to Wayland.
> Also, a wayland compositor can be much more lightweight than the whole xserver, because it is not as chatty (there is no useless communication to the xserver that communicates to the compositor for no reason) It’s not without reason that wayland is/can be used in embedded systems.
Can't there be an X extension that allows clients to inform the X server that they don't care to receive certain kinds of messages (or, make it so I can configure the X server to not send messages to certain X clients, or maybe create a launch-wrapper for X clients that instructs the X server on this on their behalf)? Also, "embedded systems" these days are easily on-par with (of not vastly more powerful than) the computers for which X was designed.
> There is a one-to-one communication with the compositor and the client. Keyboard events, window resize and the like are sent to only a specific client. I may have worded it incorrectly that it is specified — I would rather say it has an inherent model for it, that can be changed with extension protocols when needed. But the default should not have been the everyone listens to everything and find what is interesting. (For example it is now possible that a global hotkey have to be registered and the compisitor will react to that based on the registration. But there can’t be a clash now and it will work reliably) Also, in my opinion this flexibility (with which clients should not worry about) lets you create novel ways to interact with windows, that was not possible with X.
I'm really not seeing how this precludes making it so X can just not send all X clients all messages. Clients that need to see events destined to other clients' windows (which is the uncommon case) would just need to get an exception granted from the X server.
> Also, you seem to think that there is all that much difference between compositor families —- it is not the case. The core and many extension libraries are while implemented multiple times, work in the same way.
Even if all compositors were 99.9% compatible, that's still a ton of breakage -- one in one thousand interactions will behave incorrectly. Like, just take a look at Web browsers today to see what I mean about having multiple implementations making our lives worse -- they all ostensibly support the same standards, and yet they all behave in subtly different ways that Web developers have to test for. Why should I believe that it will be any different for Wayland compositors?
> Thus a traditional client with some windows will just work. Some compositor have some custom extension for eg. having a specific status bar, which you may find bad since under X there could be cross-wm status bars etc. But realistically you could not have them eg. under gnome or kde without tinkering, so the status quo doesn’t really change.
I don't use GNOME or KDE -- I rely on the flexibility X11 affords me to run the X clients I deem necessary to do my work. I know for a fact that I'm not alone on this. If Wayland is going to take this away, then I'm going to put effort to keeping an X11 implementation alive (even if it's implemented as a Wayland extension) in order to keep using my computer in the way I see fit.
> How would you create that API of X you mentionod? Wayland is a protocol, the core is mandatory. And it is in a repo, so that it can have versions — this is yet again an area where x is flawed. Even the core api can continue to evolve, and eg the compositor/client can both decide to support for example an older version — although in practise the core api is backward compatible. But a new feature for example can be used by a fresh client when available, with a proper way to fallback — due to the wl_registry.
I don't even know how to parse what you're saying here. It sounds like you're saying that just because Wayland has protocol definitions that live in a github repository (as if that mattered), it's automagically better than X extensions? Because, if you swap "X" and "Wayland" in that above paragraph, the resulting paragraph would still be true. X11 is a protocol with a mandatory core; X protocols (and extensions) are most definitely versioned (we're using X version 11 revision 7.7 btw); X clients can decide which extensions (or versions of these extensions) they want to use. If the X server doesn't support what the X client wants, the X client can optionally fall back to an older, different extension.
> That is the core protocol. You seem to have a misunderstanding around it. Otherwise, how would a wayland app work on every wayland compisitor? Wlroots can have some custom extensions and it does have , but you seem to misunderstand the point of those/scope of them. They are simple things like “a specific window that can work as a widget, eg don’t loose focus etc”. Everything buffer related is core, and for example full screen WAS not part of the core initially, but an implementation that all compositors agreed on was merged and everyone implemented it many years ago.
Wlroots is most definitely NOT the core protocol. It's a Wayland project maintained by Drew DeVault for building Wayland compositors. But Drew DeVault does not dictate what is and is not part of Wayland. I was asking rhetorically to prove this point. Also, if every app needs to make sure it works with every compositor (instead of just needing to check against a recent X.org release), then Wayland represents a regression in the way we build desktop software. With Wayland, developers need to test their app against a bunch of different compositors to make sure they all behave the same way, just like how Web developers need to test their Web apps against a bunch of different browsers. I'd rather not repeat the Web's mistakes in desktop software development.
> I’m trying to but you seem to have some grudge against the project.
I have a grudge against breaking everything for no reason, and I try not to depend on software written by people who develop a reputation for doing this. This isn't specific to Wayland. But so far, it looks like Wayland is an instance of breaking everything for no reason.
> Wayland corrected the many many failings of the API in a future proof way that can avoid.
The same thing was said about X -- that's why X has a forward-compatible extension model that Wayland largely copies. So let's not delude ourselves into thinking that Wayland is going to somehow magically avoid becoming the new X.org when all is said and done.
> Also, why do you think that basically every OS already changed to a compositor-based display server 2 decades ago? It is simply the better abstraction and this is a simple answer, but it is the fundamental one.
Why should I care what other OS's that I don't use do? First, I care about programs that I depend on not breaking. Second, I care that I can retain the power to mix and match different graphical UI tools to my liking, instead of having to take into consideration which compositors they may or may not work on (something I didn't have to do with X.org). I'm not convinced at all that Wayland actually fixes anything that couldn't have been fixed in an X extension for far less work and disruption. It's not like X.org doesn't have DRI3 support, which provides exactly the compositor-based display server you clamor for.