I am a part of the Talon community mentioned here, use Orca, have contributed to the Rust atspi bindings and feel like I know Linux accessibility quite well.
It is true to in Wayland you can write protocol extensions or custom compositors to get around these limitations. However, what many fail to realize is that the primary challenge in Linux accessibility is not just a technical problem as it is getting people to actually implement specs and care about it. Even with atspi itself, a standard that has existed for over a decade, major apps like Firefox often do not implement the atspi Collection interface. This is not a criticism but rather a practical statement that accessibility needs to be standardized and easy to implement for it to actually have any use. Orca works on Wayland but only in certain compositors. For assistive technology software developers, this pattern of supporting specific compositors is not feasible. It is important to understand that we need to support assistive tech generally. Not just ad hoc extensions for certain types of disabilities.
Wayland has no concept of global coordinates or global key bindings. The protocol itself is designed around atomicity which is a nice concept, but is fundamentally in conflict to the need of assistive technologies to control the entire state of the desktop globally. As such, atspi methods like get_accessible_at_point are impossible in Wayland.
I agree that X11 cannot be carried on forever, but with the current state of Wayland, the phasing out of X11 will have the effect of drastically harming the accessibility ecosystem. Accessibility is not a "nice to have", it is essential to the mission of community inclusion and wider goals of adopting desktop Linux in education and government.
Accessibility requirement is also something that EU is taking quite seriously lately, and if FOSS wants to be a part of something more than home enthusiasts, then it has to step up.
Wayland is great and ready for (idk) 95% of users/use-cases.
There is a long tail of more-or-less critical stuff that depend on X11 and do not have working Wayland substitutes. While the tail has been shrinking for every year, it will be decades if ever until all can be realistically migrated. Consider the Lindy Effect and that some of these systems have been running for >10y already. Consider shared but secured environments at universities and research institutes. Consider obscure hardware incompatibilities and hardware-specifix performance issues which might never be fixed.
On the software side, acessibility aside, there are a lot of VNC and other remote-X setups out there with no viable replacement in sight (yet).
Alsa, pulseaudio, pipewire and jack can all coexist and so can display servers.
I understand GNOME and RedHat will do things their way. I understand distro and GUI framework maintainers wanting to reduce their load. I understand people who like Wayland, want it to succeed, and want to evangelize. I do not appreciate when it turns into tribalism, forcing of monoculture and insisting "X11 is deprecated".
---
OP is from 2023 but as they note in their update, the situation is fundamentally not that different 2y later. Are maintainers and decision-makers really sincerely imagining that a supposed deprecation and removal of X11 can be forced onto the wider community over a couple of years from now?
> On the software side, acessibility aside, there are a lot of VNC and other remote-X setups out there with no viable replacement in sight (yet).
I've been using wayvnc for probably 5 years now? Works great. Sway can output fine to virtual-crtc out for headless mide; I expect other compositors can use this part of your GPU too. If you really desperate & your Wayland server just can't for no reason, get a DisplayPort dummy plug for $15.
I know less about others but krfb and gnome-remote-desktop are both there. KDE is recently kicking off a bunch of work to make sure their login manager is remote friendly too.
> I do not appreciate when it turns into tribalism, forcing of monoculture and insisting "X11 is deprecated".
Most of the devs doing X11 agreed en masse that it was at a dead end and not worth caring for anymore. It's not tribalism. It's technics.
Great you found something that works for you and that you managed to dodge the parts of the community that somehow managed to turn this into identity politics.
Still, the gaps are there and don't seem to be filled anytime soon, despite the progress you mention.
As an aside, you talk about wayland as if it were one thing. But the wayland protocol is intentionally minimal. Each wayland compositor picks and chooses between different third party libs to support various features. So you never know if something will actually work on the wayland compositor you use. If you stick within your ecosystem, yes, but it's not unified like X11 linux is. It's very fragmented and one's personal experience definitely doesn't say anything about other people's experience. Unlike with X11 where everyone uses the same thing.
For example, mouse and keyboard support and libei, libinput, or nothing (looking at you, weston). You never know what you're going to get and so applications that need to do basic keyboard/mouse things have to guess. It doesn't work all the time. In X11 it does.
Another example, accessibility features. The only wayland compositor that supports screen reading is GNOME's. They invented two new protocols, incompatible with all existing linux accessibility libraries. Only GNOME's wayland compositor and userspace applications use them.
So, in summary: one's experience can't be extrapolated with wayland because there is no single wayland.
It makes sense for something like accessibility to be part of the protocol because it almost always needs access to stuff that Wayland restricts by design.
I was speaking at a conference recently and was asked to chair the session at the last minute. It was hybrid, so all the speakers needed to share their slides on Zoom. I have been daily driving Linux for 14 years, and this has almost never been a problem (there was a moment with i3 but it seems better). But I hadn't bothered to test this since installing (and generally loving!) PopOS COSMIC.
The problem, at root, is Wayland. Zoom has some kind of workaround it seems, but it's not working yet in COSMIC.
The result was sad: speakers having to speak with their slides being run by one of the remote speakers, and anyone who recognized the computer running Zoom as Linux surely strengthened their conviction never to try that.
> anyone who recognized the computer running Zoom as Linux surely strengthened their conviction never to try that.
It always boggles me how supporters of Wayland (or other things that are new and better and worth deprecating the old one for) miss this. It only takes one experience like this to make the average person view Wayland (or Linux as a whole) as a total failure.
I don't want to post the typical "work on my machine" comment, but
I regularly see screen sharing failing on almost any platform.
In many in-person conferences in my field they started to request a copy of the pdf file before the talk, that will be projected and shared using a dedicated computer.
And, as explained, it doesn't matter. The problems, at root, are human psychology and incompatible but popular software, and that's sufficient to drive people away. And the issues are not new: we had exactly that with Windows Vista.
Wayland isn't a piece of software. It's a protocol. Compositors that implement it are Gnome's Mutter, KWin, wlroots, hyprland's compositor, and others. COSMIC implements their own compositor too and that's probably where the problem lies...
I use Gnome, and Wayland sessions have been flawless for years. Screen sharing works, everything works.
Also, I've seen colleagues struggle to get screen sharing working on both Windows and Mac; most OSes now don't just allow any program to read from any window, so if someone forgets to allow a permission somewhere, no screen sharing.
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:
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.
> 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.
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.
> 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.
> 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.
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.
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.
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.
It's been almost two decades and we're still taking steps backwards on accessibility and features because of Wayland.
From day 0 Wayland put their idea of a beautiful design above the needs of users. It's hard to see how we can claim to be inclusive when even our most basic decisions are hostile to large groups of users.
I never thought I would say this, but after 30 years of open source and Linux I don't see much of a bright future. Everyone I know from the community back then has moved on to using a Mac because of these issues.
But the Mac compositor (Quartz) implements the same permission model as Wayland, that's why you get a popup requesting permissions to share screen etc.
This particular case is about accessibility not permissions. AFAIK accessibility still isn't completely supported in major Wayland compositors so it's a legitimate complaint.
Wayland, traditionally, has not believed that. It believed "applications shouldn't be able to spy on or manipulate each other" and doesn't give users any mechanism to suggest that they might have permission to do so because the idea of that happening was just not on their radar.
I'm not sure about the modern state of Wayland but last time I saw it the situation was terribly messy and I was forced back to X11 because I rely on screensharing to do my job properly.
> I was forced back to X11 because I rely on screensharing to do my job properly.
Wayland screensharing has worked for a long time. I remember using it early in the pandemic when the entire working world seemed to move to Zoom/etc for meetings. So, at least ~5 years?
> Is there any reason that Xorg couldn't tack on a permission system, other than that it would be inelegant?
That's the whole reason for Wayland's existence: such things were not "easily" possible...
Linux+Xorg desktop would be hopelessly insecure for ever because these security features were deemed too hard to the point of not being "worth it". So Wayland was started.
Someone is developing XLibre, and Xorg fork. It may be pulled off, but I doubt it. Making Xorg safe was tried many times for many safety-holes.
"There should be global hooks and applications should be able to register themselves should they wish" would solve all these cases, but horse blinders are also very important to wear.
All of this was well known when Wayland was developed. They just didn't give a shit about end-users. They had one or two specific things they personally wanted done, and they made sure that was supported, and that's it. And then a few major players decide they're going to push for this new system to become the system, so it's not just "a bad alternative", it's an unavoidably bad fate.
This isn't the first case like this. The Linux desktop ecosystem has been getting worse for years, as a few major players force systemic changes that make the system more complex, more brittle, and less compatible [with anything that came before it, or that doesn't use the same core components]. I've been using a Linux desktop for 25 years and it's never been more complicated or broken.
It's part of a larger trend of tech enshittification, but seems especially sad in the Open Source world. I always figured a decentralized, leaderless ecosystem could fight incumbent stagnation and selfishness, through the creation of alternatives. But some things there's just no alternative to. And apparently the list of things without alternatives grows.
If a good bit of what you’re writing about wasn’t “fire and motion” on Red Hat’s part, the effect, at least, is the same: it’s harder to justify picking a distro other than one connected to Red Hat than it’s ever been before.
On the flip side, there's some software that works (somewhat) with wayland but deliberately breaks compatibility.
For instance, Scribus uses QT which supports wayland, but they hardcoded a check to explicitly detect wayland and exit if it's found. You get the generic QT "supported backends" message that lists wayland, but if you actually try to use it the logic resets your choice, gaslighting you into thinking you typed the backend detection or override env var isn't working.
You can get around it using a wayland-flavor that they forgot to reject, and there are bugs (not sure how many are from wayland itself and not Scribus though) so I get not wanting to handle wayland related bug reports, but having buggy software is often than having no software at all so I wish they didn't choose the nuclear option (and now they get "please support wayland" bug reports instead, so...).
I think Krita is the same? There were a couple programs I had to dig into the code to work around blocker mechanisms to get to run.
Scribus doesn't "deliberately" break compatibility; it was completely unusable with Wayland and they added friendly message. It also doesn't really go out of its way to do so as you're suggesting – it just checks Application::platformName() == "wayland" and that's it.
Maybe it's better now with Wayland and that check can be removed. I don't know.
By all means feel free, but know that you commit yourself to an endless task; every compositor has to have every feature implemented independently. The big two, GNOME and KDE, will need to be handled completely independently. After that, you can ease the process by getting support into wlroots, but that merely makes it easier per compositor; you'll still need to submit patches to every consumer of the library to actually wire up support. (For a worked example: wlroots has a way to set the keyboard layout. This does not mean that every compositor using wlroots has a way to set keyboard layout.)
You're essentially encouraging people to give up and leave it broken.
Sure, a lot of code changes need to happen, but they only need to happen once. There's no real reason to discourage people from stepping closer to the end goal.
Like... I don't exactly want to discourage people. As a person using a11y tools that don't yet exist on Wayland, I would kinda like to be able to migrate over. But it remains true that Wayland is set up in such a way that it's inherently a longer uphill struggle, and always will be. If tomorrow someone created a new X11 window manager, I could switch and my tools would still work. If tomorrow someone created a new Wayland compositor, I almost certainly couldn't use it, because they'd need to implement everything over again. They can do that, obviously, but the startup effort will always be higher.
The article we're talking under is titled "Wayland breaks the tools I use to make a living" and talks about how Wayland breaks a11y tools. The root comment says breaking backward compat is bad. What would they be possible be talking about except for Wayland breaking existing X11-based a11y tools?
I am a part of the Talon community mentioned here, use Orca, have contributed to the Rust atspi bindings and feel like I know Linux accessibility quite well.
It is true to in Wayland you can write protocol extensions or custom compositors to get around these limitations. However, what many fail to realize is that the primary challenge in Linux accessibility is not just a technical problem as it is getting people to actually implement specs and care about it. Even with atspi itself, a standard that has existed for over a decade, major apps like Firefox often do not implement the atspi Collection interface. This is not a criticism but rather a practical statement that accessibility needs to be standardized and easy to implement for it to actually have any use. Orca works on Wayland but only in certain compositors. For assistive technology software developers, this pattern of supporting specific compositors is not feasible. It is important to understand that we need to support assistive tech generally. Not just ad hoc extensions for certain types of disabilities.
Wayland has no concept of global coordinates or global key bindings. The protocol itself is designed around atomicity which is a nice concept, but is fundamentally in conflict to the need of assistive technologies to control the entire state of the desktop globally. As such, atspi methods like get_accessible_at_point are impossible in Wayland.
I agree that X11 cannot be carried on forever, but with the current state of Wayland, the phasing out of X11 will have the effect of drastically harming the accessibility ecosystem. Accessibility is not a "nice to have", it is essential to the mission of community inclusion and wider goals of adopting desktop Linux in education and government.
Accessibility requirement is also something that EU is taking quite seriously lately, and if FOSS wants to be a part of something more than home enthusiasts, then it has to step up.
Wayland is great and ready for (idk) 95% of users/use-cases.
There is a long tail of more-or-less critical stuff that depend on X11 and do not have working Wayland substitutes. While the tail has been shrinking for every year, it will be decades if ever until all can be realistically migrated. Consider the Lindy Effect and that some of these systems have been running for >10y already. Consider shared but secured environments at universities and research institutes. Consider obscure hardware incompatibilities and hardware-specifix performance issues which might never be fixed.
On the software side, acessibility aside, there are a lot of VNC and other remote-X setups out there with no viable replacement in sight (yet).
Alsa, pulseaudio, pipewire and jack can all coexist and so can display servers.
I understand GNOME and RedHat will do things their way. I understand distro and GUI framework maintainers wanting to reduce their load. I understand people who like Wayland, want it to succeed, and want to evangelize. I do not appreciate when it turns into tribalism, forcing of monoculture and insisting "X11 is deprecated".
---
OP is from 2023 but as they note in their update, the situation is fundamentally not that different 2y later. Are maintainers and decision-makers really sincerely imagining that a supposed deprecation and removal of X11 can be forced onto the wider community over a couple of years from now?
> On the software side, acessibility aside, there are a lot of VNC and other remote-X setups out there with no viable replacement in sight (yet).
I've been using wayvnc for probably 5 years now? Works great. Sway can output fine to virtual-crtc out for headless mide; I expect other compositors can use this part of your GPU too. If you really desperate & your Wayland server just can't for no reason, get a DisplayPort dummy plug for $15.
I know less about others but krfb and gnome-remote-desktop are both there. KDE is recently kicking off a bunch of work to make sure their login manager is remote friendly too.
> I do not appreciate when it turns into tribalism, forcing of monoculture and insisting "X11 is deprecated".
Most of the devs doing X11 agreed en masse that it was at a dead end and not worth caring for anymore. It's not tribalism. It's technics.
Great you found something that works for you and that you managed to dodge the parts of the community that somehow managed to turn this into identity politics.
Still, the gaps are there and don't seem to be filled anytime soon, despite the progress you mention.
As an aside, you talk about wayland as if it were one thing. But the wayland protocol is intentionally minimal. Each wayland compositor picks and chooses between different third party libs to support various features. So you never know if something will actually work on the wayland compositor you use. If you stick within your ecosystem, yes, but it's not unified like X11 linux is. It's very fragmented and one's personal experience definitely doesn't say anything about other people's experience. Unlike with X11 where everyone uses the same thing.
For example, mouse and keyboard support and libei, libinput, or nothing (looking at you, weston). You never know what you're going to get and so applications that need to do basic keyboard/mouse things have to guess. It doesn't work all the time. In X11 it does.
Another example, accessibility features. The only wayland compositor that supports screen reading is GNOME's. They invented two new protocols, incompatible with all existing linux accessibility libraries. Only GNOME's wayland compositor and userspace applications use them.
So, in summary: one's experience can't be extrapolated with wayland because there is no single wayland.
Still with this situation,it will be maybe 10 years before we get accessibility again
It makes sense for something like accessibility to be part of the protocol because it almost always needs access to stuff that Wayland restricts by design.
Let's do the math. If each Wayland implementation supports an independent 95% of what users need, then:
* With 0 implementations, Wayland is good for 100.0% of users
* With 1 implementations, Wayland is good for 95.0% of users
* With 2 implementations, Wayland is good for 90.2% of users
* With 3 implementations, Wayland is good for 85.7% of users
* With 4 implementations, Wayland is good for 81.5% of users
* With 5 implementations, Wayland is good for 77.4% of users
* With 6 implementations, Wayland is good for 73.5% of users
* With 7 implementations, Wayland is good for 69.8% of users
* With 8 implementations, Wayland is good for 66.3% of users
* With 9 implementations, Wayland is good for 63.0% of users
* With 10 implementations, Wayland is good for 59.9% of users
I was speaking at a conference recently and was asked to chair the session at the last minute. It was hybrid, so all the speakers needed to share their slides on Zoom. I have been daily driving Linux for 14 years, and this has almost never been a problem (there was a moment with i3 but it seems better). But I hadn't bothered to test this since installing (and generally loving!) PopOS COSMIC.
The problem, at root, is Wayland. Zoom has some kind of workaround it seems, but it's not working yet in COSMIC.
The result was sad: speakers having to speak with their slides being run by one of the remote speakers, and anyone who recognized the computer running Zoom as Linux surely strengthened their conviction never to try that.
> anyone who recognized the computer running Zoom as Linux surely strengthened their conviction never to try that.
It always boggles me how supporters of Wayland (or other things that are new and better and worth deprecating the old one for) miss this. It only takes one experience like this to make the average person view Wayland (or Linux as a whole) as a total failure.
I have such failures with Windows. Sometimes need reboot to fix it. It's kinda a running joke that most things in Windows are fixed by rebooting.
Cosmic is alpha software
I don't want to post the typical "work on my machine" comment, but I regularly see screen sharing failing on almost any platform.
In many in-person conferences in my field they started to request a copy of the pdf file before the talk, that will be projected and shared using a dedicated computer.
> The problem, at root, is Wayland.
Screen sharing worked fine for me on Wayland 3+ years ago (and still works today), so Wayland isn't inherently the issue.
And, as explained, it doesn't matter. The problems, at root, are human psychology and incompatible but popular software, and that's sufficient to drive people away. And the issues are not new: we had exactly that with Windows Vista.
And this is why I don't recommend any DE other than Gnome, and why Gnome is the only desktop supported by corporate distros (RHEL, Suse, Ubuntu).
It's pretty much guaranteed if someone is having issues, they're using a DE that's not Gnome.
Wayland isn't a piece of software. It's a protocol. Compositors that implement it are Gnome's Mutter, KWin, wlroots, hyprland's compositor, and others. COSMIC implements their own compositor too and that's probably where the problem lies...
I use Gnome, and Wayland sessions have been flawless for years. Screen sharing works, everything works.
Also, I've seen colleagues struggle to get screen sharing working on both Windows and Mac; most OSes now don't just allow any program to read from any window, so if someone forgets to allow a permission somewhere, no screen sharing.
https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_arti...
[flagged]
> I just bitch and moan now, because it’s better than killing myself to avoid seeing how fucked up things will become.
fwiw - I'm happy to chat if you wanna vent.
Care to explain what millennials have to do with any of that?
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.
> 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.
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.
> 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.
> 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.
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.
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.
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
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.
The way to combat these problems is to form some foundation, secure funding (public and private) and hire devs to work on it across ecosystem.
It's been almost two decades and we're still taking steps backwards on accessibility and features because of Wayland.
From day 0 Wayland put their idea of a beautiful design above the needs of users. It's hard to see how we can claim to be inclusive when even our most basic decisions are hostile to large groups of users.
I never thought I would say this, but after 30 years of open source and Linux I don't see much of a bright future. Everyone I know from the community back then has moved on to using a Mac because of these issues.
But the Mac compositor (Quartz) implements the same permission model as Wayland, that's why you get a popup requesting permissions to share screen etc.
This particular case is about accessibility not permissions. AFAIK accessibility still isn't completely supported in major Wayland compositors so it's a legitimate complaint.
Absurd ideas like "applications shouldn't be able to spy on or manipulate each other without explicit permission from the user".
Wayland, traditionally, has not believed that. It believed "applications shouldn't be able to spy on or manipulate each other" and doesn't give users any mechanism to suggest that they might have permission to do so because the idea of that happening was just not on their radar.
I'm not sure about the modern state of Wayland but last time I saw it the situation was terribly messy and I was forced back to X11 because I rely on screensharing to do my job properly.
> I was forced back to X11 because I rely on screensharing to do my job properly.
Wayland screensharing has worked for a long time. I remember using it early in the pandemic when the entire working world seemed to move to Zoom/etc for meetings. So, at least ~5 years?
I gave my explicit permission by choosing to run the software in the first place.
Nobody said anything about that. Is there any reason that Xorg couldn't tack on a permission system, other than that it would be inelegant?
There were X11 extensions that implemented access controls, eg in TrustedSolaris.
> Is there any reason that Xorg couldn't tack on a permission system, other than that it would be inelegant?
That's the whole reason for Wayland's existence: such things were not "easily" possible...
Linux+Xorg desktop would be hopelessly insecure for ever because these security features were deemed too hard to the point of not being "worth it". So Wayland was started.
Someone is developing XLibre, and Xorg fork. It may be pulled off, but I doubt it. Making Xorg safe was tried many times for many safety-holes.
"There should be global hooks and applications should be able to register themselves should they wish" would solve all these cases, but horse blinders are also very important to wear.
> Everyone I know from the community back then has moved on to using a Mac because of these issues.
It's your bubble.
At the same time, I know many who have been forced to use Macs (macOS is new windows), but keep using Linux outside of work.
All of this was well known when Wayland was developed. They just didn't give a shit about end-users. They had one or two specific things they personally wanted done, and they made sure that was supported, and that's it. And then a few major players decide they're going to push for this new system to become the system, so it's not just "a bad alternative", it's an unavoidably bad fate.
This isn't the first case like this. The Linux desktop ecosystem has been getting worse for years, as a few major players force systemic changes that make the system more complex, more brittle, and less compatible [with anything that came before it, or that doesn't use the same core components]. I've been using a Linux desktop for 25 years and it's never been more complicated or broken.
It's part of a larger trend of tech enshittification, but seems especially sad in the Open Source world. I always figured a decentralized, leaderless ecosystem could fight incumbent stagnation and selfishness, through the creation of alternatives. But some things there's just no alternative to. And apparently the list of things without alternatives grows.
Linux desktop has never worked for me better than today
If a good bit of what you’re writing about wasn’t “fire and motion” on Red Hat’s part, the effect, at least, is the same: it’s harder to justify picking a distro other than one connected to Red Hat than it’s ever been before.
On the flip side, there's some software that works (somewhat) with wayland but deliberately breaks compatibility.
For instance, Scribus uses QT which supports wayland, but they hardcoded a check to explicitly detect wayland and exit if it's found. You get the generic QT "supported backends" message that lists wayland, but if you actually try to use it the logic resets your choice, gaslighting you into thinking you typed the backend detection or override env var isn't working.
You can get around it using a wayland-flavor that they forgot to reject, and there are bugs (not sure how many are from wayland itself and not Scribus though) so I get not wanting to handle wayland related bug reports, but having buggy software is often than having no software at all so I wish they didn't choose the nuclear option (and now they get "please support wayland" bug reports instead, so...).
I think Krita is the same? There were a couple programs I had to dig into the code to work around blocker mechanisms to get to run.
Scribus doesn't "deliberately" break compatibility; it was completely unusable with Wayland and they added friendly message. It also doesn't really go out of its way to do so as you're suggesting – it just checks Application::platformName() == "wayland" and that's it.
Maybe it's better now with Wayland and that check can be removed. I don't know.
See: https://bugs.scribus.net/view.php?id=16998 and https://github.com/scribusproject/scribus/commit/74d8d7ef7
Krita should work now.
sounds like some peeps could contribute code to fix wayland / compositors to enable talon's accessibility hooks :D
By all means feel free, but know that you commit yourself to an endless task; every compositor has to have every feature implemented independently. The big two, GNOME and KDE, will need to be handled completely independently. After that, you can ease the process by getting support into wlroots, but that merely makes it easier per compositor; you'll still need to submit patches to every consumer of the library to actually wire up support. (For a worked example: wlroots has a way to set the keyboard layout. This does not mean that every compositor using wlroots has a way to set keyboard layout.)
You're essentially encouraging people to give up and leave it broken.
Sure, a lot of code changes need to happen, but they only need to happen once. There's no real reason to discourage people from stepping closer to the end goal.
Like... I don't exactly want to discourage people. As a person using a11y tools that don't yet exist on Wayland, I would kinda like to be able to migrate over. But it remains true that Wayland is set up in such a way that it's inherently a longer uphill struggle, and always will be. If tomorrow someone created a new X11 window manager, I could switch and my tools would still work. If tomorrow someone created a new Wayland compositor, I almost certainly couldn't use it, because they'd need to implement everything over again. They can do that, obviously, but the startup effort will always be higher.
They could also work on xorg, and make it better. That's what open source is about.
Wayland is a protocol for talking between the compositor and an application.
AT-SPI is a protocol for talking between the compositor and an accessibility reader.
It's not in Wayland's jurisdiction to define how AT-SPI should be used.
It's impressive how I've seen quite a few accessibility complaints about Linux, and not a single bit of praise when people fix something.
Again.
<expletive> ANY Linux project that strongly breaks backwards compatibility.
Not surprised that it's still messing with people even this late in the game.
I maintain a few Linux projects in my spare time.
I don’t really care about your opinion here.
xwayland still exists for backwards compatibility.
xwayland exists for application compatibility, but is essentially worthless for a11y tools
Accessibility wasn't strongly broken so I didn't think that commentor was talking about that.
The article we're talking under is titled "Wayland breaks the tools I use to make a living" and talks about how Wayland breaks a11y tools. The root comment says breaking backward compat is bad. What would they be possible be talking about except for Wayland breaking existing X11-based a11y tools?
Fuck any statements that are absolutist?
Personally I think a full forever commitment to the past is a form of folly which I can only laugh at the premise of.
No one is forcing anyone to use Wayland. There's DEs that use X11 and have no plans to move to Wayland.
Also no one is preventing this app from working, for whatever reasons the devs just haven't got it working.
Open source software is about freedom. Freedom to say fuck backwards compatibility or freedom to use X11 for the next 100 years.
Also the freedom for the X11 devs to say they don't want to maintain it anymore...
Intentional breaking of Xorg to frustrate use isn’t freedom. It’s harm.
Who broke it? It works. It's still there. Plenty of distros use it still...
The maintainers just got sick of maintaining it and moved on...