Firefox 121 defaults to Wayland on Linux
omgubuntu.co.uk
omgubuntu.co.uk
I am sensing a large momentum for Wayland in the Linux community though. Finally there is maturity for Wayland in KDE, there is very strong commitment from various projects to default to Wayland (this being one of them). Traditionally more conservative projects like Cinnamon and Wine are finally adopting Wayland too. It seems critical mass has been achieved to get things really moving in the community, and it's about time.
I was under the impression WINE was less conservative and more that they really needed features that Wayland only recently added (relative positioning?)
Desktop is even more complicated. Think about the infinite fractal of Linux windowing systems and DEs and drivers and end-user configurations, and having to maintain consistent win32 windowing behavior across _all_ of them... you realize adding in Wayland support is a massive development effort and support and maintenance commitment, even if it did have all the needed features.
Then also consider that new technologies have many bugs and change frequently; many Wine users do not use the latest version of Wine; and how important being able to build & run older Wine versions is for regression testing... it adds up to adding new OS API support being a very expensive thing to do. So yeah, it makes sense to be conservative about it. The Linux community's love for throwing away stable libraries and replacing them with a fresh new thing is a serious hindrance to writing quality software on a long timescale. (Oh look, it's PipeWire coming down the road... oh joy...)
It will eventually be dropped like a hot potato, just like HAL.
At LEAST read the docs for your distro:
If Wayland only JustWorks on systemd-based systems that's not exactly making a great case for it, and this thread has plenty of other downstream stuff that it seems to upend as well.
There are many people in the Linux community that are just vehemently opposed to it.
I suspect that in many cases the “lack of resources” was simply not having the resources to convince some of these people to stop being roadblocks.
I'm less sure about XFCE or Enlightenment. Judging from [1] the XFCE people have been working on it since Feb 2021 (when that page was created), but real issues still remain, and I'm not surprised that "let's do a substantial rewrite of much of our codebase from something that works perfectly fine to ... something else that works perfectly fine" is not hugely top priority for a fairly small project like this. Call that "people being roadblocks" if you will, but that doesn't strike me as fair. Neither of us get to decide where these people spend their time.
It's very weird to say, but I feel like I'll eventually be dropping Linux and moving to Windows, and it won't be for videogames.
At a toolkit level, you don't really have to worry about that. When developing GTK or Qt apps, most of the DE integration and Wayland/x11-specific features are handled for you automatically. Basic trackpad gestures, copy/paste and windowing heuristics are handled by the toolkit, and so is accessibility software if your toolkit supports it.
If an app doesn't work well on a desktop's Wayland implimentation, it is less often a Wayland problem and more a desktop/toolkit problem. We had the same issue with non-conformist x11 software, unfortunately.
Just no ability to launch windows at absolute positions or do non-standard input stuff (like special mice, keyboards, or keyboard/mouse sharing) unless your particular wayland flavor has libei. And some waylands like sway are actively hostile to libei. Which is kind of microcosm of the waylands as whole.
Projects like GNOME would have dropped AppIndicator and server-side decorations whether it was included in Wayland or not. Drilling-down on a minimal set of secure features was the only path forward if Wayland wanted developers to take the protocol seriously.
I'm not trying to be rude just genuinely curious, and I also don't use a DE, wayland or accessibility, so I have no horse in the game.
I run the OS that runs the programs I want to use.
Why wouldn't someone ditch an OS for another to keep using the software they want?
Probably because it was a legitimate question out of curiosity with a couple sub-questions, and "why not" is a dismissal rather than an answer.
So when you write commands you bind them in different way: app specific[1], feature specific[2][3], OS-specific, hecking __programming language specific__[4] etc, and then talon mixes and matches all of that stuff together.
So let's say I have VSCode focused on a javascript file . Talon knows this, and so I have "panel switch" which is a vscode specific command, and "op strict equal" to insert ` === `, but I also have generic text editing commands (because it's an editor), and multi cursor commands (because vscode has been tagged as multi cursor supporting), and tab commands (because vscode is a tab-based editor), and so on and so on.
If I then switched to the browser I would keep the generic text editing commands, and the tab commands, as it supports both of those things, but I would no longer have multi cursor support (or JS commands), because my browser doesn't support that.
This also means you can by and large use the same talon config (and so the same voice commands) on windows, mac and x11.
So for me switching to windows is actually less of a pain because most of the ways I interact with my computer don't actually change, as talon abstracts that away quite a bit.
[1] https://github.com/talonhub/community/blob/main/apps/vscode/... / https://github.com/talonhub/community/blob/main/apps/vscode/...
[2] https://github.com/talonhub/community/blob/main/core/windows...
[3] where vscode gets its features "bound" https://github.com/talonhub/community/blob/main/apps/vscode/...
[4] https://github.com/talonhub/community/blob/main/lang/javascr...
I have solved this by replacing my keyboard with voice commands almost entirely (I don't actually have a keyboard on my desk, but I can reach for my laptop keyboard if I really really have to), and am slowly working on replacing a trackball with an eye tracker (it's kind of headache-inducing though, so it's likely the trackball will stay for a while)
I'm not a medical professional but that sounds like a disability to me.
The odds are pretty good that computer-related RSI is similar to other computer-related RSI. I see no particular need to specify that I'm not talking about tennis elbow when that is already abundantly evident from the context. Most of my comments could include an accurate disclaimer that I'm not talking about tennis elbow, but it wouldn't improve any of them.
Real diseases often have a progression of permanent damage over time and real treatments have positive and negative interactions with other aspects of patient health, cost, and a wide range of outcomes. Commercials especially push a simplistic view that a person has a problem and undergoes a treatment and their problem is resolved. This is as real as crimes being solved in scope of an hour drama or as real if you prefer as people hacking by pounding on the keyboard really fast.
Most users in Developed countries have access to both doctors and the internet and have whatever level of problems they have in spite of pursuing treatment options and probably wont benefit from "one weird trick" to beat RSI.
When I hear accessibility I tend to think of screen readers - magnification or text to speech - for people with low vision.
Only on the internet would someone discuss a change they've made due to a disability, only to have someone else say challenge them on it and imply that they're bullshitting.
Accessibility is customization, and customization is accessibility. They are one and the same.
User control over interfaces is an accessibility feature. At the heart of accessible control schemes is the notion that if a user isn't able to use a traditional control-scheme they should be able to build or hook into something else or customize something that works for them.
This is a big problem with how the Linux community thinks about accessibility. Accessibility is not a separate concern from user agency and control. Accessibility IS user agency and control over a user's interface. It is the ability to take an interface you can't use or that is frustrating or painful to use and to adapt it to your needs.
Accessibility is fully aligned with Linux/GNU philosophy, but we treat it like a separate issue and like it's a chore to support, rather than being a central pillar of how we ought to be approaching software development in general.
----
Here, GP has RSI which means their customization is linked to a traditional physical disability. But to be clear, even if that wasn't the case and even if this just made their life easier and they didn't have a clear, socially accepted disability classification to point to -- customization is still accessibility. Gatekeeping accessibility or asking people to prove that they're fully "disabled" isn't really helpful, we should still be prioritizing making it possible to build things like this. And we should still be treating it like an accessibility concern regardless of whether there's an easily defined disability to point to.
For example[1] it doesn't know if you're using VSCode that you have focused the inbuilt terminal, and so it should now accept terminal commands (eg "cd <whatever>") until you focus back. It knows about the language that you are using because you have configured your text editor to have the file name in the window name, which it can reliably read. This is also how you have website specific configuration.
[1] last I checked! I think there was some work to try to solve this problem, I'm not sure where they got to though, I kind of went down my own configuration fork for a while
I can’t speak much to windows accessibility, although Mouse Keys got me through several rough times in my life where I fried or broke my mouse in some way or another. I do think windows has improved with time, at least by accidentally triggering the screen reading in W10 more times than I’d care to admit
I'm not a big Wayland fan (quite the opposite truly), but I don't know if this is true: if there's an accessibility protocol made for Wayland you could (in theory) have one accessibility SW accessing many Wayland DE.
So this isn't a Wayland design issue, but it is an implementation issue: given that many DE have reimplemented the Wayland server, there will be less shared code than with X and more bugs to take into account.
Of course given the age of Wayland and that this is still an issue really show the problems with Wayland..
This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.
Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. I think most casual users haven't realized this. KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
That makes targeting it, whatever "it" actually is, with tools for accessibility all that much harder. That's on top of the Wayland protocol's hostility to things that would make that job easier. We've "secured" the system against use by anyone who doesn't have working eyes or hands. There's no malice there, just the unintended consequence of a system designed by able-bodied people. I'm not even sure X is better in this regard, except that there are solutions like Talon that work there.
There are shared libraries like wlroots that can help with consistency, but it doesn't implement everything and not every compositor is using it. Something like accessibility shouldn't be an extension protocol but a core part of the design.
It is never too late to start improving things.
On the other hand, this means that the ecosystem overall stays fragmented and we get an eternal state of "to do X in Windows do foo, in MacOS do bar, and on desktop Linux see this wiki page discussing your options". And while I suppose there would be value in ex. screenshot tools only needing 3 code paths, it would have been nice to only need 1.
This is something I've been wondering for a long time - how long will it take before someone writes a Wayland-based server that provides an interface for window managers, system trays, and whatever other clients running in other processes, mimicking what X does?
I considered wlroots but the complexity is far higher and Im not in a rush to move to Wayland.
Furthermore it was of vital import for KDE and Gnome to support both X11 and Wayland for years and leverage their large existing codebase. Wlroots would both have to travel back in time like the terminator from 2018/2020 to 2010 and become universally suitable en route.
This is fine. Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver. You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects. Focus on what users actually need from the applications (like: working screen capture).
X11 - the platform with more window managers and terminal emulators than actual apps. Wayland needn't repeat the same mistakes, but here we are on that trajectory.
> KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
Close enough. We have kwin, Mutter, and wlroots (the last one effectively doing what Weston should have done from the start) - three disjoint codebases.
Gnome telling SDL2 to link to libadwaita to draw clientside window borders is just cherry on top.
> Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
Every other graphical system did so by tying the protocol to an entire specific software stack; Windows/Android/MacOS/Haiku all require you to use their single official compositor and window manager. I get that you're arguing that's a good thing, but I pretty strongly disagree.
> IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver.
Hard agree, 100% yes; even if they'd just focused on shipping a single working example desktop environment, at least it would have forced them to figure out all the protocols that need to exist.
> You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects.
I'm less convinced of that; people aren't asking for shallow customization at all, and I am skeptical of the idea that any one window manager could accommodate the needs of GNOME, compiz (yay cubes), and dwm. You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
But overall, I tend to agree; personally I would have liked wlroots to effectively become the unifying point and have been part of the initial release, along with actually shipping most of the needed protocols up front rather than effectively leaving everything except drawing windows as a TODO.
I am a former dwm user (contributed patches too), and I'd say we represent a group of marginal importance. Suckless is as much a philosophy as it is a lifestyle choice. It proves that simplistic software can be practical, but skims over many in-depth issues, such as accessibility.
Once we get the elitists out of the way, the needs of the 99.99% are not that hard to meet: Windows & macOS combined market share more than proves it; tools like Hammerspoon or AutoHotkey fill the gaps for most power users.
> You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
Hammerspoon uses Lua; macOS doesn't even ship a Lua interpreter or ObjC bindings.
Also, the majority of the population is not technically competent enough to even care about decisions such as JavaScript vs Guile vs Bash; power users in practice turn out patient enough to put up with garbage like AppleScript, because it gets work done.
The continued prevalence of memory unsafe languages is unfortunate, but a well-written and well-maintained C project used by a million people is going to provide more value than an absolute marvel of engineering, written in Rust, used by a hundred.
Take this redit post from someone with a bum shoulder, for example:
https://www.reddit.com/r/linux/comments/17oo98g/wayland_simp...
It's the second hit for "Wayland Accessiblity Protocol", so (I'm guessing) if there is such a protocol, it's extremely obscure and unsupported.
The first hit links to these two pages, which are separate lists of wayland accessibility regressions for KDE and GTK:
https://www.freedesktop.org/wiki/Accessibility/Wayland/
https://www.freedesktop.org/wiki/Accessibility/GTK-a11y-reva...
Of course, even if they address all the things on both lists (which is at least twice as much work as doing it under X11 was) none of that will help the person with a bad shoulder, since they need to mix and match between multiple environments to use their machine.
Another way to put it is Wayland with a few years of development by a few Linux players (others were building alternatives, while yet others were seeing which one would win out, and yet others were hoping to stay on X11 forever) under its belt, is almost as solid as X11 with many decades of development by all the Linux players.
The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong. X11 has been built and expanded for decades and even today is incapable of doing many modern functions that its competitors can.
Wayland, OTOH, has almost reached parity with X11 rapidly, does things that X11 is not even capable of, and has a roadmap to reach complete parity.
> The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong.
It's also not something anyone is arguing, and something that's not really meaningful because we have Xorg already. At best, you're arguing that Wayland actually has a chance to catch up even though it hasn't in the first 15 years.
> Wayland, OTOH, has almost reached parity with X11 rapidly,
Debatable but possible,
> does things that X11 is not even capable of,
Capable of without more extensions, but who's counting?
> and has a roadmap to reach complete parity.
Yeah, no. Wayland has roadmaps to someday hope to implement a lot of features, but explicitly is designed to not cover others and AFAIK has nobody working on others. There is not, and probably never will be, a wayland protocol to separate the window manager from the display server. There could be but AFAIK isn't any effort to let programs manipulate windows in a portable way (read: there will never be accessibility tools that work on all, or even most, compositors). Wayland is aiming for ~90% feature parity with X, and may someday reach it.
---
[0] I can think of some metrics you could use, but they're all hopelessly entangled in confounding variables. For example, we could graph number of X11 window managers released per year against Wayland compositors released per year, but even if you could pin down good numbers they're happening in completely different ecosystems and contexts. Likewise, we could make up a list of features and when they were added, but it seems a bit unreasonable to ex. hold it against X11 that nobody cared about HiDPI for the first ~30 years it existed.
If Wayland is going to be caught up and have feature parity so soon, then why can't decisions to deprecate and remove X11 be 100% put on hold until then?
> The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong.
Nobody thinks that. But at the time X11 was missing all of those important features, there wasn't another full-featured option that everyone was rushing to deprecate and remove support for to force everyone onto the immature and incomplete X11, at the expense of things that already worked.
Of course, there’s no reason that this has to be a separate process, it could just have been a library that everybody links to. wlroots looked like it could have been a nice library that provided a lot of that shared functionality, but then Gnome and KDE didn’t use it, so the predictions of fracturing seem to have come true.
For what it's worth though, accessibility was mentioned as one of the improvement area for which Gnome got funding: https://www.phoronix.com/news/GNOME-This-Week-Homed
Not sure what it will mean in practice, accessibility being a large topic.
The sad thing to me is that Wayland is aiming at replacing X while at the same time proudly stating that they aren't going to support a fair bit of the functionality that X provides.
That makes the whole effort an exercise in regression to me.
But Windows 11 really achieves greatness in a lot of ways, which offsets it.
There are some minor issues with Wayland but most of it works.
I don't know what talon is doing as it seems proprietary, but the issue might be there.
Here is a bit of a discussion though on this topic:
- a summary of the situation: https://github.com/splondike/wayland-accessibility-notes/blo...
- talon-required features and their current compatibility: https://github.com/splondike/wayland-accessibility-notes/blo...
Basically people complaining about needing to do work to modernize.
All the things will eventually be just fine. X11 is a walking zombie.
Yes, users are very understandably miffed that things which were working are suddenly broken and somebody now has to fix it in order to return to the status quo.
> things will eventually be just fine
Wayland is 15 years old. At this rate it will be due for replacement before it's feature complete.
You are misunderstanding. You can continue to keep using applications in X11-mode for as long as those applications maintain that code path. But many of the niceties Wayland provides, X11 won't get because it is virtually unmaintained.
Or said another way, X11 is already broken and getting slightly more broken every day.
And before you get angry at X11 going unmaintained, would you have expected Apple to support Carbon ad-infinitum?
Look at the backwards-compatibility and new-framework-adoption-rate woes Windows has to deal with because Win32 exists and devs are lazy / expensive.
X11 is a complete dead end. All applications need to eventually update. Put pressure on app developers to get to it...
btw, I already said something wrong, because, which wayland? It's not a thing.
Like, you can complain about missing deep accessibility support in something like Bpswm or Ratpoison, but is that really fair?
I'm guessing accessibility support is/will be pretty good on both Mutter (Gnome) and Kwin (KDE). Wlroots-based probably will be too with the community attention it is getting. Stray beyond that and you'll be on your own.
If X11 was going to be some permanent fixture at least people who rely on it for apps that are abandoned or proprietary or can't/won't be updated would have an alternative they could keep using. But while X11 isn't going away any time soon, it's also very clearly not what we want to be building on or encouraging people to use. When I criticize the state of Wayland, I'm not saying X11 is great. I don't want to be on X11, I want to use Wayland. I want the features that Wayland has.
Where accessibility is concerned, we're at risk of losing a bunch of users if they lose the ability to use applications they rely on during the transition or if there aren't alternatives to help control the applications that don't get updated. This is not something where we can just say, "oh the developers are lazy."
If the stuff doesn't get supported, regardless of whether it's the developers' fault or Wayland's fault, the users can't just deal with it until the ecosystem catches up. Instead, they go to Windows (or more realistically to Mac, my understanding is that Apple is kind of the gold standard if you need accessibility controls).
----
Also add to this that "developers need to modernize" minimizes just how unapproachable a lot of this stuff actually is. I don't have a good grasp of how accessibility works in X11 because the development philosophy there has been for years "let the toolkit handle it" or "don't worry about it, controllers will just do something weird to handle window placement or font sizes on their own."
What are the standards for handling those problems in the future? There probably are standards, and they're probably better than what X11 was doing, but I don't feel confident that I know what they are. And there are X11 apps that are written by developers who aren't professionals and that have even less knowledge than I do about how the Linux desktop actually works. I would challenge anyone to find a good tutorial online written at a level that novice developers can understand that walks through how to make sure that a Wayland app is accessible, what changes need to be made from X11, and what the common problems or pitfalls are that developers might face.
Again, wouldn't necessarily be the biggest problem in the world -- except for the fact that X11 is a dead end and Wayland is the future. And because it's the future, we really, really need to make this stuff work.
The wayland/x11 compatibility shims work and will continue to do so for a long time, for the reasons you are mentioning. Basically both will work on a Wayland system for the foreseeable future - the big change was making Wayland the default which puts the focus there instead of allowing people to mentally push that work off into the future.
Wayland is prime-time, it's shipping as the default for all the big distros. It's here - time to get with it and update your codebase. Like has already been pointed out, Wayland isn't new, and this day has been coming for years. Now app developers will be compelled to finally put in the work.
It's not fair to complain about Wayland when it's some app developers that are not modernizing.
How do they modernize?
Like you point out, Wayland isn't new. So, I would repeat:
> I would challenge anyone to find a good tutorial online written at a level that novice developers can understand that walks through how to make sure that a Wayland app is accessible, what changes need to be made from X11, and what the common problems or pitfalls are that developers might face.
"Need to modernize" is worthless advice without follow-up advice about what needs to be done to modernize. How many developers building apps for Linux even know what the at-spi protocol is?
----
But more to the point:
> It's not fair
I'm not blaming Wayland devs. I like a lot of Wayland's approach to controls and structure, I agree with a lot of the development philosophy. This isn't about what's fair, I'm telling you that because Wayland is the future and because X11 is a dead end, if users with accessibility concerns can't use Wayland and they can't stick with X11 (which will become increasingly difficult for them to do as X11 decays more and more), they will leave the Linux ecosystem entirely because they will not be physically able to use it. It does not matter who's fault that is.
Is it fair? Who cares, it's going to happen regardless if the accessibility situation doesn't improve.
This is just kicking the can back and forth, blaming application developers changes nothing about the situation that people are in. If application developers need to modernize, then the question becomes "how do we make that easier for them to do and how do we encourage more of them to do it?" Because clearly the current approach of calling them lazy doesn't seem to be working.
I don't use accessibility features, but I do daily drive a Wayland system (Fedora 39 and 38) and have experienced zero issues. I honestly don't even know what system any given app is trying to use - it all "just works". That is to say I don't believe the sky is falling like some people make it sound.
With that said - the more pressure that is placed on app developers to figure it out, the better. Kicking the can down the road just because XWayland works today is foolish. If you have an app that you rely on that uses X11 exclusively - you should complain to the app developers today so that tomorrow it doesn't stop working.
The entire Linux conversation on accessibility summed up in one sentence.
> If you have an app that you rely on that uses X11 exclusively - you should complain to the app developers today so that tomorrow it doesn't stop working.
And when they say, "we agree, what specifically do we need to do to be accessible under Wayland", what do I tell them?
What cannot be accomplished with ATK/AT-SPI?
It's literally all there... but alas, we love to complain.
Documentation and tutorials. I see X11 devs who aren't even looking at Wayland struggling with this stuff. It is very, very clearly not as easy as you are making it sound.
Nor are you in a position to say that everything works if you don't use accessibility controls. You're very confident that the at-spi protocol is fine for everything given that you are someone who does not rely on the at-spi protocol to use a computer and who does not use it as a daily driver.
I am inclined to say that if users who do rely on accessibility controls on a daily basis are complaining, probably they're not making up their complaints.
Who's fault it is that they're running into issues? Again, it doesn't really matter, the issues persist.
This entire thread started off by someone saying untrue rumors about Wayland and DE's regarding accessibility - so excuse everyone who thinks the complaints are likely misguided.
Again - if something is lacking in Wayland compatibility - now - is the time to ask app developers to update. If for some reason it cannot be done in Wayland, it should be reported to the Wayland project! This is not rocket science...
Right now XWayland works as it should. So provide some specifics or get off the pot...
I'm going to tentatively push back on this, my (very limited) understanding of the at-spi protocol is that it exposes application-specific controls and that it's not relevant to conversations about how to control a DE, and that current DEs do not in fact expose a common shared protocol across all of them for the kinds of controls that Talon needs.
I'm not an expert on this stuff by any means, but from what I can tell, OP is correct and is not spouting untrue rumors. I'd welcome correction in the form of some kind of accessible documentation for integrating with those window managers that uses a universal common protocol for all of them, but getting back to something I've pointed out multiple times above:
> so excuse everyone who thinks the complaints are likely misguided. [...] This is not rocket science...
This kind of response isn't particularly convincing given that I note you still haven't linked over some novice-accessible documentation about how to work with this stuff or test it, likely because that novice-accessible documentation is difficult to find if it exists at all.
I would love some easy ways to verify what at-spi controls, how to integrate with it in different languages, and how different DEs handle exposing it for their own interfaces. The absence of approachable documentation is a big reason why people are confused about Wayland (and about other good projects like Flatpak that get commonly maligned on HN, but that's a longer conversation). The absence of easy, clear information about how all of this stuff works might at least partially explain why application developers aren't quickly modernizing.
If you think that Talon developers are lying about how DEs work, then education efforts using clear, user-and-developer facing documentation about the protocols involved would be a pretty good way of combating FUD.
----
> Right now XWayland works as it should. So provide some specifics or get off the pot...
First, as others have mentioned, XWayland is insufficient for the kinds of needs that Talon has; operations like enumerating windows or handling focus can not (and should not) be handled via XWayland unless you plan to run your entire desktop environment in XWayland.
Secondly, XWayland is not the future. It is also a dead end. I'm glad that it exists for now, it is absolutely critical for early adoption of Wayland and is critical for supporting some apps. But XWayland is not a permanent solution to accessibility problems and it's wild to hear people simultaneously say that X11 is a walking zombie and to tell people that accessibility is fine because if there are any problems with Wayland you can always just tie your applications to a walking zombie.
The goal here is to get rid of X11, or at least that's what I think the goal should be, because I do think that X11 is a walking zombie and I resent the fact that I'm still using it.
----
My concern is not that Wayland can't be accessible or that there aren't ways to make it accessible. My concern is that regardless of whether or not universal protocols exist right now, it doesn't look like they're being used and it doesn't look like Wayland is going to be accessible for a lot of people in reality. And I don't care who's fault that is; it's still the case that calling developers lazy and accusing people who are sharing real accessibility problems that they have right now of spreading "untrue rumors" does not seem to be helping to improve the situation.
This isn't a situation like NVIDIA where there's one specific company we can all shame; if a bunch of disparate developers aren't taking the necessary steps to update their applications, then something is going wrong in the communication process or the steps aren't clear enough, or the incentives aren't aligned.
Again, I would welcome clear and accessible documentation that average developers could use that demonstrates how Talon could be made to work with Wayland and how the concerns its developers have (https://github.com/splondike/wayland-accessibility-notes/blo...) could be handled.
Accessibility is the one thing that xwayland isn't useful for; if my input system can't interact with wayland windows, what's the point?
Honestly, yes.
The iPhone is light years ahead of Android on the accessibility side, and it is the device you are most likely to always carry with you.
If you are using an iPhone, it already makes more sense to purchase a Mac, and from that point on going knee-deep into the Apple ecosystem makes sense in a lot of ways.
Like, you can hook up your smart doorbell to your Apple TV (for HomeKit), and when someone rings the door / motion is detected, Apple's image recognition can tell you on your iPhone who is at the door.
Notice that I never said applications. I'm aware that xwayland is actually quite good these days; the problem is accessibility and automation tools that it can't support.
> would you have expected Apple to support Carbon ad-infinitum?
> Look at the backwards-compatibility and new-framework-adoption-rate woes Windows has to deal with because Win32 exists and devs are lazy / expensive.
Yeah, devs are expensive, which is why backward compatibility is so important. Microsoft, for its many faults, seems to understand that breaking applications every few years and demanding that developers put in time in order to keep things working is poor form, leading to people making comments like
> I’ll also give a shout-out to our friends in the Operating Systems business: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, and so on, for doing such a great job of backwards compatibility on their successful platforms.
- https://medium.com/@steve.yegge/dear-google-cloud-your-depre...
In fact, the rest of that essay is a great commentary on exactly why this kind of thing is bad and why Apple should be derided exactly for this kind of thing.
…
> Wayland is 15 years old.
So, it's not very sudden, then, is it?
So much of what people see as wrong in Wayland is about slow-moving applications and driver vendors refusing to adapt; waiting until their software is actually broken before they do anything. We've had more than a decade knowing full well what is coming. I sympathize that an application you rely on is caught up in that. Nobody wanted that situation. But X11 has had a pretty good life. And unless Talon on Linux is suddenly abandoned, I really doubt those developers are going to keep hitching their wagon to X11. At some point, (probably soon now that distributors are getting serious about it), they will take a look at what's new and they will make it work with Wayland.
With that said, I don't think you have to worry for a while. I doubt apps are ever going to stop working in X11 altogether. You might end up with a different desktop at some point if you're using GNOME or KDE, but that's all.
> And unless Talon on Linux is suddenly abandoned, I really doubt those developers are going to keep hitching their wagon to X11. At some point, (probably soon now that distributors are getting serious about it), they will take a look at what's new and they will make it work with Wayland.
That's assuming that they can make it work with Wayland, which appears rather unlikely since the API surface doesn't exist. As you say, Wayland has had more than a decade but most of that time was spent loudly proclaiming that such functionality was a security problem and had no legitimate usecases so here we are.
> With that said, I don't think you have to worry for a while. I doubt apps are ever going to stop working in X11 altogether.
I certainly hope I can keep using X until Wayland actually reaches feature parity, but I'm already seeing pressure on both sides; waydroid is the first[0] application to outright refuse to support X, while Asahi Linux was loudest about not wanting to support Xorg but they're hardly the only ones. I suspect I'm going to end up with a 3-layer system comprised of cage[1] running xwayland running my real graphical environment with some applications in their own little cage windows. It's a little annoying but as a break-glass option it seems to function with only slightly more papercuts than X11 programs on Xorg:\
[0] Well, first that I've noticed at least.
https://wiki.linuxfoundation.org/accessibility/atk/at-spi/st... exists, but is fairly unapproachable and it's not clear to me as a developer where I would start if I was trying to either build an application that hooked into at-spi or to set up automated tests for at-spi events on my own software.
The common advice is always "use a graphical toolkit", but let's say I'm stepping outside of a toolkit like GTK and I'm building something smaller, or let's say that I want to build a toy screenreader of my own. I've had an awful time trying to find documentation about this stuff.
[1] https://en.trycht.cz/2023/12/15/down-and-down-exploring-the-...
[2] https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/main/READ...
[3] https://gnome.pages.gitlab.gnome.org/at-spi2-core/devel-docs...
So this is not meant to be dismissive of you, I really do appreciate it, but also wow this is still pretty anemic documentation compared to most other tech fields. I kind of wonder if this is also a chicken-and-egg problem because the way the healthy documentation springs up around projects is enough people use the projects that they run into issues, they start documenting best practices... and in areas like Linux accessibility where (as I understand it) there are often like 10-20 people total working on the technologies behind it at any given time, that community isn't going to exist and we're going to get tutorials that say stuff like:
> Of course, there are much more interfaces to use or implement for specific objects, like the Text interface for text controls, Table interface for tables, etc., but the principles of these interfaces are the same, just a normal DBus programming with all it entails.
So there aren't going to be a ton of people doing interesting things in that field or digging into how stuff works, which means it's not going to have people available to help make the field more approachable.
But again, I do appreciate the resources you did find.
The important bits:
> if you only say "accessibility" you may get the response "but at-spi2 works independent of x11 or wayland" the problem with at-spi2 is that it's opt-in by the application, so some programs just don't show up at all. the coverage of at-spi2 in video games is basically zero, for
and
> [...] wayland's stance on tools like talon is 'no' [...]
I may also need to switch back to windows if X11 support is dropped "too far" before wayland is there in the accessibility aspect.
I'm planning on moving all of my machines from Linux to BSD in part because of this, and in part because of SystemD.
A first step might be to just have a list of all the functionality affected by fragmentation. So far, unfortunately, most such lists are accompanied by if not subsumed within angry rants.
> they would probably diverge from GNOME and KDE by doing so
Which would be something I could live with. I dislike Gnome quite a lot so don't care about that. I do use KDE, but it's nothing that would hurt too much to do without if necessary.
> and anyway they are generally loath to include or endorse graphical components in the base system.
I don't remember the others off the top of my head, but OpenBSD certainly seems to be treating Xenocara as a core part of the OS? It's not in the main src tree, but it's maintained in-house, the x* sets are treated like any other, and even some non-graphical programs depend on the xbase set for things like font rendering.
Most X apps these days use only a tiny subset of request types anyway (source: lots of time spent with xtruss) and most of what's left is easy to shim.
The X protocol is messy, but very little of it is used by software people both a) care about, and that b) isn't available in source form and can easily be upgraded.
Sometimes I wonder about taking wlroots and doing a FrankenCompositor with first class X protocol support, including window management and all the bits the Wayland proponents keep not wanting to add...
To the extent that we allow programmable interfaces outside of the terminal, we put those interfaces on top of the graphics stack rather than underneath it and we treat them like alternative control schemes, not common interfaces that every input device should be hooking into and sharing regardless of whether they're for some "disabled" category or not. Disability is a spectrum, having separate categories for "normal" interfaces and accessible interfaces doesn't capture that.
These problems are kind of universal, but X11 just happened to be so wildly insecure and had such bad encapsulation that devs could work around that problem. Which... better than nothing, I guess, but our primary way of mitigating accessibility problems shouldn't be to make our software worse.
I'm still on X11; I haven't fully figured out tablet settings and I'm waiting for OpenTabletdriver to mature a bit more before taking a serious dive into Wayland. But does being on X11 mean that my desktop is accessible or that I can test software that I build with a common screenreader to make sure it works for disabled users? No, of course not, I use i3wm where as far as I can tell accessibility software like Orca can't hook into any of the programs that I run, even programs with explicit support for Orca.
I don't think the problem here is the technology, the technology just reveals a deeper apathy that has always been present. It won't be fixed until we change our relationship with differently abled users and start working with accessibility communities on shared protocols/interfaces rather than treating those interfaces like afterthoughts. A lot of the "debates" about accessibility requirements like controlling window position, etc... stem from that issue and probably have solutions that would work for everyone if we prioritized finding them and approaching the problems from different angles.
TBC I don't have any educated opinions about Wayland (I don't know remotely enough to know if the decisions they made are good ones in the grander scheme of things), more that it's this looming existential sadness that I'll eventually have to give up on Linux.
And this is probably some form of "losing", but honestly WSL gets me pretty close to where I want to be in the getting shit done department. Just not in the "not using Windows" department ;-)
(MacOS is another fine option, but I literally bought a framework laptop a week ago, so that door is financially closed to me for a long while)
Accessibility work itself ironically suffers from an accessibility problem. I brought up i3wm above, the issue for that is pretty illuminating: https://github.com/i3/i3/issues/3393
It's not that the devs are saying "this doesn't matter", the devs behind one of the most popular tiling window managers in the X11 ecosystem are saying, "this does matter, but we don't know how to fix it. We don't know what changes we'd need to make to be accessible."
It's a tragedy because I honestly believe that if accessibility communities were more heavily baked into testing and development in Linux and if this wasn't treated like two separate worlds, it would be better for everyone -- fixing accessibility concerns very often improves interfaces across the board and makes them more powerful. Of course, it shouldn't be the primary motivation, but it's worth mentioning that every single screenreader is a potential adblocker, every alternative control scheme is a way to automate and script software, every comprehensive text-based description of an interface is a way to pipe that interface into a terminal and build tools on top of it.
There's a huge amount of potential, but how do you bridge that gap? I don't really know, I tried looking into Orca to see what would need to happen here and bounced off of it pretty hard, it's not a very approachable tech stack and there aren't tutorials or getting started guides. And on the other side of the issue I can preach about needing accessibility input during interface design, but I'm not in a position to give specific advice because I don't use screenreaders or alternate control schemes and I don't know what the biggest problems are.
The people who need to be involved in that process can't get involved because there's a tech barrier in place even for technically inclined people, and because the underlying software locks them out from the start. i3wm isn't ever going to get someone who's intimately familiar with Orca to jump into the conversation because the people who need to use Orca can't use i3wm. So that leaves the people who can address that tech barrier, but they don't know what to do or how to approach the problem because of the lack of involvement and because the communities are isolated from each other. So it's a chicken-and-egg problem and I don't know how to solve it.
Cool. I guess I can delay switching to Wayland until the future!
RN dealing with -
1- when it comes back from suspend, the whole screen is filled with Rainbows. Pretty, but useless. 2- display scaling setting is either ignored or completely broken, no in between. Display settings in general seem wonky.
If I pretend these two things don't exist, the smoothness during gaming is far superior though..
But if were a random new user who booted into Wayland-only new fedora only to find my installation is already borked... what are we supposed to tell them? Oh yea, Linux is only for AMD users.. sorry!
I lurk on several Linux enthusiast forums and subreddits and whenever a new person wanders in asking why they get a blank screen on boot, or their laptop can't resume properly, or their desktop crashes randomly, I have observed that there is a roughly 0.95 chance they have an nVidia card in their system. (With or without the proprietary drivers.)
Wayland does not define AFAICT new APIs that a driver needs to support, but it does use the newer ones that nVidia never bothered to support.
WTF is this revisionism. There’s a reason nearly everyone in the Linux community has been trying to create an X11 alternative.
Because X11 is really terrible at doing many things.
Sure Wayland doesn’t do everything X11 does. Yet. It’s also decades younger and doesn’t have decades worth of patches and workarounds making things work.
Finally Wayland does things that X11 simply cannot do, and unlike Wayland where some of the things it “cannot” (more often chooses not to by design) do can be offloaded to other parts of the system, the same is not true of X11.
Maybe because the developers themselves have deprecated it? That would be freedesktop.org.
I think an X11 alternative would be a Good Thing. In the future, that might well be Wayland, I suppose. But I don't trust freedesktop.org; I have learned to expect them to play compatibility games in order to achieve hegemony. The main reason I use Linux is to avoid hegemonic overlords.
Agreed. "Perfect" is a stretch. What I'm saying, though, is that on an NVidia card, I can actually run a graphical system with X11. It has screen tearing and freaks out when my monitors aren't framerate matched, but it runs.
Wayland crashes on startup. Every time. I've tried every setting, every environment variable, every kernel parameter, and it doesn't work at all. And when I roll up my sleeves and dig deep on forums/github issues, the answer I get is basically "Yeah, this is broken. Blame NVidia."
X11 isn't under active development. That's not a good situation. However, I don't think the alternative is very compelling when their response to a super common system configuration being totally broken is "not my problem. shoulda bought AMD."
>Sure Wayland doesn’t do everything X11 does. Yet. It’s also decades younger and doesn’t have decades worth of patches and workarounds making things work.
It's over a decade old. The remaining blindspots as far as X11 backwards compatibility should be super niche things. Not "using NVidia."
Really? I find Wayland way worse for gaming. Like there's a few extra frames of delay or something. It _really_ messes with me and I can't stand it. It's why I'm still on X11 for now.
Edit: I did a quick Google search, and your comment is dishonest. Many people are complaining about input lag on the steam deck. They've even measured it [0]
[0] https://www.reddit.com/r/SteamDeck/comments/11yuulz/input_la...
Also, did you enable VSync on both the tests? And the same form of VSync? That can have an impact on input lag.
edit: I recall reading about timing experiments. IIRC good participants could get down to 10ms accuracy when trying to time moving their finger to a signal.
Nvidia's drivers are flaky and deserve their own condemnation, but that's a problem no matter what you use. You won't escape Nvidia's enormous firmware files and driver jank even if you run your machine headless.
That being said. Wayland is good and it shall have replaced X11 years ago! It is made by the same people which maintain X11. Same applies to Systemd, implemented in C, unified interface and simple configs. Nothing is perfect and things need to mature. As usual :)
And? Tactile keyboards, switches and knobs are much better than touch screens. Mechanical keyboards are the counter reaction to bad input devices. I love TUIs because they are more efficient than GUIs and easier than CLIs. GUI won? Notcurses (C++) and Rust bring many new TUIs.
But also?
I’ve seen Electron and from the first moment I wondered why it resembles Flash. With a built-in huge web browser. Eating resources and fitting nowhere. Same for touch screens in cars. And VR-Headsets…bruh…are that 3D-Shutter Glasses?!
Vice versa - I hope for lightweight AR-Glasses. But only with a standard VESA-Protocol or a BLE-Profile.
Personally I can't wait until everybody comes to their senses and drops this pile of garbage API and goes back to X11.
I know, all of the things I said can be said to be the worsening of the software. But what many people think when they read that sentence is that just the simple act of updating software is detrimental to the user's needs. Which I don't think is true all the time.
This is spot on and it makes me sad. We have hardware and programming languages available to us that people could only dream of 30 years ago and so much of the software we produce with it is objectively worse. I don't think Wayland (or X) is really salvageable at this point.
Same, but I'd take a step further. If the most common argument in favor of application X or Platform Y is that it's "more modern" or "the future", I make a mental note to avoid using that tech if at all possible - it's almost always guaranteed to be garbage. It's the tech equivalent of being set up on a blind date and being told the other person is "Nice".
Also, say what you will about Xorg, but it's very much 'batteries included', the idea of wayland foisting so much of what used to be X's responsibilities off to the wm just reeks of 'ivory tower'ness.
Any application with access to the X11 socket has easy privilege escalation available to it. By for example, injecting into a sudo enabled terminal or keylogging the user.
Admittedly, with Wayland the security situation wasn't ideal until recently with the adoption of security contexts that can finally allow you to deny screen capture access among other Wayland protocols to sandboxed applications[1].
[1] https://flatpak.github.io/xdg-desktop-portal/docs/portal-int...
<https://wayland.app/protocols/wlr-screencopy-unstable-v1>
I don't believe I'm an outlier. I believe most Linux users are like me: they are conscious of security issues, and they don't need a nanny to look after them. I don't think that the majority of Linux users are hot-desking corporate users, with multiple user sessions on the same machine, or trying to run a GUI over a network connection. Those are eccentric use-cases.
Red Hat/Gnome are trying to make a version of Linux that can be used by a child. I think that's a fine objective; but it's not even on the horizon. An operating system that just gets out of your way would be lovely, but for now it's a dream (and Windows isn't that system, of course; I think managing a Linux system is miles easier than trying to manage Windows).
As far as Gnome is concerned, it's experienced at least two violent changes of direction in its history. One of the things you need from a child-friendly OS is no violent changes of direction. If a GUI in particular changes dramatically from one version to the next, that's a big fail.
But this is a rather exotic scenario: the attacker uses an exploit that works on the Linux version of a browser, and uses that to attack some other application running under X11. That's a complicated chain of dependencies; it might be worth it if I was operating a bank of Uranium centrifuges, but not just to violate my privacy (e.g. steal passwords from my password manager).
I think Wayland is a fine project, and when it's mature I'll jump. I'd prefer a local-only GUI. But I don't think it's mature yet. And the way it's pushed reminds me of Poetteringware; I need to be sure I'm not being shafted.
Are you misunderstanding what the OP meant by "socket"? It doesn't have to literally be a network socket, but your X11 apps all connect to the server via some IPC mechanism, could be a network socket or a local named pipe (I think it lives out in /var/, but I'm not on a Linux system atm). Their point was there is no client authentication or separation via this IPC mechanism: one X11 application can send messages directly to another X11 application. That's where their example of a malicious app inserting text into a sudo terminal comes from. You can see this for yourself using a virtual keyboard program. It's just an X11 app like any other, it's just injecting messages for the server to dispatch to another client.
> I believe most Linux users are like me: they are conscious of security issues, and they don't need a nanny to look after them.
I feel under this argument, you can also describe memory segmentation as a "nanny" =/ I don't think many would argue we should go back to shared memory systems.
Sure. I get that. But I don't run malicious applications on X; and I don't pipe the output of curl into bash.
> I don't think many would argue we should go back to shared memory systems.
Me neither. But from my perspective, memory segmentation is necessary to protect me against incompetent programmers, not malicious applications. Breaking X11 security isn't something that happens by accident, it requires actual malice.
The thing about malicious applications is that they usually don't do a lot to inform the user that they are a malicious application. "I don't run malicious applications" is a claim shared by nearly everyone who's ever run a malicious application.
Back in the 80s, I got viruses and trojans, because (a) I was promiscuous with floppy disks, and (b) I worked with students. And I installed software from shady places that came with unwanted stuff like browser toolbars.
Nowadays, I use Linux, and I find I can rely on the distro's package repository. So I only install software from the repository; if I need to try something that isn't packaged by the distro, I proceed with extreme caution.
I'm sure it's different if you're running a corporate Linux desktop fleet; but this is a home network, with one laptop that runs any GUI at all. The laptop exposes no network ports. In fact the entire home network exposes no internet ports.
I think Red Hat would be fine, if they'd stick to serving corporate requirements. I just wish they'd stop shoving stuff down the throats of non-corporate users. I'm particularly annoyed by systemd; Poettering is a specialist in throat-shoving.
Unfortunately, I don't seem to be able to get Bluetooth Audio to work on Linux without pulseaudio. I have a pair of nice Bose cans that I can't use, because I don't want to run pulse. I need a bluetooth audio stack that depends only on ALSA. (I think it's possible, but every time I try I run into a brick wall, and I've got tired)
People frequently get mugged in broad daylight in 'safe' areas.
Malicious applications can come in trustworthy looking packages. Just look at the amount of malicious applications that have been found in python libraries recently, none of which you would have installed or used directly.
X is insecure and your habits maybe have been enough to protect you so far, but banking on them always doing so in the future is kind of silly.
One person may not be gullible enough to unintentionally run a malicious application, but once you extend it to a group of people, the claim will likely no longer be true. What if your coworker(s) accidentally ran a rogue X11 application, their passwords got keylogged, and now your company systems are compromised?
And the above paragraph only operates under the assumption that you, the one person, is perfect, who never makes mistakes, never runs malicious applications, and runs on a distro that is never compromised, providing programs developed by people who are security-minded.
You might have been compromised never knowing it.
On the other hand, the other day when I shared my screen on Firefox, my Wayland compositor (indirectly through xdg-desktop-portal) asked me to confirm that it was my intention to let the browser see my desktop. I felt that was pretty nifty.
If I'm running a malicious application, I have much bigger worries than a an injected sudo. It has access to all my files!
> I feel under this argument, you can also describe memory segmentation as a "nanny" =/ I don't think many would argue we should go back to shared memory systems.
On my desktop I use memory segmentation to protect against programming errors, not for security.
If you practice sandbox hygiene on linux (eg. bubblewrap) the only files it will have access to are the ones absolutely necessary for its functioning such as a private /home/user per application. However if you use X11, all such measures will be useless.
You could of course run nested X11 (eg. Xephyr). But the inconvenience is of such magnitude why not use Wayland?
You're not hearing me. For most desktop users, there was never a need to sandbox applications. It's simply not a threat vector 99% of desktop linux users have ever dealt with. It's certainly not a big enough problem to break the screen / input recording and sharing of tons of applications. Again, if you need to do that, the correct way is to PROMPT the user, not invisibly disable it entirely.
And the sandboxes that do get used aren't very vulnerable to X11 attacks. If you're running firefox the web process sandbox doesn't have X11 access, and by the time the rendering process gets chain-exploited it can access your files directly without needing to go through X11.
Even if Firefox is perfect, that still leaves everything else which connects to the outside world or opens downloaded files. We know there’s a long history of those exploits and everyone serious in the desktop OS space has been trying to harden things so it’s not a single mistake away from an irrecoverable compromise.
Security needs to allow usability or the whole system fails.
It's rather vague and kind of hard to find more detailed information.
I also agree with the sibling comment from tedunangst that most people just don't worry all that much about keyloggers, nor should they IMHO because it's not really a common attack vector.
[1]: https://fedorapeople.org/~dwalsh/SELinux/Presentations/sandb...
Batteries included? That is the reason why X11 is/was shipped alongside Wayland for some time. It will be dropped and XWayland remains for compatibility reasons. And Wayland has already some batteries X11 doesn’t, better scaling support. Security through Portals/Flatpak. We’re in 2023, screensharing works for some time now ;)
We don’t get stuck in legacy hell like Windows. And we don’t cut off compatibility like Apple. Bumpy ride but prospects are good.
Next thing? A new virtual console for userspace? Something like KMSCON? https://en.wikipedia.org/wiki/Kmscon
I don’t want delete the good old thing. I want see them alive and improving :). Without the usual “it must become worse before it becomes better”.
But yes. Flatpaks require more memory and disk space and fixes in private libraries are not fixed by a friendly package maintainer for all packages. I use native packages from Arch for most stuff and for new hot or weird stuff Flatpak. Especially for Closed-Source weird stuff.
I prefer most - if not all - handle by native packages because that is a core feature of Linux. But there will be always others for reasons. For example plugins, Vim relies here mostly on Vimplug. Steam is thing I need to accept but itself a candidate for Flatpak (currently I prefer the native package). And to be precisely, Meson is also a package-manager for C/C++ developers.
PS: I also use Flatpaks when otherwise many unusual dependencies are involved. That one application using Qt? Flatpak. And vice versa some applications which doing well move from Flatpak to native package (Marker did that).
PPS: GNOME-Software does a good job in handling native packages, Flatpak and LVFS at the same time. I use mostly pacman, flatpak and fwupd. But sometimes I need the captains approach “Linux. Make it so.”.
legacy hell hasn't been a thing for a long time, and flatpack basically uses the same solution Windows does - numerous redundant different versions of older libraries.
> And we don’t cut off compatibility like Apple
Without Flatpack or similar, Linux is honestly pretty terrible as far as backwards compatibility goes.
Worse latency and performance (on intel and AMD), xdotools don't work, window managers don't work. Doesn't work without dbus (the first thing I usually uninstall) and additional seat/login daemons which indicates its bad design.
https://news.ycombinator.com/item?id=38281264
Firefox Is Going to Try and Ship with Wayland Enabled by Default (phoronix.com) 151 comments
Previous discussion:
https://news.ycombinator.com/item?id=38488850 17 days ago, 6 comments (mozilla.org)
`xdotool search` seems like it has been deemed a security issue for reasons I can't understand (if someone has hacked in to the point that they can even run such query commands, surely I'm already pwn'd). Maybe I'm oversimplifying it, but to me it's like being upset that someone who broke into your house can see the color of your curtains. The powerful feature set of X far outweighs these minor security concerns.
And it looks like xpra is facing huge issues switching over https://github.com/Xpra-org/xpra/issues/387 :(, I have yet to be as satisfied with any other free remote desktop software (paid nomachine is close but less scriptable).
I hope these aren't fundamental limitations of wayland, but the challenges seem steep.
Achieving RCE in a single program meaning your entire system is pwned is behind the times compared other operating systems. In order to make freedesktop's security competitive again security restrictions need to be added.
I believe the idea is that by adding security measures in the graphical server, you can limit it better. So yes, if there's no other protections then the graphical server is the least of your problems, but if you run a program in a container then the graphical server becomes the weakest link so we'd like to protect it. (I don't know why other protections - https://wiki.archlinux.org/title/Firejail#Firejail_with_Xorg or XACE - weren't good enough, but there is an argument for something there)
Firefox can't "default" to anything because it has to run atop whatever display server I'm running. I guess you could say it "defaults to Wayland" instead of XWayland, but I can't see that being the common interpretation.
Of course if only X is available (or only Wayland) it will continue to use what is available.
I think "Firefox now prefers Wayland over X" may have been a bit more accurate, but that also has other possible interpretations.
Firefox is kind of flakey on Nvidia wayland too. Sometimes it just refuses to launch, but it mostly does work with GPU acceleration if it manages to launch.
I should mention that every bug, and dozens more, immediately disappears if I disable the Nvidia driver completely and just run off my AMD IGP.
I hope soon, the FreeDesktop people will formally stop "supporting" X.org so some other, more interested party can finally take control. FreeDesktop's charter promises that they will extend X.org, not abandon it OR replace it, so if you've given donations to them (as my organization has) you should feel a little ripped off.
Citation needed.
Since you are the first in this comment chain to assert that Wayland is bloated, perhaps you should also be the first to provide evidences to support your assertion too.
Proof needed.
Another way of looking at this, Apple did the same move over a decade ago with far more limited hardware and pretty much everyone loved it because the speed and stability boost was quite noticeable.
But with Wayland, who does the physical rendering? This responsibility is all now dumped on the window manager?
Edit: ahah, modern systems punt the actual drawing off to the kernel, using Kernel Mode Setting. What I would’ve called the framebuffer when I were a lad.
The application renders to a texture.
The compositor takes all of the textures from windows and composites them into a single texture that will then get displayed.
> This responsibility is all now dumped on the window manager?
No, the window manager manages the windows and giwen the compositor information on how it should composite.
The TL;DR is that the vast majority of apps are now rendered on the client and most window managers are compositing. This means that the flows look like this:
1. X server reads input.
2. X server sends input to the window manager.
3. The window manager maps the input to a window and sends it back to X.
4. The X server sends it to the clients.
5. The client re-renders and sends it's buffer to the X sever. (Unsyncronized)
6. The X sever sends the new buffers to the window manager.
7. The window manager composites the desktop and sends the result back to the X server.
8. The X server displays the buffer.
The TL;DR is that the X server just does inefficient IPC and some top level I/O. Basically all of the rendering is done in the clients or window manager.
So Wayland attempts to improve on this model, highlights are:
1. Well designed IPC interface and async/hotplug baked in.
2. Remove the X server intermediary.
3. Actually add frame metadata to allow avoiding tearing.
4. Switch to a more declarative approach for most APIs. For example actually having the concepts of full-screen, modals, popups and screensavers. This fixes issues like using volume keys while a context menu is open and many others.
5. Provide the ability to have capability-based security for things like reading other application's outputs and inputs.
The top level I/O management have been moved into libraries as much as possible. Output is mostly managed by the regular graphics APIs and kernel DRM and input is managed by libinput. Of course you don't have to use these libraries, but they are pretty commonly used.
People get upset that there are now N compositors, but in X most window managers were compositors anyways, it hasn't really changed this equation. There were also lots of optional extensions so window-manger compatibility was never perfect.
i am in support of pushing for newer standards this way, whether that is the intention or just a side-effect. no progress happens when people in the most impactful position refuse to adapt it. the needle moves only when casual users are made to test it.
almost 10 years ago, nvidia drivers sucked massively for laptops with hybrid graphics on x11 (sometimes not giving video out at all). they now suck at wayland. if we put up with all that in the past with the older standard, so be it today in the name of progress.
Every time I try to enable it, either: everything still uses X11 on reboot, or the system boots to a black screen and I need to use recovery to revert.
Game changer.
How does "dark mode" work in desktop linux?
I'm using i3wm and I haven't been able to find a way to "press a button and every app turns into dark mode". To be clear, all my apps are already configured to take the theme from "system theme", I just haven't been able to find how to change this system theme.
On android this is pretty well integrated, what's the deal with desktop?
But no matter what theme I choose, there will always SOMETHING be broken. In one theme some part of an application will have black text on a black background. Another theme fixes that, but them makes in the alt+tab application switcher the part that highlights which application you're selecting invisible. Other themes have almost invisible scrollbars. Various applications have missing icons because they no longer have their own built-in ones.
I wish every application just had its own actually working built-in theme, rather than trying to shoehorn a global desktop theme inside of everything. It used to be like that in the past and it looked perfect compared to the mess now. Desktop theme settings should just be about the outer window borders and stuff.
Also, does there even exist ONE theme still today that actually visually distinguishes the selected and non-selected windows well? They're all super subtle about this now. Give me a bright blue selected window, gray non-selected window titlebar please so I can tell at a side-eye glance what's focused.
I loved KDE 3.5, but ever since KDE 4 and plasma, I've tried multiple times and never liked it.
I also don't like Gnome, doesn't fit my workflows well, it doesn't support moving windows between multiple desktops well, no window list enabled by default, ...
https://medium.com/@fulalas/gnome-42-the-nonsense-continues-...
What's a theme and customization if the DE/app forces 'themes' on the user?
Getting downvoted over this further prove my whole point
-Allow to choose theme for the window decorations (titlebar etc...) and the desktop itself in its settings and have this applied consistently in the desktop (all applications use same window decorations on the outer part of their windows, ...).
-Let application have their own icons inside of the window (I have nothing against applications reusing icons, but let the developer choose them, not desktop-dependent since that's clearly not working out). Like say the "save file" icon in a text editor: I'd rather have a well-chosen one by the developer of this text editor, than one that either doesn't work or look completely out of place but was enforced by some desktop standard.
What I don't like is:
-applications changing / removing the outer window borders. They have no business changing that, only the inside content of their windows. E.g. a browser removing the title bar of its window can make some menus the desktop provides there inaccessible, make it invisible which window is focused, etc...
-application using external theme (e.g. based on some desktop standard) icons for its internal contents and then not working properly because the creator of the application could not know what the external theme would look like. This does not work out for various reasons: having 1 desktop setting makes it impossible to fix individual programs since changing theme to fix 1 may break another, e.g. say you have themes "adwaita" and "greybird" in your desktop setting, theme adwaita breaks program A (e.g. it shows black text on black background; just arbitrary example, not saying adwaita actually does this but I know at least one epub reader that showed black text on black background for some desktop settings in real life) but works in program B, and theme greybord works in program A but breaks program B (e.g. its icons will be invisible or whatever): If program A and program B just had their own inner contents, this problem would not exist.
Also, different applications having to be consistent across each other for their inner contents is something I couldn't care less about, so it's not worth all the problems it causes.
Use of CSS in GTK for theming (maybe Qt too, not sure?) doesn’t help matters since both user applied-themes and developer-applied CSS can screw things up by overriding things in a half-baked way.
I have a button in gnome that toggles dark mode on/off that switches the desktop over that works for just about everything (not discord though).
Is this something I can use if I'm using i3wm?
If you're using a Window Manager (like i3) they are unlikely to come with utilities like this. You need to download another app (lxapperance for Xorg) or write a script to flip the appropriate settings.
#!/bin/bash
color_scheme=$(gsettings get org.gnome.desktop.interface color-scheme)
case $color_scheme in
*default* ) new_color_scheme="'prefer-dark'";;
* ) new_color_scheme="'default'";;
esac
gsettings set org.gnome.desktop.interface color-scheme "$new_color_scheme"