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
