> Two things: First, yes, a lot of Wayland's missing features absolutely were intentional omissions in the name of security. This is even almost understandable; the only difference between a vital a11y tool and horrible malware is whether the software acts on behalf of the user or against them, there is no technical distinction. Second... Wayland is almost 17 years old. If it was 2010, I would readily accept that it was early WIP software, but we're past the point where 'they just haven't gotten there yet' is convincing.

Firstly, the problem is when you put it this way, people think that Wayland can't do accessibility, or screen capture, or automation. It is true that it is intentional that a Wayland program can't simply expect there to just be the ability to go and read screen contents (or inject inputs, or intercept input, or ...) without permission, but that's not just security, I think that's also somewhat a result of the fact that the Wayland core protocol is really not applicable to any specific use cases, and is really just the bare bones necessary for programs to talk to a compositing system. For example, you can't really do proper desktop applications as we know them without something like xdg-shell, which isn't part of the core Wayland protocols, and yet it's totally possible to have Wayland protocols that do things like screen capture, and they can be as "standard" as the ecosystem wants. (Unfortunately that stuff usually gets relegated to DBus presumably because nobody actually wants to support authorization on the Wayland side, but oh well.) To put it more clearly, there is absolutely no reason that Wayland desktop systems can't just expose every bit of functionality X.org allowed to all apps if they want to, security be damned, and the protocols can be standardized; wlroots compositors usually do basically this after all, and I think these days the protocols are all ext protocols upstreamed to wayland-protocols. (And in practice, secure alternatives that allow for proper automation/accessiblity/etc. are very likely to exist and be supported by all major desktops in the long run.) I think people get the wrong idea that Wayland is telling them they can't ever do this, but it's really just telling application developers they can't absolutely count on being able to do it like they can in X.org.

Secondly, the "Wayland is x years old" thing just doesn't make sense, this has to stop. This isn't a project with full time employees like at your job, it's a distributed open source effort. The investments are incredibly uneven both over time and for specific areas of interest. Until about 10 years ago, Wayland was basically not usable at all for almost anybody, and until the last few years the vast majority of Linux users were using NVIDIA GPUs and couldn't really use Wayland without pretty terrible bugs (XWayland was especially broken. AFAIK to this day NVIDIA is working through XWayland issues that never existed on AMD/Intel.) The momentum Wayland had back when nobody could really use it was pretty damn bad. This isn't really terribly unusual for open source projects of this nature though; I mean look at how catastrophically long it took for GIMP 3.0 to come out, and that is a lot less complex and multifaceted than entire desktop systems.

I'm not saying that the initial work done on Wayland was bad or not important, but the majority of work done on making Wayland usable in real life happened in the past few years. 17 years ago or so, all that existed of Wayland in practice were some ideas about how to design a graphical interface system to succeed X.org. (and at that time, Wayland's design was probably too radical anyways: I don't think it's clear that all Linux users would've accepted things about Wayland that hardly anyone complains about today, like the pervasive use of compositing without a traditional fallback. Today X.org is basically the only commonly used windowing system that can properly operate without some form of compositing.)

> I think people get the wrong idea that Wayland is telling them they can't ever do this, but it's really just telling application developers they can't absolutely count on being able to do it like they can in X.org.

That's still worse than what X.org provides. "You can maybe do it" is worse than "You can definitely do it".

> Secondly, the "Wayland is x years old" thing just doesn't make sense, this has to stop. This isn't a project with full time employees like at your job, it's a distributed open source effort.

That's fine. What's not fine is then insisting that this new thing that has spent 17 years to get to a point of not being able to provide an equivalent experience to X11 should be the default and/or should replace X11.

No one should even think about deprecating X11 until functionality under Wayland is a strict superset of functionality under X11.

1 - Oh, yes of course Wayland could support all these things, but that's not terribly interesting. It's like a programming language with an inadequate standard library: It keeps the core language lean and flexible, while ensuring that the ecosystem will remain fragmented and anyone trying to do normal work will forever have an uphill slog to get anywhere. In practice, in 2025, there are 3 incompatible ways to take screenshots in Wayland (the GNOME way, the wlroots way, and the KDE way that supposedly will get combine with wlroots real soon now), and we're just now starting to get to the point where theoretically the APIs exist to do a11y but the practical side isn't there yet.

2 -

> This isn't a project with full time employees like at your job, it's a distributed open source effort.

It's not a hobby project, either. AFAICT, Wayland has always been predominately a corporate project. It's a loose proxy, but https://gitlab.freedesktop.org/wayland/wayland/-/graphs/main... matches my impression; started at Red Hat, with lots of help from Intel, Samsung, and Collabora.

but wayland actually can't do accessibility. If it needs custom protocols that are not part of wayland, then wayland itself isn't the one enabling it