[jchw]

The Wayland protocol "lacks" some things "by design" in that they are not specified. However, this is not intentional omissions, not even under the guise of "security", it's stuff that simply hasn't been done yet.

The most promising work towards improving accessibility support in Wayland was the work done on the Newton protocol:

https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the...

Unfortunately, the project appears to have stalled. I think the Linux desktop just lacks important strategic investments, and this is one of them. For now, existing accessibility bus support in UI toolkits is mostly being leveraged. Some compositors (i.e. KDE's kwin) also can support some old X11 features used for automation/accessibility (i.e. XTEST works, although applications will need to be granted permission first)

The situation is somewhat similar for IME: There are a few protocols for handling basic IME/text input, but it's not really finished, and further work on text input protocols has stalled.

This is not an ideal state of affairs at all, and it is a major threat to the future of the Linux desktop. I doubt many Wayland proponents (of which I do consider myself to be one) seriously believes that shipping Wayland-only without robust support for accessibility or internationalization is really a good idea. It's basically only happening because progress on Wayland has been rather slow, for many reasons, a lot of which really aren't in the control of open source contributors or maintainers. However, at the same time, maintaining both X.org and Wayland paths everywhere forever is also not sustainable: with limited resources, there simply has to be a point at which the line is drawn. X.org outside of XWayland has been unmaintained for a fairly long time.

On the flip side, if anyone working on Newton or Wayland accessibility has any idea what anyone on the outside can do to help things along, we'd love to know. I really hope that one of the major investors in the free software desktop (Valve? Red Hat?) can be convinced to help shift some resources to this. It's one thing to have some software work somewhat sub-optimally (as is the case with KiCAD), but it's a bigger issue that users who upgrade to newer free operating systems may face a system that is not usable for them because of limited accessibility tools. Possibly a compliance problem for companies that wish to ship systems based on free software desktops.

[yjftsjthsd-h]

> The Wayland protocol "lacks" some things "by design" in that they are not specified. However, this is not intentional omissions, not even under the guise of "security", it's stuff that simply hasn't been done yet.

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.

> However, at the same time, maintaining both X.org and Wayland paths everywhere forever is also not sustainable: with limited resources, there simply has to be a point at which the line is drawn. X.org outside of XWayland has been unmaintained for a fairly long time.

I'm actually cautiously optimistic that https://gitlab.freedesktop.org/wayback/wayback or the like will help significantly; sharing as much of the stack as possible should reduce the maintenance burden.

[seba_dos1]

Things don't get done in projects by themselves regardless of whether they're 1, 5 or 15 years old.

Major distros and DEs only recently started actually migrating to Wayland by default and only now you can see a decent variety of new nicknames in various development channels.

[jchw]

> 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.)

[BrenBarn]

> 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.

[jchw]

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

That's not worse, that's different. The positive side is that applications can't silently snoop around keylogging the system, transparently capturing things or using XTEST to bypass authorization.

Worse would be if you couldn't do it. On the contrary Wayland gives users more control over their machine than previously at least in principle (and application developers lose some control, which is obviously where a lot of frustration comes from.)

> 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.

X11 is mainly deprecated because nobody is really willing to work on it. The one person who wanted to work on X.org kept breaking shit. None of the desktops want to, or even can afford to, maintain X.org and Wayland paths forever. If people are upset they can get a full refund, at least.

[yjftsjthsd-h]

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.

[jchw]

The point with 1. isn't that it's interesting that such APIs could be made, it's that a whole bunch of non-sense discourse has flourished because people don't understand what it means that Wayland can't do screen capture.

That said, there is a standard way to capture the screen now, via XDG Desktop Portals + Pipewire. For better or worse, that is the standard that works whether you're on GNOME, KDE, COSMIC, Hyprland, etc.

Anyway, I really feel I said enough regarding the "17 years" thing. I think Wayland definitely was much closer to a hobby project for about half it's life, and while we have some big names investing in it, frankly I doubt the investment in Wayland desktops really compare to pretty much any other commercial windowing systems and probably still nowhere near the effort put into X11 over the years. But regardless, it's not really about that. The point is that the investments made by each party is not unilateral, they all had specific things they were working on. This is very different, IMO, than having a full time team. The closest you will see to that is Red Hat, but Red Hat also doesn't invest in all of the important areas for a full proper desktop.

[vrighter]

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

[jchw]

Wayland core can barely do anything. The vast majority of Wayland functionality is split between wayland-protocols and xdg-desktop-portal.

If you say "Wayland can't do interactive window resizing" because Wayland core doesn't have xdg-shell, well, it's maybe right by some twisted logic, but it's utterly useless and confusing to users who think that it means they can't when using Wayland which isn't true.