I like that this article isn't just a bunch of GNOME hate. But I freely admit to being frustrated that this switch is being forced when they're still developing basic accessibility functionality for GNOME. Once I switch to Wayland, I have to find new ways of:
- Adding hotkeys
- Replacing all my utilities that involve screenshot + OCR
- Making sure Orca works to some extent (low expectations here, but I need some of it to work)
- Reversing the gamma ramp
- Screen magnification
I have mapped out some approaches to most of these, but I full anticipate one or more to be show-stoppers or items I have to attempt to implement from scratch. I'm looking at 100 hours of work, minimum, to make this switch, and am basically just left out in the cold to figure all these workflows out under more hostile circumstances. It's also a chicken and egg, since I need to bootstrap into the new environment without any of my old tools working.
It's great that GNOME is taking some of this seriously, but they're forcing a very difficult transition, and it's frustrating that they think accessibility is in a usable state, or that we're low prioritiy enough to not matter. I'vbe heard the word "edge case" used a lot, it really stinks to be in a category where your entire computer use and professional career are considered an edge case.
yjftsjthsd-h · 5h ago
> Making sure Orca works to some extent (low expectations here, but I need some of it to work)
It sounds like this actually is supposed to work? At least on GNOME?
cardanome · 6h ago
I am still perfectly happy running X11. I am not going to switch any time soon.
Never change a running system.
The fact that only Gnome kind-off supports basic accessibility on wayland already shows what a giant failure wayland is.
justoreply · 3h ago
I like how Wayland provides some isolation between applications, so I switched
tetraodonpuffer · 5h ago
it only takes popular distributions making it default, then all sorts of things will start depending on it, and it will be difficult to not switch eventually. As somebody that has written a lot of xlib/xt/motif code years back, and that still has the full O'Reilly X series set on my bookshelves, I would prefer X11 to continue; but just like sysv->systemd it seems things are moving against that being the case.
vidarh · 4h ago
To me, the only thing that'd be troublesome to replace would be a browser, but worst case I'll run a Wayland compositor on my X11 server for that.
(And yes, I'd rather do that than go all in on Wayland)
yjftsjthsd-h · 3h ago
> but worst case I'll run a Wayland compositor on my X11 server for that
This is actually surprisingly easy, too. My first experiments ran a wayland app in cage ( https://github.com/cage-kiosk/cage ), but in order to better handle multiple windows I switched to sway with a lightly tweaked config, and other than some input weirdness (I think it struggles with modifiers held while switching focus) it works pretty well.
DonaldFisk · 6h ago
I understand that Wayland doesn't support Xlib function calls. What are the options for those of us who rely on C code which which uses Xlib for 2d graphics and event handling? If I have to switch to e.g. GTK, I'd not only have to rewrite all the Xlib calls, but all the code which depends on this, as Xlib and GTK do graphics ad events quite differently.
wizzwizz4 · 6h ago
XWayland is still supported, and afaik will be for some time. It's only standalone Xorg which isn't.
E.g. you now use the wayland calls instead of x11 calls
DonaldFisk · 5h ago
Specifically, I mean functions such as XCreateSimpleWindow, XDrawRectangle, XDrawArc, XmbDrawString, XNextEvent, etc.
wizzwizz4 · 6h ago
> GNOME’s Wayland session is now stable and usable with Orca.
They did that via an out-of-band D-Bus protocol, rather than going full Wayland. I'm all for keeping D-Bus around for backwards-compatibility (lots of things use AT-SPI2, and I certainly don't want a repeat of the CORBA -> D-Bus migration), but Wayland's AT support should be first-class, not relegated to proprietary GNOME extensions.
> Assistive technologies or other accessibility clients currently connect to the compositor through a D-Bus protocol, defined in the Mutter repository linked above. By exposing this interface via D-Bus rather than Wayland, we make it easy to withhold this communication channel from sandboxed applications, which shouldn’t have this level of access.
tuna74 · 1h ago
Maybe it is actually better to do these accessibility operations over D-bus than over a Wayland protocol. Just because something existed in Xorg does not make it the best solution.
jauntywundrkind · 4h ago
Excellent excellent call out. This feels very wrong direction, this using a side-band for accessibility!!! I had no idea.
It's surprising to me that security would prompt the push to D-Bus. Wayland's design with the compsitor as the message bus center was built to center security in the architecture, to make the compositor the arbiter of data flows. I'm struggling to picture what the issue was here with sandboxed applications.
holowoodman · 4h ago
Compositors are incompatible with one another and have totally different levels of functionality. Most compositors don't do any proper kind of security and permissions and just limit data flows in the most primitive and restrictive way possible. Using something with existing security but the possibility of cross-communication like DBUS is just easier here. Although I expect a lot of confused deputy type of exploits there...
jauntywundrkind · 2h ago
> Compositors are incompatible with one another and have totally different levels of functionality.
I see far more similar about compositors than different. They have freedom of implementation & do different things, but they offer to apps a very common set of protocols, and some of the newer edgier protocols have more varied adoption. But I see standards & growth & development forward as 'what Wayland is', not "incompatibility" (that's why Wayland proper is purely 100% protocols & not a bespoke impl) and "totally different" (???).
Finding formal concensus to make special stable has been hard. But there is a pleasantly large amount of overlap and interop, even if compositors end up implementing more than one flavor of say gamma control.
> Most compositors don't do any proper kind of security and permissions and just limit data flows in the most primitive and restrictive way possible.
When starting a composite yeah, you figure out who has input and send it there. You render the surface the apps give you. Dataflow is inherently quite unidirectional for a long time when beginning a desktop compositor.
But that doesn't feel true at all today. Most compositors support advanced screen sharing, virtual pointers, and other fairly advanced data-flow protocols, almost all built security in mind, requiring more advanced routing & permissioning, as is very visible with the screen share flows of most apps.
> Using something with existing security but the possibility of cross-communication like DBUS is just easier here.
Agreed, but you yourself in your very negative comment on Wayland in this topic seem quite opposed to second systems in broad basis (and pretty radically down on Wayland in general). I'd like to see the display system protocols able to better tackle talking about and managing what's on the screen, rather than building a second parallel system for saying and working with what's on the screen.
I also think there's a decently strong basis already there in the current protocols. There's a security context to start. https://wayland.app/protocols/security-context-v1 We see more advanced flows like XDG Foreign for apps to expose surfaces and mix them onto our own apps.
At-spi d-bus was already right there & done, and it felt easy to keep using it. It was mostly convenience I feel like, and the justification of security feels like a blunt hammer to deny exploration. https://gitlab.gnome.org/GNOME/at-spi2-core/
mkesper · 7h ago
TLDR (non-AI): The author raises very valid points about accessibility under Wayland. The "And Now We Don’t Have a Choice" subtitle seems to address that only Gnome seems to have usable accessibility under Wayland right now but can easily be misunderstood as "we have no alternative to Wayland".
The author also mentions X11 sucked in many ways and that this transition also is a moment to rethink what proper accessibility should fulfill.
holowoodman · 6h ago
Wayland is a perfect example of the second system effect and the sunk cost fallacy. X11 had problems, but instead of fixing them, developers threw the baby out with the bathwater, designed something completely byzantine and weird. Time was invested, so no stopping now or ever. The design of wayland introduces more problems than it solves, only by plastering over with yet another extra protocol that you have to implement in addition to wayland you might regain some lost functionality. Or paper over a design bug that will never be fixed.
Wayland is a dead horse. Made edible by sufficient fermentation and mobile towards the finish line by declaring the rot spreading over the line to be a victory. That Gnome just now gains parts of the functionality it had in X11, years later, while still being actually behind X11, while being an incompatible mess that leaves behind all other desktop environments to the detriment of the Linux ecosystem as a whole isn't actually a victory. Its the victory of the slightly-less-ruined after a devastating war.
ChocolateGod · 6h ago
> X11 had problems, but instead of fixing them
You can't fix a protocol that simply isn't designed for how modern graphics hardware works.
Both macOS and Windows have upgraded their display stacks over the decades, but it was seamless because unlike Linux, nearly all applications dynamically link the system library which they can upgrade. Linux is late to the party here because everyone wants to make their own toolkit.
X was designed for multiple remote terminals receiving drawing commands over a network, not locally hardware accelerated graphical interfaces and functions that rely on close coordination between the hardware and display server (e.g. hardware planes, vrr, hdr).
Fixing X would require a new protocol to the point that it isn't X anymore, aka Wayland. There are arguments that not having a reference display server has led to problems though.
vidarh · 1h ago
The protocol is trivially extensible, and have had plenty of extensions that has significant altered how it behaves. Fixing X in a step wise manner wod have been perfectly doable. The problem is that the Wayland proponents didn't just want to fix the things there was agreement was broken, but also wanted to actively break things that would cause an uproar.
holowoodman · 4h ago
Wayland also doesn't even remotely resemble anything that would be fit to talk to modern graphics hardware. DMA buffers and DRM (direct rendering manager, not the digital restrictions management) are an afterthought, a separate protocol that is not even all in stable yet. Vulkan usually doesn't work. Latency with Wayland got worse and won't get better because "frames have to be perfect". Tons of unnecessary blitting and latency be damned. All while actually tearing in Wayland is as bad as in X11 here.
Fixing X would require a protocol that is mostly X, but of course incompatible because you have to rip out some protocol bugs. But Wayland isn't X minus the bugs. Wayland started as a little bit of broken bitmap-pushing and a whole lot of hot air. And even with tons of extension and auxilliary protocol development, multiplied by tons of unnecessary reimplementations in tons of compositors, it isn't even where X11 was when Wayland started. Wayland fixed nothing yet, broke a lot, fragmented the community, brought pain and misery.
ChocolateGod · 4h ago
> Wayland also doesn't even remotely resemble anything that would be fit to talk to modern graphics hardware. DMA buffers and DRM (direct rendering manager, not the digital restrictions management) are an afterthought
You don't use Wayland to talk to graphics hardware, you use Wayland to communicate with the display server.
The Wayland protocol lets apps negotiate an area to write it output to and how it gets written there is completely up to the application, whether it involves the GPU or not, OpenGL, Vulkan etc.
This is in contrast to X where the app use X APIs to draw textures, which are then pulled by the compositor (copy, rip latency/performance), and then sent back to the X server to display.
holowoodman · 4h ago
That is complete BS. The application doesn't talk to the graphics hardware alone and then just copy a bitmap into a Wayland buffer. You don't just magically talk to the GPU. There is this little problem called 'security', 'multiprocessing' and 'multiuser' in between.
ChocolateGod · 3h ago
> That is complete BS. The application doesn't talk to the graphics hardware alone and then just copy a bitmap into a Wayland buffer. You don't just magically talk to the GPU. There is this little problem called 'security', 'multiprocessing' and 'multiuser' in between.
This is literally what DRM/DRI is for...
which is not Wayland.
If you think the display server should handle applications using the GPU, then even Xorg dropped this approach.
lotharcable · 4h ago
DRM is literally the 3D acceleration driver framework for Linux. It has been around for decades and is same set of drivers that are used for any sort of accelerated graphics in X.
If you want to get rid of DRM you have to start over and rewrite all graphical drivers for Linux from scratch.
DMA is part of the basic architecture of modern computers. It is how you can do things like have fast USB devices or network devices because it allows device hardware to by-pass the CPU and write things directly to memory.
holowoodman · 4h ago
> DRM is literally the 3D acceleration driver framework for Linux. It has been around for decades and is same set of drivers that are used for any sort of accelerated graphics in X.
Yes, exactly. And Wayland ignored it for years, from the start, and only later slowly adopted it as an extension.
> DMA is part of the basic architecture of modern computers.
Yes, I know.
DMA is even older and not limited to Linux or Graphics. Back in the old VESA, SGI and Windows 3.0 times, DMA was a cool new feature (but actually old even then). When Wayland was conceived, it was boring and old. Yet Wayland didn't originally include DMA buffers, just later added it as an extension when it became obvious that they had just gotten rid of a 40 year old feature that was really really necessary for modern graphics...
ChocolateGod · 3h ago
> Yes, exactly. And Wayland ignored it for years, from the start, and only later slowly adopted it as an extension.
DRM is not part of Wayland, and Wayland does not use DRM. Wayland is the protocol between the display server and application, DRM is a functionality provided by the kernel to allow user space applications to use and share graphics hardware.
The display server can use DRM, as will applications wanting to use OpenGL/Vulkan, but these are not "wayland".
vidarh · 6h ago
I'm sorely tempted to take the backend of a Wayland compositor and write a new X server on top of it, with a focus on deprecating everything not actually used by modern X apps that don't have alternatives, which would be a lot.
I bet you could benefit from quite a bit of the Wayland compositor work on modernising the lower levels, and end up with something much simpler than current Xorg without ditching much compatibility.
elsjaako · 5h ago
I think XWayland is basically an X server that supports Wayland. It is based on Xorg though. But if you really think it has a bunch of features nobody uses, you could try to delete those simplify that way.
Or am I misunderstanding what you want to do?
vidarh · 5h ago
I don't want an X server that supports Wayland. I want a leaner, simpler X server without Wayland.
EDIT: To clarify, the reason I mentioned Wayland compositors is that it'd be an opportunity to pick a low-level rendering backend that has been written from scratch without the baggage of Xorg.
The "good parts" of X that modern apps actually use are comparatively simple compared to the low level bits - the protocol is trivial-ish, and you can get 90% there by implementing a small-ish subset of the protocol.
lotharcable · 4h ago
XWayland can be run in 'rootless' and 'rootful' modes.
Rootless is what it is typically ran as and allows you to integrate X11 apps into your Wayland desktop environment.
Rootful would allow you to run X11 desktop with X11 Window manager and the whole ten yards.
I don't know how well rootful mode is working because it is rarely used. I imagine it would take some work to make it fully functional. But it something that exists and I would expect that the Xorg/Wayland devs would like to see it fully fleshed out.
But that essentially gets you most of the way there.
vidarh · 1h ago
But then I'd get the baggage of both a whole Wayland compositor and much of Xorg. I want neither.
tuna74 · 1h ago
If you want to fix X11, you can. You can do all the work that the Wayland devs did.
Joker_vD · 6h ago
> designed something completely byzantine and weird. Time was invested, so no stopping now or ever. [...] is a dead horse. Made edible by sufficient fermentation and mobile towards the finish line by declaring the rot spreading over the line to be a victory.
This applies perfectly well as a criticism of X11, you know.
holowoodman · 4h ago
Yes, but X11 has the excuse of being very old. Wayland was supposed to be a clean redesign, learning from the mistakes of the past. They learned from some mistakes, but they also completely ignored all of the good ideas, functionality and necessary additions that X11 and other systems like MacOS and Windows had.
They designed a system that was as simple as they could make it, trying to push the complexity that wasn't just bitmap-blitting onto others. And they isolated Wayland from all possibilities of making proper, compatible, common extensions. They tried to be the opposite of X11, because they recognized "push absolutely everything into the X11 server" as a mistake. Nobody ever used the XPrint extension. But they went too far, cut away all the useful stuff, all the necessary extensions, even cut away the "server" and just went with a library plus protocol. Now everyone has to reimplement their own server (compositor in wayland lingo), producing tons of busywork, splitting the community, ensuring incompatibility and pain. And everyone has to keep up to date on all the tons of necessary extra protocols that all the compositors have to implement all over again.
Yes, the same words do apply. But for different reasons.
Spivak · 6h ago
Do you mean dbus as the other protocol? Because that's an intentional choice to separate out the protocol for drawing windows and responding to events and "desktop stuff" that's not related to being a window on the screen. They're not plastering over anything, that stuff is intentionally out of scope for Wayland.
The advantage is that anything can use the desktop stuff (cli tools) just by talking to dbus instead of having to be a wayland client despite having no windows.
holowoodman · 4h ago
Tons of stuff aren't in wayland that are actually graphics and window related. Wayland just forgot about it, then later on people realized that their design was far too primitive and simplistic.
DMA buffers, color management and pixel formats, scaling and DPI, image and video capture, tons of keyboard and mouse related things, all initially forgotten, now incompatible extras that are inconsistently implemented, frequently broken and forever in beta/staging/unsupported hell...
Spivak · 4h ago
If you mean what Wayland literally calls "staging" it means that compositors should adopt it now, it doesn't mean pre-release. Once multiple compositors implement the protocol it can become stable.
holowoodman · 4h ago
Staging still means it is untested because not widely implemented. And still unsupported by the majority of compositors. So basically still unusable.
Also, "can become stable" is a very rare thing. Only a single-digit percentage of staging ever became stable.
mkesper · 6h ago
People downvoting my TLDR and all that nonsense about XLibre on top is making me sad.
Kim_Bruning · 7h ago
More and more people are using GPT for editing. I admit to sometimes using AI to help me too. To be fair, I'm not sure what to think of this particular slick style quite yet.
Fr3ck · 6h ago
What in particular drove you to leave this comment? I am just curious. This doesn't strike me as Gen AI slop like other posts I see sometimes.
Kim_Bruning · 3h ago
Ah, a lot of people do use LLMs for editing. And when I read this I can just hear GPT-4.x's style and tone of voice in my head.
None of the following are smoking guns, but together... well, either it's GPT or it's https://xkcd.com/810/ .
* Bullet point lists
* emdash
* extensive use of bold
* sentence fragments
* "Here's the good news:"
* juxtaposition over emdash: "This transition is happening — but we’re not being ignored anymore."
* Bullet points that simply MUST have a conclusion " The entire workflow? Gone." , " not just for me, but for every user who deserves to choose how they compute.", "And they shouldn’t have to." , "But we have to start over."
* "I hope it’s done right — not half-baked, not bolted on."
* "We lost an ecosystem."
* "That has to change. / And it starts with every compositor agreeing on what “accessible” actually means. "
etc....
Maybe it's
A) A human who is a very skilled writer with a particular style
B) GPT4.x
but my best guess is
C) Both: Human did the rough draft, then had GPT4 edit it into shape.
abhinavk · 6h ago
People see an em dash and dismiss it as slop.
Maybe they don't know but some of us love them and have keyboards which have an em-dash/en-dash key or use an OS where they are easy to type.
wizzwizz4 · 6h ago
It's got an —, and apparently these are called "ChatGPT hyphens" now – even though they're on my keyboard.
beej71 · 5h ago
Bad news for all my programming guides that use em dashes properly... ;D Luckily I have a Git history on them that predates LLMs, for whatever that's worth.
In Vim, the digraph is ^K-M.
ThrowOregonAway · 7h ago
XLibre talk is banned here, we DO have a choice.
Ezhik · 7h ago
What's XLibre? Are they taking Linux desktop accessibility more seriously?
resoluteteeth · 7h ago
It's a fork of x.org that's trying to keep actively developing it more than the x.org developers are interested in doing (because they are working on wayland and see x.org as basically obsolete). That in itself is a reasonable goal but given the person responsible for it I would not be too optimistic about it.
kstrauser · 6h ago
From their readme:
> Together we'll make X great again!
This explains the project in a nutshell.
lotharcable · 6h ago
XLibre is a fork of Xorg X11's codebase started by a developer who got kicked out of the Xorg project because he was making lots of changes that broke everything and had a hard time getting along with the other devs.
Another dev blindly applied his MRs assuming he had tested stuff before submitting the request and they had to go back and revert a bunch of stuff.
Broke nvidia compatibility, broke xrandr extension, and a bunch of other stuff.
LightHugger · 3h ago
This is false, he we the sole person submitting large amounts of code for about a year and was widely praised, until he forked and red hat went nuclear on his account for opposing their corporate goals, he was not kicked out for bad changes or anything of the sort. Trying to revise history on this is malicious.
The people like OA are spreading misinformation because the developer stated everyone was welcome to contribute and would oppose excessive politics. Keep in mind red hat is currently getting sued 3x over for blatantly racist policies which they used to ban other contributors and forced on their managers, they are evil people.
ThrowOregonAway · 6h ago
Googler, NSA'er, or Red Hatter?
bananapub · 6h ago
> What's XLibre?
a fork of X allegedly maintained by an arsehole
> Are they taking Linux desktop accessibility more seriously?
no
anonym29 · 7h ago
Can you elaborate more on discussions about XLibre being banned on here? Are accounts that mention it getting banned? Is there just mass downvoting by partisans with some kind of agenda?
I get that X11 has security issues, but NVIDIA drivers and Wayland still seem to have no support now and no support planned for the future, so Wayland is a non-negotiable non-option for many (most?) Linux desktop users, including myself.
That said, with the custodian of X11 refusing to merge 1000+ patches including various bug fixes and security fixes, I'm excited for the prospect of XLibre - this is exactly what Open Source, as an idea, was invented to facilitate - user choice.
ThrowOregonAway · 6h ago
Lots of Red Hat and Google and NSA types all here, all of which have their own clever sneaky reasons for hating x.org.
Wayland won't even RUN on old computers that lack the mandatory hardware backdoors.
wizzwizz4 · 3h ago
Wayland is a ridiculously simple protocol: I could run it on pencil and paper. It doesn't require anything I'd describe as a "hardware backdoor". What are you on about?
vbezhenar · 6h ago
HN cancel culture strikes at Xlibre.
mkesper · 7h ago
Wayland supports nvidia cards, that they are not supported is FUD at this point in time.
anonym29 · 6h ago
I have an RTX 4060 Ti with latest drivers installed, KDE on Debian. On the login screen, I can select X11 or Wayland. Selecting X11 lets me log in fine, selecting Wayland and logging in results in a black screen and the only thing I can do to get any video out at all is switching to another TTY.
colanderman · 6h ago
Same exact experience here. Nearly borked my entire installation trying to get that to work.
opticfluorine · 6h ago
I have an RTX 4060 with latest drivers, KDE, and Arch. Wayland works perfectly for me. Maybe Debian has some outdated packages that haven't caught up yet?
anonym29 · 4h ago
"Works on my machine, just use my OS" isn't a solution to my problem, whereas X11 is a solution to my problem.
Flockster · 6h ago
And I am running a 4060 Ti 16Gb perfectly on my Fedora setup with wayland and KDE.
colanderman · 6h ago
Really? As of a couple months ago I nearly totally hosed my Debian installation trying to get Wayland GDM working under Nvidia.
demosthanos · 6h ago
I've been totally breaking Linux installs trying to get Nvidia to work for 15 years now, and that's on X11. On the other hand I recently did the first OS upgrade that I've ever done successfully without breaking Nvidia and that was running Wayland.
Nvidia is just really really bad on Linux in general, so it's always a coin toss if you'll be able to boot your system after messing with their drivers, regardless of display server.
abhinavk · 6h ago
I haven't tried Debian but the latest releases of Ubuntu, Fedora as well as any rolling release distro work fine.
lotharcable · 6h ago
Nvidia under Linux has had a long and hard history.
For most purposes, including gaming, it is best to avoid Nvidia hardware. Using Intel for laptops and AMD for dedicated GPUs is kinda the best general approach if you are planning on using Linux.
Of course if you have a need for CUDA then Nvidia is the only game in town, but that is a different issue then Wayland support.
For a while Nvidia was fighting the Xorg/Wayland devs over GBM vs EGLStreams which has delayed Wayland support. This has to do with the API extensions that allowed Wayland to manage application output buffers.
Gnome was the only Wayland environment to try to support EGLStreams for Nvidia, but it really didn't do them any good.
A while ago Nvidia eventually switched over to GBM and EGLStreams is dead, which helped out a lot of people running non-Gnome Wayland desktops. But there are lots of problems with Nvidia drivers besides that right now.
The reality is that Nvidia doesn't care about consumer Linux desktop. Their primary focus is on Enterprise users in terms of people needing graphically accelerated desktops.
So right now if you are running Linux on your personal workstations/desktops/laptops you are essentially beta testers for whenever Enterprise Linux distros make the switch to Wayland.
justin66 · 6h ago
> The reality is that Nvidia doesn't care about consumer Linux desktop. Their primary focus is on Enterprise users in terms of people needing graphically accelerated desktops.
What does this actually mean in terms of technology? What is Nvidia providing that works for RHEL but doesn't work for Fedora, or whatever?
Spivak · 6h ago
I have an Nvidia card with the default Fedora install and it works on Wayland without having to do anything.
- Adding hotkeys
- Replacing all my utilities that involve screenshot + OCR
- Making sure Orca works to some extent (low expectations here, but I need some of it to work)
- Reversing the gamma ramp
- Screen magnification
I have mapped out some approaches to most of these, but I full anticipate one or more to be show-stoppers or items I have to attempt to implement from scratch. I'm looking at 100 hours of work, minimum, to make this switch, and am basically just left out in the cold to figure all these workflows out under more hostile circumstances. It's also a chicken and egg, since I need to bootstrap into the new environment without any of my old tools working.
It's great that GNOME is taking some of this seriously, but they're forcing a very difficult transition, and it's frustrating that they think accessibility is in a usable state, or that we're low prioritiy enough to not matter. I'vbe heard the word "edge case" used a lot, it really stinks to be in a category where your entire computer use and professional career are considered an edge case.
It sounds like this actually is supposed to work? At least on GNOME?
Never change a running system.
The fact that only Gnome kind-off supports basic accessibility on wayland already shows what a giant failure wayland is.
(And yes, I'd rather do that than go all in on Wayland)
This is actually surprisingly easy, too. My first experiments ran a wayland app in cage ( https://github.com/cage-kiosk/cage ), but in order to better handle multiple windows I switched to sway with a lightly tweaked config, and other than some input weirdness (I think it struggles with modifiers held while switching focus) it works pretty well.
E.g. you now use the wayland calls instead of x11 calls
They did that via an out-of-band D-Bus protocol, rather than going full Wayland. I'm all for keeping D-Bus around for backwards-compatibility (lots of things use AT-SPI2, and I certainly don't want a repeat of the CORBA -> D-Bus migration), but Wayland's AT support should be first-class, not relegated to proprietary GNOME extensions.
Per Matt Campbell's article https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the..., this decision has something to with security:
> Assistive technologies or other accessibility clients currently connect to the compositor through a D-Bus protocol, defined in the Mutter repository linked above. By exposing this interface via D-Bus rather than Wayland, we make it easy to withhold this communication channel from sandboxed applications, which shouldn’t have this level of access.
It's surprising to me that security would prompt the push to D-Bus. Wayland's design with the compsitor as the message bus center was built to center security in the architecture, to make the compositor the arbiter of data flows. I'm struggling to picture what the issue was here with sandboxed applications.
I see far more similar about compositors than different. They have freedom of implementation & do different things, but they offer to apps a very common set of protocols, and some of the newer edgier protocols have more varied adoption. But I see standards & growth & development forward as 'what Wayland is', not "incompatibility" (that's why Wayland proper is purely 100% protocols & not a bespoke impl) and "totally different" (???).
Finding formal concensus to make special stable has been hard. But there is a pleasantly large amount of overlap and interop, even if compositors end up implementing more than one flavor of say gamma control.
> Most compositors don't do any proper kind of security and permissions and just limit data flows in the most primitive and restrictive way possible.
When starting a composite yeah, you figure out who has input and send it there. You render the surface the apps give you. Dataflow is inherently quite unidirectional for a long time when beginning a desktop compositor.
But that doesn't feel true at all today. Most compositors support advanced screen sharing, virtual pointers, and other fairly advanced data-flow protocols, almost all built security in mind, requiring more advanced routing & permissioning, as is very visible with the screen share flows of most apps.
> Using something with existing security but the possibility of cross-communication like DBUS is just easier here.
Agreed, but you yourself in your very negative comment on Wayland in this topic seem quite opposed to second systems in broad basis (and pretty radically down on Wayland in general). I'd like to see the display system protocols able to better tackle talking about and managing what's on the screen, rather than building a second parallel system for saying and working with what's on the screen.
I also think there's a decently strong basis already there in the current protocols. There's a security context to start. https://wayland.app/protocols/security-context-v1 We see more advanced flows like XDG Foreign for apps to expose surfaces and mix them onto our own apps.
At-spi d-bus was already right there & done, and it felt easy to keep using it. It was mostly convenience I feel like, and the justification of security feels like a blunt hammer to deny exploration. https://gitlab.gnome.org/GNOME/at-spi2-core/
Wayland is a dead horse. Made edible by sufficient fermentation and mobile towards the finish line by declaring the rot spreading over the line to be a victory. That Gnome just now gains parts of the functionality it had in X11, years later, while still being actually behind X11, while being an incompatible mess that leaves behind all other desktop environments to the detriment of the Linux ecosystem as a whole isn't actually a victory. Its the victory of the slightly-less-ruined after a devastating war.
You can't fix a protocol that simply isn't designed for how modern graphics hardware works. Both macOS and Windows have upgraded their display stacks over the decades, but it was seamless because unlike Linux, nearly all applications dynamically link the system library which they can upgrade. Linux is late to the party here because everyone wants to make their own toolkit.
X was designed for multiple remote terminals receiving drawing commands over a network, not locally hardware accelerated graphical interfaces and functions that rely on close coordination between the hardware and display server (e.g. hardware planes, vrr, hdr).
Fixing X would require a new protocol to the point that it isn't X anymore, aka Wayland. There are arguments that not having a reference display server has led to problems though.
Fixing X would require a protocol that is mostly X, but of course incompatible because you have to rip out some protocol bugs. But Wayland isn't X minus the bugs. Wayland started as a little bit of broken bitmap-pushing and a whole lot of hot air. And even with tons of extension and auxilliary protocol development, multiplied by tons of unnecessary reimplementations in tons of compositors, it isn't even where X11 was when Wayland started. Wayland fixed nothing yet, broke a lot, fragmented the community, brought pain and misery.
You don't use Wayland to talk to graphics hardware, you use Wayland to communicate with the display server.
The Wayland protocol lets apps negotiate an area to write it output to and how it gets written there is completely up to the application, whether it involves the GPU or not, OpenGL, Vulkan etc.
This is in contrast to X where the app use X APIs to draw textures, which are then pulled by the compositor (copy, rip latency/performance), and then sent back to the X server to display.
This is literally what DRM/DRI is for... which is not Wayland.
If you think the display server should handle applications using the GPU, then even Xorg dropped this approach.
If you want to get rid of DRM you have to start over and rewrite all graphical drivers for Linux from scratch.
DMA is part of the basic architecture of modern computers. It is how you can do things like have fast USB devices or network devices because it allows device hardware to by-pass the CPU and write things directly to memory.
Yes, exactly. And Wayland ignored it for years, from the start, and only later slowly adopted it as an extension.
> DMA is part of the basic architecture of modern computers.
Yes, I know.
DMA is even older and not limited to Linux or Graphics. Back in the old VESA, SGI and Windows 3.0 times, DMA was a cool new feature (but actually old even then). When Wayland was conceived, it was boring and old. Yet Wayland didn't originally include DMA buffers, just later added it as an extension when it became obvious that they had just gotten rid of a 40 year old feature that was really really necessary for modern graphics...
DRM is not part of Wayland, and Wayland does not use DRM. Wayland is the protocol between the display server and application, DRM is a functionality provided by the kernel to allow user space applications to use and share graphics hardware.
The display server can use DRM, as will applications wanting to use OpenGL/Vulkan, but these are not "wayland".
I bet you could benefit from quite a bit of the Wayland compositor work on modernising the lower levels, and end up with something much simpler than current Xorg without ditching much compatibility.
Or am I misunderstanding what you want to do?
EDIT: To clarify, the reason I mentioned Wayland compositors is that it'd be an opportunity to pick a low-level rendering backend that has been written from scratch without the baggage of Xorg.
The "good parts" of X that modern apps actually use are comparatively simple compared to the low level bits - the protocol is trivial-ish, and you can get 90% there by implementing a small-ish subset of the protocol.
Rootless is what it is typically ran as and allows you to integrate X11 apps into your Wayland desktop environment.
Rootful would allow you to run X11 desktop with X11 Window manager and the whole ten yards.
I don't know how well rootful mode is working because it is rarely used. I imagine it would take some work to make it fully functional. But it something that exists and I would expect that the Xorg/Wayland devs would like to see it fully fleshed out.
But that essentially gets you most of the way there.
This applies perfectly well as a criticism of X11, you know.
They designed a system that was as simple as they could make it, trying to push the complexity that wasn't just bitmap-blitting onto others. And they isolated Wayland from all possibilities of making proper, compatible, common extensions. They tried to be the opposite of X11, because they recognized "push absolutely everything into the X11 server" as a mistake. Nobody ever used the XPrint extension. But they went too far, cut away all the useful stuff, all the necessary extensions, even cut away the "server" and just went with a library plus protocol. Now everyone has to reimplement their own server (compositor in wayland lingo), producing tons of busywork, splitting the community, ensuring incompatibility and pain. And everyone has to keep up to date on all the tons of necessary extra protocols that all the compositors have to implement all over again.
Yes, the same words do apply. But for different reasons.
The advantage is that anything can use the desktop stuff (cli tools) just by talking to dbus instead of having to be a wayland client despite having no windows.
DMA buffers, color management and pixel formats, scaling and DPI, image and video capture, tons of keyboard and mouse related things, all initially forgotten, now incompatible extras that are inconsistently implemented, frequently broken and forever in beta/staging/unsupported hell...
Also, "can become stable" is a very rare thing. Only a single-digit percentage of staging ever became stable.
None of the following are smoking guns, but together... well, either it's GPT or it's https://xkcd.com/810/ .
* Bullet point lists
* emdash
* extensive use of bold
* sentence fragments
* "Here's the good news:"
* juxtaposition over emdash: "This transition is happening — but we’re not being ignored anymore."
* Bullet points that simply MUST have a conclusion " The entire workflow? Gone." , " not just for me, but for every user who deserves to choose how they compute.", "And they shouldn’t have to." , "But we have to start over."
* "I hope it’s done right — not half-baked, not bolted on."
* "We lost an ecosystem."
* "That has to change. / And it starts with every compositor agreeing on what “accessible” actually means. "
etc....
Maybe it's
A) A human who is a very skilled writer with a particular style
B) GPT4.x
but my best guess is
C) Both: Human did the rough draft, then had GPT4 edit it into shape.
Maybe they don't know but some of us love them and have keyboards which have an em-dash/en-dash key or use an OS where they are easy to type.
In Vim, the digraph is ^K-M.
> Together we'll make X great again!
This explains the project in a nutshell.
Another dev blindly applied his MRs assuming he had tested stuff before submitting the request and they had to go back and revert a bunch of stuff.
Broke nvidia compatibility, broke xrandr extension, and a bunch of other stuff.
The people like OA are spreading misinformation because the developer stated everyone was welcome to contribute and would oppose excessive politics. Keep in mind red hat is currently getting sued 3x over for blatantly racist policies which they used to ban other contributors and forced on their managers, they are evil people.
a fork of X allegedly maintained by an arsehole
> Are they taking Linux desktop accessibility more seriously?
no
I get that X11 has security issues, but NVIDIA drivers and Wayland still seem to have no support now and no support planned for the future, so Wayland is a non-negotiable non-option for many (most?) Linux desktop users, including myself.
That said, with the custodian of X11 refusing to merge 1000+ patches including various bug fixes and security fixes, I'm excited for the prospect of XLibre - this is exactly what Open Source, as an idea, was invented to facilitate - user choice.
Wayland won't even RUN on old computers that lack the mandatory hardware backdoors.
Nvidia is just really really bad on Linux in general, so it's always a coin toss if you'll be able to boot your system after messing with their drivers, regardless of display server.
For most purposes, including gaming, it is best to avoid Nvidia hardware. Using Intel for laptops and AMD for dedicated GPUs is kinda the best general approach if you are planning on using Linux.
Of course if you have a need for CUDA then Nvidia is the only game in town, but that is a different issue then Wayland support.
For a while Nvidia was fighting the Xorg/Wayland devs over GBM vs EGLStreams which has delayed Wayland support. This has to do with the API extensions that allowed Wayland to manage application output buffers.
Gnome was the only Wayland environment to try to support EGLStreams for Nvidia, but it really didn't do them any good.
A while ago Nvidia eventually switched over to GBM and EGLStreams is dead, which helped out a lot of people running non-Gnome Wayland desktops. But there are lots of problems with Nvidia drivers besides that right now.
The reality is that Nvidia doesn't care about consumer Linux desktop. Their primary focus is on Enterprise users in terms of people needing graphically accelerated desktops.
So right now if you are running Linux on your personal workstations/desktops/laptops you are essentially beta testers for whenever Enterprise Linux distros make the switch to Wayland.
What does this actually mean in terms of technology? What is Nvidia providing that works for RHEL but doesn't work for Fedora, or whatever?