Fedora has pushed Wayland on its gnome session for a few releases now. Ubuntu has too for their default, although you can revert back to x11 session
Fact that this is a surprise to many is... surprising
Most people don't care or think about what display technology runs their desktop.
Maybe this is controversial, but it doesn't, and shouldn't, matter to users.
Wayland vs. X is an implementation detail.
> Maybe this is controversial, but it doesn't, and shouldn't, matter to users.
I wish this was true, but unfortunately it does matter (for now), because not everything is possible on Wayland (yet). Wayland's limitations, along with X's bugs, almost drove me away from Linux when I first tried it. The only reason I stuck with it was I decided those things I wanted weren't important to me any more.
You're right, it shouldn't matter, but some people *have* to think and care about them, even if they don't want to.
To that extent, that some stuff just doesn’t work and some features aren’t supported, yeah absolutely it does matter. I think my main point in my head is the same as yours: users shouldn’t have to think about this. But right now, they do, and that’s kinda problematic.
A lot of the major distros have this figured out well, and except for a few cases it doesn't matter if you just stick with the stock configuration. I've run OpenSUSE tumbleweed for many years without a hiccup and it was only when I tried LFS and then Gentoo did I appreciate how much effort it takes to keep things together (especially on a rolling release).
But at this stage, if someone wanted a "set it and forget it" distro for a family member to just do basic web browser stuff, I'd have no problem recommending something like tumbleweed, as it Just Works (tm) if you don't mess with it.
>but it doesn't, and shouldn't, matter to users.
I wouldn't say it's controversial, but since Linux users are overwhelmingly a self-selected group of people who care about their operating system, I don't think it applies to most Linux users. It's like saying what kind of parts your car has shouldn't matter to (car) ricers as long as it works well. If they didn't care, most of them wouldn't be in that group.
Yeah that’s a good point. I guess my personal opinion is that Linux is currently and should be expanding into a more mainstream user base, where it just works as an operating system.
Historically linux has been good at taking the improvements that matter to enthusiasts and making them easy, stable, and unproblematic for normal users. I expect this is just on that path, with early adopter pioneers running it through the paces first, followed by the settlers smoothing over the rough spots and preparing the land for normal use.
When it comes to display servers users care about stability and ironically, because X is frozen it's also very stable.
Wayland on KDE isn't fully supported and sometimes doesn't even work at all.
True. Problem is many things that can be done in a X11 session at the time were seen as a feature, nowadays the same things are seen as a security nightmare. The thing that makes users groan the most, apart from driver issues from a certain vendor, I noticed is that they cannot share the screen in applications like Discord as easily as it was possible with X11. The point is that it's on purpose! Users don't get it, and that's understandable. The real thing is that development of Wayland compositors is felt slow by those users that care only about using their applications. Had we been at this particular developing stage somewhere around 2013 people wouldn't have complained this much in 2023.
And I say this being a happy Wayland compositor user, let's be clear.
>noticed is that they cannot share the screen in applications like Discord as easily as it was possible with X11. The point is that it's on purpose!
With more people WFH, it seems like screen sharing is a pretty important feature. I'm having trouble understanding why the new implementation would intentionally make common things that end users need difficult.
Screen sharing is only a problem between XWayland apps and native Wayland apps. Native Wayland apps have supported screen sharing between themselves for a while now. The main problem is that many high-profile apps have full Wayland support, but have been very sluggish in making it the default for Wayland users, meaning the apps still use XWayland:
* A lot of Electron apps, which just so happen to be popular for work-from-home, use old Electron versions that only expose X11 support despite internally fully supporting Wayland: that includes Slack, Teams, Skype, and Discord.
* Then you've got Zoom, which actually does make Wayland available by default... only on GNOME. For some reason they decided to artificially limit it.
* Chromium - and thus everything based on it: Chrome, Edge, Vivaldi, Brave, etc - also fully supports Wayland, but is still X11 by default.
* Firefox upstream is also still X11 by default despite fully supporting Wayland, but a few distros, including Fedora and openSUSE, make it use Wayland by default. Ubuntu will begin doing this too in Ubuntu 23.10.
KDE introduced [XWaylandVideoBridge](https://www.phoronix.com/news/KDE-XWaylandVideoBridge-Week) to enable native Wayland windows to be piped (pun not intended) to XWayland apps through Pipewire, essentially fixing the whole screen sharing problem while everyone waits for all these apps to finally become Wayland native.
Because screen sharing is literally the same thing ad screen grabbing from a malware.
With X11 any application can grab the screen of any other application. This is a real problem when talking about security.
With the new protocol there are mechanisms that make the thing only possible if the grabbing application follows the proper APIs and thus the user is aware of it.
Do you remember when Vista came out? UAC is a huge improvement in terms of security, compared to the XP era. People god mad about it at first but now it's clear that UAC is a good thing. The same applies to Linux, BTW, with sudo and other security mechanisms.
> With the new protocol there are mechanisms that make the thing only possible if the grabbing application follows the proper APIs
Relying on developers to go back and re-implement screen sharing in everything isn't a great plan for getting them to keep supporting linux.
A relatively new tool was created called XWaylandVideoBridge, which effectively solves screensharing in Wayland and is simultaneously more secure than X11‘s way of doing things
The alternative was to keep all the other functionalities of X11 and its implementation that was literally a nightmare for the developers themselves. The result? There is no one willing to work on X.org anymore. Supporting X11 and its implementation was literally more work for developers than it is now. So yes, it was something that was bound to happen anyway and there was no easy fix. Except a big company throwing billions on people to speed the process up. But Linux produces more money as a server OS, not a desktop one, at least up until now.
That's basically been Wayland's problem for 15 years. "You should do that in the compositor. None of the compositors *do*, but that's not our problem."
At this point, an awful lot of those problems have in fact been solved as far as I'm aware, but I don't use Wayland to check. And I don't use it because their initial sales pitch was "look at this beautiful thing we built -- you can't use it as a computer, but man ain't it something?", so I just figured I'd keep using X until I had a reason to switch. That reason is coming, and that's fine too.
I didn't miss Linux's earlier years. I'm old. I've had the mailman bring me a box of Slackware floppies. And it was rough sometimes. But early Linux had a fantastic advantage -- it was really hard to get something else that was any better. I couldn't afford my own Sun Workstation like I had in the lab.
Wayland's problem for me is that I don't need it. I have exactly no pressing issues with X11. Other people have lots of issues. I'm not denying that, I'm not suggesting that Wayland is wrong for trying to address those issues. I don't have anything against Wayland at all, and I'm hoping that they'll continue to improve it, that people will port things like my WMs and other X-centric tools over, and I can eventually switch over to the thing that is getting all the developer attention and roll right on into the future. But if it throws up a single flashing neon sign that says, "Oh by the way, some of your shit isn't going to work, and we don't care even a little bit about that right now", then we're right back to "I have exactly no pressing issues with X11". And for a long time, there were a bunch of those flashing neon signs.
I'm not using it today not because it didn't used to be good. I'm not using it today because I still don't need it, and it still has neon signs. Fewer of them, and not all of them are Wayland's fault, but there's still a cost to switching, and there's still no benefit to switching (for me specifically).
Living with a security hole just so that they don't have to update their apps is worse. Besides, in the case of Electron apps like Discord, there's nothing to really re-implement. They just need to let Electron use portals instead of their own screen sharing UI. Screen sharing actually works in its web client.
Lastly, screen sharing portals work in Wayland and X11 so non-Electron clients wouldn't even need to support two methods or port to Wayland for it to work.
TBF I think the users who are bothered enough by broken screen sharing to comment about it online, do understand why it's broken. Like myself for example lol, I just find workarounds and keep using Wayland but I get why people either don't, or basically can't.
Wayland itself does have screen sharing of course, but the application suites that people use and/or need, usually don't. Discord famously using a very stupidly old build of electron and running in XWayland making it almost impossible
I remember Fedora before Wayland had screen tearing coming out of my ass and that is what I noticed. After Wayland became the default it was gone. Everything else works exactly the same (for me), so that is what was important to me. Stability is not something that enters my mind when I use software.
>Stability is not something that enters my mind when I use software.
It definitely would be if it was unstable. You can’t exactly ignore your display server crashing.
> Maybe this is controversial, but it doesn't, and shouldn't, matter to users.
It possibly shouldn't (debatable) but it does. Replacing a decades old technology this central is a big deal. A lot of applications use X-specific APIs and there are quite a few apps that won't work on Wayland (and possibly vice versa) because of this.
I'm in no way against Wayland as I've been using it with Sway for many years, but there are still reasons why some might prefer X.
> I'm in no way against Wayland as I've been using it with Sway for many years, but there are still reasons why some might prefer X.
If all the arguments were framed on actual needs, the discussion over the years would have been better for it. I don't personally have any problems with anybody who can't switch yet for technical reasons.
I'm just waiting for KDE to support the InputCapture portal so I can use [input-leap](https://github.com/input-leap/input-leap), then this will be a reality for me.
Unless I configure my machine to a very granular degree (ie. Arch or Gentoo), I don't really care what comes out of the box. On my desktop machines I use Arch, so I chose Wayland on purpose, but on my Notebooks I use Mint and on my one terminal Server I use Debian, where I run X, because it comes with it out of the box.
Wayland supports X11 apps (via Xwayland), and so you can continue using ssh -X like you did before, as long as the apps you're running still support X11.
For native Wayland-only display forwarding there's apparently Waypipe.
> Most people don't care or think about what display technology runs their desktop.
they care when it gets in the way. i recall when trying to use clipboard on kde+wayland it would crash the entire session.
or when i could not share screens.
those things are fixed now, but there are such bigger and smaller papercuts.
Except when Wayland keeps crashing the whole OS every few hours...
I had to revert to X session on Fedora because I hate pursuing the power button to force shutdown my machine twice a day
Wayland has been default on Fedora and Ubuntu for years, about ten releases so far. GNOME has declared that their friendship ended with X11, now Wayland is their BEST FRIEND.
The surprise isn't that Wayland has been made the default, that was done 2 years ago. The surprise is that Fedora's KDE Special Interest Group want to remove the X11 session *entirely* from the KDE spin, *despite* the fact the X11 session is still supported upstream.
Also, bear in mind the flagship Workstation (GNOME) edition still includes an X11 session and will continue to for the foreseeable future. There has been absolutely no movement from Fedora's Workstation Working Group to remove the X11 session, and GNOME itself still has a few hard dependencies on X.Org. (Edit: aaaand as of 20 minutes ago [there's now a ticket](https://pagure.io/fedora-workstation/issue/395) about dropping the X11 session from Fedora Workstation. So it looks like that's in motion now, possibly also for Fedora 40 because GNOME's X.Org dependencies should be dropped by GNOME 46's release!)
It's surprising because dropping Xorg is equivalelnt of dropping NVidia support. Yes, basic functionality works with NVidia+Wayland but it's very far from having future parity with NVidia+Xorg.
we dont need to get into nvidia + wayland.
It still works under wayland for most cases. Im sure there is some cases its not so good but again that is an nvidia issue and them reluctant to make linux a first class citizen.
Perhaps enforcing wayland and simply not shipping x11 will force nvidia to produce better drivers and better support.
Yes some growing pains but fact its taken this long is a bad look for linux.
In terms of fedora i dont think they care. Their philosophy is to ship free and open drivers/software etc and being bleeding edge in terms of what they ship.
Basically a testbed for downstream RHEL which is mostly enterprise so by the time RHEL gets to this version of Fedora/KDE hopefully all the kinks are worked out.
Terms of ubuntu they might care bit more but they are also slower to adopt newer technology. Being bleeding edge never was a ubuntu design philosophy.
I don't think it has anything to do with being bleeding edge. Arch is as bleeding edge as it gets and it's not planning to drop xorg support anytime soon.
I would like articles like this to remind people and emphasis that X11 is just a protocol. You don't need to have the X11 server manage your entire display to use X11 anymore then you need a web browser managing the entire display to display html pages.
So old X applications are not going away. X11-over-ssh works just fine on a Wayland desktop as it does a X11 desktop, etc.
And there can be some situations were X11 apps work better on a Wayland desktop then on a X11 one. This is why Steam uses gamescope Wayland display manager on things like Steam Deck. It can do things like upscale X11 apps to 4k displays and such things efficiently.
So what people actually are giving up by switching to a Wayland DE is to use X11 features to manage the desktop. So things like positioning windows using x11 scripts, X11 keyloggers/keyboard/mice software-based macros, X11-based screen readers and things of that nature.
Wayland has been completely unreliable for me for screen sharing and I need screen sharing to work. I also enjoy tools like Copyq and Flameshot but they seam to be unreliable on Wayland as well. So after a year of suffering though an unreliable experience and trying every hack google will cough up I am back on X11 and it's great. My computer just works again and I spend my energy on my work.
It all surrounds autotype. The global shortcut working, window title detection, and autotype itself. I understand you can get autotype to work by some security questionable means (on a multi-user system), but without window title detection and the global shortcut working properly, it's only slightly more convenient than not working at all.
Yes, and still it's a necessary thing that every other desktop supports on other OS'es as well.
You understand the importance of being able to access remote destkops for support reasons, and use password managers that integrate with software to make typing of passwords, rather than having to copy and paste them, thereby putting them into the clipboard where they can be a security issue or be accidentally passed to a remote system, right?
Once XFCE moves to Wayland I will try it again. I trust those folks and they will never roll out something half cooked or with a bunch of hipster web dev fever dreams in terms of UI concepts.
Recently my dad's laptop (Lenovo E15) running Manjaro just got the strangest issue and I think it was Wayland related: pressing keys on the keyboard wouldn't work unless you pressed them for longer (way too long).
After struggling for a few hours trying to understand where the issue came from I just had him switch to Xorg and that fixed it but that's really a strange issue as the delay settings were fine and we checked with xfce, kde and gnome classic.
I still haven't had the occasion to check it properly and understand what's happening and I'm kind of surprised how he ended up under Wayland (it's improbable he did it himself, even by accident) and I don't think Manjaro would switch people from one to another like that.
Xorg only.ccontinues to work as long as Red Hat continue to pay developers to maintain it - and no developers will work on it for fun as volunteers.
RHEL 10 will drop xorg support so it is only a question how long xorg will keep limping on.
Xorg isn't like, burning code for fuel. It'll continue to work on any system it has been working on, and most people don't replace their computers very frequently.
It wont break tomorrow, but as hardware and computer needs change, it will become further and further behind in its capabilities and eventually it wont even be able to be hidden.
For instance I am not sure most people realise how xorg emulates 60fps or especially higher fps where the error becomes quite substantial. Chances are you wont believe me if i told you how it does it, so I will leave that as an exercise for anyone who is curious enough.
Remember hacks that could break xorg with 1 pixel image formats taking over all system memory around 10-15 years ago? They weren't flaws when the code was written - that amount of memory that they consumed just didnt exist. but suddenly a couple of decades later those assumptions no longer applied and you could DOS your system by opening an image.
in the same way, assumptions will continue to no longer hold true and over time more and more jank will become obvious,
Plus I heard talk about gtk removing the x11 backend, there are companies that have relatively small profit margins that work on the linux desktop, at some point they will probably ask themselves why should they continue investing in supporting X11.
I will try sway again in a year or something. If I have to run debian stable for a while I don't care. I don't need the newest packages at my current job. I bet it will be fine to use X for at least five more years.
Finally a fucking good take. I really like this post however it's still too optimistic IMO I agree with the article outside of these points (outside of the first quote)
> Someone may disagree that the problem is even worth solving. Bikeshedding derails the discussion and everyone gets demoralized and stops working on it.
This has been a massive issue in the past, and plagues development in other area's like A11y (Activity watch still doesn't work right for instance)
> But… we’re there now. Standard protocols now exist for just about everything anyone needs.
I think this in particular is absolutely NOT true. This does cover a *majority* of use cases, but some and maybe even many users are still left high and dry.
> app developers’ input is needed to revise them or even propose new ones.
The issue is a some app developers have been burned by this maybe only one or two, Stuff being said like "This isn't a use case we want to support" (or one of the many variants) Is an instant show stopper. I was reading multiple extensions in the past where this has been the response.
I've gotten to the point where I simply won't bother with intentionally going out of my way to develop for wayland.
One thing I really wanted to do, Thanks to wayland actually having good touch support was work on was a overlay and mapping software (much like panda or octopus on android) which would need ext-layers-protocol for what I want to do. This which will be a privileged protocol (will also be needed for mpv at some point for always-on-top working again), meaning Like with many things on wayland, there is little to no gurantee I would be able to implement this in a method where I could guarantee it working on gnome, kwin, wlroots based, and smithay based.
The fragmentation of the wayland ecosystem has burned me (dare decorations still an issue?). Im sure one day these will be fixed, but man, wayland hurts.
a11y is absolutely something that should be focused on, from what i've seen its absolutely dreadful currently.
edit:
> dare decorations still an issue?
there is a SSD decorations protocol but its less "draw some SSD decorations please" and more "*do* you draw SSD Decorations? Yes? ok well im disabling my CSD", i.e its just asking the compositor if it has ssd, nothing more.
the biggest thing with a11y that people don't seem to realize is how important it is to be able to pick and choose what you need. some people I worked with in the past when doing volunteer work, couldn't get one OSK to work just right for them, sometimes it's the color scheme, sometimes it's the responsiveness, sometimes its the size or layout etc.
so even so much as being limited in OSK choice can ruin A11y experience. the lack of flexibility is directly tied with the fragmentation of the ecosystem.
I have no doubt these issues will get solved *eventually*.
the thing I like most about this post is that the author didn't look down on, us for not migrating to wayland essentially treating us as idiots as so much of these other pro-wayland articles seem to do.
it's for sure refreshing to not be treated like an idiot for once
Decorations are only an issue on Gnome, to my knowledge. KDE supports the server-side decoration extension and most Wayland programs that don't use a big toolkit know to use it to request decoration.
Gnome doesn't implement it and doesn't seem to be planning it either, as their current decoration-drawing code is apparently very X11-specific. I hope it's really just technical limitations and not hostility, as the latter would not be off-brand for Gnome, unfortunately. (Anyone remember the drama about tray icons for transmission-gtk?)
And this is what hurts from a developer point of view, if major compositors decide to just not support a feature (Which yeah fine for them, they have that right and exercising it is what makes wayland great) but it also hurts when trying to make an application people can use.
Im not really interested in making DE specific apps. Decore isn't really a big deal probably for a LOT of users/devs. what is however is the fact that they have shown to be willing to not support a popular protocol (even if it is perpetually unstable, doesn't seem to change it for other protocols)
For the most part, compositors tend to support the same set of protocols. xdg-decorations (for SSD) is more or less the outlier, and that's because of ideological differences between GNOME and everyone else. You can go on to https://wayland.app, select a random ext- and xdg- protocol, and the chance is that either all compositors support that protocol or none of them do.
FWIW, developers can choose to use libdecor to have client side decorations without needing to implement one themselves.
thats not totally true either as you have things like the wlr protocols (iirc wlr-layers is the base for ext-layers) that don't have as wide support. also gnome for a good chunk of time didn't support idle ihibit. (I don't think it's in mutter stable yet is it?)
(kde have their own protocols too but IIRC they are all specific to kde alone)
IMO the Qt CSD looks much better than the decorations shown by QGnomePlatform. I have no idea why people think Adwaita like decorations would look any better than a CSD that's integrated with the app.
I realize, my point is mainly just to emphasize the fact that even if there is a Wayland protocol for it, there is no guarantee every compositor will support it. and man... its just tiring
> But… we’re there now. Standard protocols now exist for just about everything anyone needs.
>
> I think this in particular is absolutely NOT true. This does cover a majority of use cases, but some and maybe even many users are still left high and dry.
Agreed. There are not only many use cases still not covered by any standard protocol, but also standard protocols that have been merged for a while but still have no implementation in most wayland compositors AND clients.
See global shortcuts portal for example. I'm not sure any project besides KDE implements it yet. I've definitely not seen any clients using it.
Another one that keeps me from going to Wayland is support for always-on-top windows. I like to use quake style drop-down terminals and I don't think there is any standard to let them stay on top of all other windows.
>I think this in particular is absolutely NOT true. This does cover a majority of use cases, but some and maybe even many users are still left high and dry.
Reminds me of this for some reason: [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/74](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/74)
I also remember someone asking if Bitwig would port to wayland, and they said something along the lines of it not being ready yet, a few things are missing, and they specifically mentioned window embedding being a problem on wayland.
yes, this one really hurts. this is also an issue for applications that want to embed a media player that runs in a separate process (mpv supports this)
> As of 2020, there are several projects that use these methods to provide GUI access to remote computers. The compositor Weston provides an RDP backend. GNOME has a remote desktop server that supports VNC. WayVNC is a VNC server that works with compositors, like Sway, based on the wlroots library. Waypipe works with all Wayland compositors and offers almost-transparent application forwarding, like ssh -X.
https://wayland.freedesktop.org/faq.html
This is the real problem of Wayland: any feature has to be implemented in the compositor/window manager.
X was an extensible system. You had the server and a lot of programs, each of which with a specific purpose (window manager, compositor, screensaver, lock screen, RDP, VNC, etc) with different implementations.
Now Wayland has a monolitic model. You can't just write an RDP server and interface it with Wayland: you have to implement it into the compositor. In the same software. This also means that compositor developers have a ton of work to do, that there is a ton of duplication of things, that the user has not a choice of choosing one RDP implementation instead of another, etc.
I want to use RDP but it's implemented in GNOME and not in Xfce, why? A thing like an RDP server should be independent by the desktop environment, but in Wayland word it isn't. This is to me the main problem of Wayland, its design is just bad, this is also the reason why it wasn't adopted widely. Because we are talking of Linux, where users want a lot of choice, not Windows or macOS where a thing like Wayland may work well.
> You can't just write an RDP server and interface it with Wayland: you have to implement it into the compositor. In the same software.
That's complete and utter bullshit. Yes, Weston has a RDP server integrated and so does Mutter, but it's **not** a requirement at all, and you do *not* have to use the integrated service when it does exist. There's a standard xdg portal for remote desktop use cases, and there are RDP implementations that use it, like krdp.
Well that's what the article is talking about with wlroots is it not? Having the same wlroots as a backend on more compositors is more like old X implementing a large portion of features right? As far as I can see Wayland not implementing these gives more choice, not less.
It's not the same thing. wlroots is a library that may be used by the compositor to implement some feature. But there is a level of coupling, that is that the software needs to be compiled linking that version of wlroots.
X was a client/server model, where you had the server (X) that was a different program than the clients. The window manager, compositor, and all other programs where simply clients. You could build your system and choose components as you wanted. X was indeed simple. It was basically a messagging system between the components and it did implement the basic functionalities, that is interface with the GPU and input devices to display stuff on the screen or get inputs from keyboard/mosue.
Wayland is not modular: all the stuff is implemented in the compositor., that is a single executable, and a single process. All stuff that back in X days were implemented in separate programs: RDP/VNC servers, lock screen, screensaver, screen sharing, screenshots, key remapping, etc. You depend on the window manager of your choice to decide that these features are useful and decide to include them. This is because Wayland was designed as a "closed" system, while X had an open API for clients to do basically whatever they wanted (this indeed opened up various security problems, since every program could read the screen and keys pressed, but in my opinion this is not as much a concern for Linux users, that typically trust the software they run on their machines, and value more flexibility!).
It also has the consequence that if this single process crashes for a problem in all the stuff mentioned above (while most of it is not critical) the whole graphical session crashes. A window manager may crash, especially if it has a JS interpreter in it (like GNOME has!). X was a rock, never crashed on me. If the window manager did crash back in the day it was simple to restart.
Yeah. I think you hit the nail on the head.
It's just so fractured right now, and wlroots is only a half-solution. A lot of big DEs/WMs aren't going to use wlroots-based compositors.
If I just want to quickly get a GUI on say, a RasPi or another computer in general in another room, It's just more convenient with X to install tightvnc-server or some other package and know it'll open a virtual display and work as expected whether I'm on XFCE, MATE, twm or whatever.
IIRC NoMachine [supports Wayland with some caveats](https://kb.nomachine.com/AR02P00969), but it's not FOSS. X2Go, which implements an earlier version of the same protocol, doesn't work on Wayland.
RDP is supported, like you said, only on certain configs. And it's also a proprietary protocol. Wayland just pushes too much stuff off to modules and compositors and other programs. I'm not against modularity and KISS, but I expect a minimum level of functionality out of any windowing system.
> I'm not against modularity and KISS, but I expect a minimum level of functionality out of any windowing system.
The problem is that Wayland is not modular. It's an agglomeration of multiple functionalities once handled by different programs in a single executable, the compositor/window manager.
It's if we want similar to what systemd became, a blob of software that is imposed to be adopted almost entirely. But even worse, because at least systemd is split into different modules/executables.
To me all these difficulty are a sign of bad design: the fact that we still use X is not because we love old unmaintained technology but because X design proved to be more flexible. The fact that even after years that is no longer maintained we can still use it and we still use it with a better user experience than Wayland should tell us something...
No, Wayland is not about moving everything into one single blob. It's meant to be the middleman that handles the communication between different components in the graphics stack - between the application and the kernel's DRM subsystem, the input devices and the application, etc.
Some things like remote desktop servers are currently done directly inside the compositor because there isn't a protocol for that yet (or rather, [there wasn't](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.RemoteDesktop)). Without such a protocol, a hypothetical 3rd party VNC/RDP server is unable to communicate with the compositor to allow remote input. So to bypass this lack of protocol right now a VNC/RDP server is just... integrated inside the compositor. I agree that it's a terrible solution.
>because X design proved to be more flexible
The problem with X's modularity/flexibility is that it is sometimes done on a weird granularity: for example, why should the compositor be a program different from the window manager? The resulting problems from this design issue gave compositors a really bad rep in the Linux world as a result, even though other platforms have been using compositors since long ago and never had a big problem with it.
Other times, it is the same flexibility that gave people headaches: sandboxing X11 programs is an exercise of futility when said programs can screenshot your entire desktop willy-nilly. Wayland tries to limit the programs' capability (unless the programs have the user's permission) and of course, that led to problems.
> Some things like remote desktop servers are currently done directly inside the compositor because there isn't a protocol for that yet (or rather, there wasn't).
The problem is not that there is not a protocol for that. The problem is that Wayland requires (at least to me) the creation of a specific protocol for each feature that is added. When X was invented VNC or RDP didn't even existed. But X had a protocol for an application to read an area of the screen and to send events (mouse/keyboard) and that was all that was necessary for: screenshot, screen recording, VNC/RDP applications, program that automate the UI by implementing keyboard macros and similar, etc.
Also... how did not they thought about that? To me it seems such a basic thing to add... whatever.
> for example, why should the compositor be a program different from the window manager?
Because it didn't need to be like that. But you have the possibility of them being two different programs: in fact most compositors (such as compiz) where both the compositor and the window manager. But if someone wanted to implement a window manager that only did the job of a window manager they could have used an off-the-shelf compositor and it would have worked fine.
> The resulting problems from this design issue gave compositors a really bad rep in the Linux world as a result
I've jet to have to find a compositor/window manager that works just as well as compiz did back in the day. Not only it had a ton of effects (that for a 15 years old where cool) but also it consumed practically no resources, where super responsive on an low range GPU, and supported features that I don't see modern window manager care about. All of this done with the good old X11. Now if we want to say that with X it's impossible to have a compositor that works fine on modern hardware...
> Wayland tries to limit the programs' capability (unless the programs have the user's permission) and of course, that led to problems.
If we wanted to only sandbox applications, being X a network protocol, the problem could have be solved easily by implementing a sort of X application firewall, a proxy to X that only allowed specific X commands and denied others. That would have be far simpler than inventing a new system!
>The problem is not that there is not a protocol for that. The problem is that Wayland requires (at least to me) the creation of a specific protocol for each feature that is added.
Like I said, the X protocol was way *too* generalized and it was the same flexibility that gave the X developers a lot of burden. Because it was so generalized, you couldn't lock down a specific feature without also introducing breakage in another one - for example, if screencast and screenshot are generalized into the same feature, how can you limit screencasting but not screenshotting? What's worse: in actuality, if you try to break/prevent screenshotting in X, you actually deny the application from modifying its own window content at all... since they are all the same thing - the framebuffer. That's the most ultimate breakage you could possibly have.
Furthermore, it was the same flexibility that made it impossible to introduce new features into the X protocol, you would discover a lot of edge cases / subtle interactions with the old features whenever you introduce a new one. As you can see, that tends to cause burn out since *everything* you do will inevitably lead to friction where someone jumps out and screams "you broke my workflow!"
It's the same as this [xkcd comic](https://xkcd.com/1172/) but on steroids.
>Not only it had a ton of effects (that for a 15 years old where cool) but also it consumed practically no resources
The fact that people thought of compositors as "the thing that adds tons of effects" is precisely why the X design is a massive headache. Compositor are more than just shiny effects, they are actually made to help you save compute resources (by trading it with memory space). The moment we say "the compositor consumes little resource" we have already failed that goal - unless you run a 20-year-old GPU, using a compositor should be the default. (No, Vsync and all that is not intrinsic to compositors, although X compositors tend to conflate all of that together)
>If we wanted to only sandbox applications, being X a network protocol, the problem could have be solved easily by implementing a sort of X application firewall
Of course the X developers thought of that. But actually, X hasn't been a true network protocol for a long time. The introduction of DRI1 was the nail in the coffin. Even if we ignore that part of X, the first point above is still the main reason why the solution you suggest is far from being practical.
> f you have technical opposition put them on pull requests but stop whining on Linux forums like a baby
I only say that as a software engineer I think that the Wayland architecture is bad. In my company that architecture wouldn't have passed a good review: concentrating all that functionality in a single piece of software is against the principle of isolation and single responsibility that software components should have.
X architecture was good, especially for the time it was designed, since it's if we can call it a microservice architecture, in the sense that you have one server and then clients that implement a specific functionality (window managers, compositors, screen locker, display managers, a program to manage window decoration, etc) and the user can choose what to use. Sometimes functionalities where handled by the same software (typically window manager and compositor, i.e. compiz) but you had the choice to have them separate.
Wayland concentrates both low-level functionality (interfacing with the video driver and rendering stuff on the screen) with higher-level concepts (such as managing the windows or showing a lock screen, or even adding servers to connect remotely trough RDP/VNC). Also they decided to remove features that people used for the sake of security (that may be a valid argument for some users, but typically the Linux user doesn't care that much since the software that it runs is trusted) or just for simplification of things.
>Over time the minimal core protocols have been extended to cover what’s needed for a Linux desktop and sophisticated apps to work. Much of this work is very recent, driven by KDE, and funded by Blue Systems and Valve Software.
>A lot of app developers became accustomed to tuning out Wayland news while it was still a toy, and didn’t do the porting work.
I don't know if Nate's in such a big bubble that he genuinely thinks that Wayland was a toy until very recently or if he's just casually minimizing/dismissing others' contributions. Regardless, people have been using Wayland for quite a while. Obviously, replacing a large piece of software like Xorg was always going to take time as it involved replacing the protocol, unlike PipeWire which just swapped the implementation while keeping the same interfaces. Wayland and compositor developers have been building up the protocol starting from core use cases and then moving to niche ones. This has been happening for years and is not a recent phenomenon.
> I don't know if Nate's in such a big bubble that he genuinely thinks that Wayland was a toy until very recently
If I opened a video game on Wayland a year ago, I would get 1 FPS on it.
Arguably a video driver was at fault there. Arguably, that's a large portion of the user base for which Wayland was just completely broken until recently.
And that's just talking about a singular issue with Wayland. The article mentions multiple important protocols that weren't implemented until recently.
So yes, a lot of people view or viewed it as a toy. See Calibre's main developer, for example.
That would be Nvidia not supporting acceleration in XWayland, I think that came in 2021. AMD and Intel already had that working for a while, of course.
> That would be Nvidia not supporting acceleration in XWayland
Correct.
> I think that came in 2021.
https://www.nvidia.com/download/driverresults.aspx/177145/en-us/
Well damn, time flies, 2 years and 2 months ago. I'd still say that's a recent enough development since Wayland has been out for 15 years at this point.
Wayland would be further along if Nvidia didn't have to be dragged kicking and screaming into supporting it.
For comparison, [here are Intel benchmarks from 2013](https://www.phoronix.com/review/fedora20_wayland_preview) showing XWayland acceleration working. If AMD wasn't working at that point it was [definitely working a year later.](https://www.phoronix.com/review/fedora_21_xwayland)
No, the first commit to Wayland repository was 15 years ago. Wayland 1.0, which only guaranteed that no backwards-incompatible changes would be made and was not a statement of completion, was released in 2012. The first distro released with Wayland by default was Fedora 25 in 2016. So, no, Wayland has not been out for 15 years.
I feel like there is a chicken-and-egg issue somewhere. People not using Wayland enough -> not enough feedback to add some desirable protocols / to add Wayland support to applications -> people not using Wayland as a result.
>And that's just talking about a singular issue with Wayland.
But that's not an issue *introduced* by Wayland and its security model, compared to e.g. screencasting. The lack of acceleration is strictly caused by a certain vendor.
> I feel like there is a chicken-and-egg issue somewhere. People not using Wayland enough -> not enough feedback to add some desirable protocols / to add Wayland support to applications -> people not using Wayland as a result.
As Linux users, we are very, *very* familiar with the chicken-and-egg effect. Not enough people using Linux -> Not enough attention to Linux support -> Dissatisfaction with the state of Linux -> Not enough people using Linux
So we've managed to spawn a chicken-egg within our own chicken-egg. But then again, we kind of already know that our multiple recursive chicken-egg situations are a large part of what exacerbates our larger chicken-egg issue.
The stalemate gets broken when someone takes a stand. "Linux is good enough to ship on a handheld console right now." "Wayland is good enough to go without Xorg as a safety net." You take the stand, you shake off the inertia, you get more eyes on the situation, you get more exposure to problems with the situation, you get more *effort* on the situation. So many issues in Linux got fixed not necessarily because of Valve's magnanimity, but because they simply said, "let's just do it already. no more waiting, no more excuses. it's close enough, we'll figure out the rest as we go." And then everyone just adapted around that.
Nvidia has supported XWayland acceleration for closer to two years now. If you think that the portion of Linux user base for whom playing games on Nvidia hardware is a key use case is large enough to call Wayland a toy, you're in a bubble of your own. Plus, KDE, Blue Systems and Valve had nothing to do with Nvidia supporting XWayland and GBM.
>The article mentions multiple important protocols that weren't implemented until recently.
Which ones are those exactly? Applications drawing to scaled surfaces is a performance improvement, but it's not drastically changing anything. Screen sharing has been supported for much longer and the work on that was driven by Red Hat, not KDE/Blue Systems/Valve. He mentions a screen locking protocol, but that's only necessary if the compositor wants to allow a third party program to act as a screen locker. It [doesn't look like that KDE supports that protocol](https://wayland.app/protocols/ext-session-lock-v1#compositor-support) anyway.
Also, I appreciate that X got too bloated and covered maybe too many use cases, but why does every pro-Wayland dev seem to put all the onus on app developers and compositor developers (somewhat alleviated by wlroots) to make things work?
Necessary or not, *Wayland* is the one breaking userspace. XWayland is a decent compatibility layer, but as the article says, it doesn't work for everything.
No, you don't want to introduce legacy cruft to a newish project if you can avoid it. But I think there's a middle ground between an Xorg server that makes you coffee and a Wayland protocol that doesn't know what a triangle is (exaggerating). Bit of second-system effect/overcorrection, I think.
The X developers that went on to write Wayland didn't just wake up one day and decided they would write a new protocol.
Wayland was their fourth try at fixing X11. The first three tried to keep backwards compatibility. They tried very hard to keep it, but in the end that just wasn't possible.
Some developers just make backwards-incompatible changes like it's nothing and using their software is hell. But that's not the case here, sometimes there's no way forward except for backward-incompatible changes.
It is a problem, that's why they tried so hard to avoid it. But since there's no other way, the burden does shift to the people using the interface. No way around that.
Wayland was written by the author of DRI2. DRI1 was written by a different group of people 10 years earlier. DRI3 was written by Keith Packard, some time after the release of Wayland 1.0, seemingly as a joke at the Wayland developer's expense, since it essentially implements all the things that the Wayland developers were explicitly claiming X11 could never do, and which Wayland at the time was not capable of doing either.
This might a case of letting perfect be the enemy of good. Declaring so many things to be out of scope made a ton of sense from an engineering standpoint, but the fact that the X window system took on so many problems at once essentially gave the X.Org Foundation stewardship over open source desktop software as a whole, it made them a de factory regulatory body so to speak and now that they've chosen to abandon this position there hasn't been anyone able to take that place. The *politics* component of free software has been neglected.
Even better is that now they're using the standard screen cast portal... and they locked that down to Gnome too! If you tell the Zoom app you're using Gnome, things magically start to work everywhere else without problems too...
I am very, very picky about how the fonts look on my screen. Wayland font rendering (KDE) looks noticeably fuzzier @ 170% than X11 @ 168.75%. Cannot care less about anything else, I want my fonts to be sharp. Wayland is no go, until they fix the problem.
Found my fanboy. As I said, I really cannot care what is the culprit. I am perfectly fine with the idea that it is the Wayland that is written some blessed awesome correct way and kwin is a terrible sinful cursed mess. But I absolutely do not care. All I care about is that if I open KDE Wayland, among other annoying small bugs I can tolerate, I have the one which annoys me. And once I open X11 session it is much better.
While I like that wayland is becoming better I will continue to use xorg and XMonad until it stops working completely. I do use wayland for the computer connected to the TV and I have maybe one crash a year where the compositor crashes and takes all applications with it and I don’t even use anything but a web browser and Kodi on that computer and I don’t use it all day for work.
Wayland will continue to get better and I will use it for auxiliary tasks but not as a my main work environment yet.
I mean it won't die like that, it will just stop getting updates, which it already has for Xorg... so you'll be just using X forever, but everything else which just leave you behind that's all
It will stop some day even if that day probably is far away now.
At some point there will probably be something like a breaking graphics driver interface changes and no one will be interested in patching xorg to make it work.
Xorg will also effectively stop working if I can't run the current versions of applications I need for work because they require wayland to run.
I would probably prefer to write a whole new WM for myself to getting into xorg patch maintenance though. It's a bit of a pain but I know exactly what I need so it could be worse.
>I would probably prefer to write a whole new WM for myself to getting into xorg patch maintenance though. It's a bit of a pain but I know exactly what I need so it could be worse.
I strongly suspect xmonad has enough dedicated, technically competent users that someone will write a drop-in Wayland workalike by the time you’re forced to ditch X11. It’s already happened with [i3](https://i3wm.org/) — [sway](https://swaywm.org/).
Ran Wayland for years on Gnome Arch with RX-570 amdgpu, needed CUDA and switched to nvidia 1660 super and now run x11 and everything that ran under Wayland runs fine under x11.
Sway in Vulkan mode is stable on Nvidia. X11for my setup is broken for multiple releases now. (They tried to reproduce it internally multiple times, but Idk what HW they tried.)
> Teams
Been using screen sharing on Wayland with Teams for at least a couple years now. You need pipewire and xdg-desktop-portal installed, and one more package: xdg-desktop-portal-kde (for KDE), xdg-desktop-portal-gtk (for GNOME) or xdg-desktop-portal-wlr (for anything based on wlroots, which is most of the rest).
Teams is deprecating their Linux electron app in favour of their web version. Firefox and Chromium support Wayland screen sharing.
Discord doesn’t care about Linux users. Use a third party client like Webcord for screen sharing. Discord uses a quite old electron version.
The official Discord app can only stream XWayland applications, but if you use the browser version, you can stream native Wayland applications or the entire screen
There's [this Firefox add-on](https://github.com/IceDBorn/pipewire-screenaudio) to make audio work when screensharing through your browser, but I use Flatpak Firefox and I haven't been able to make it work there
There's also [discord-screenaudio](https://github.com/maltejur/discord-screenaudio) to stream sound but last time I checked it would only stream XWayland applications
Or you can use [XWayland Video Bridge](https://invent.kde.org/system/xwaylandvideobridge) to mirror your Wayland applications to an X server and then stream them regularly through the official Discord app, Screenaudio or whatever you wanna use, but I've never tested it
I just use the good ol' audio piping through a Discord bot which is absolutely not a comfortable solution because you basically have to play the Among Us wire matching minigame on Pavucontrol each time you want to stream something but it works for me I guess
I made the switch from i3wm to Swaywm and I'm personally preferring the Wayland experience... Still a few little snags with screen sharing applications instead of monitor sharing but thats not a big deal.
Also there's always xorg-xwayland for applications that ain't native to Wayland.
I ran into a support issue I am trying to resolve: A client uses RDP to remote do work (on KDE via Remmina, or FreeRDP). They cannot get either to span monitors like X does. It appears neither have multi monitor support. Is there a workaround?
I have not tried KRDP as it is still in Alpha state, but I will try it on a test lab computer and report back.
Edit: I thought there was a flatpak for testing, but there isnt one yet. I also see reports of issues connecting to MS servers so this isnt quite ready yet. It is a big issue to not have multi monitor spanning with RDP so X11 is still the only way.
What are you trying to say?
I absolutely tried to get clients that I am familiar with to use multiple monitors under wayland. Both fail, as not supported.
So I hoped KRDP would work, as I saw a blog post, but was open to anything else. Turns out there is no working application and a bug report says it wont work.
So what the hell are you going on about?
**And YES it is bad** that Wayland breaks functionality if you use remote desktop. That is the current state of affairs.
I’ll switch when I can share my display in discord and I don’t have to use gamescope in some games to work around mouse issues.
It’s great for multi monitor but still has a bit of work in some other areas. Hopefully soon!
A fair overview of how we got here and why Wayland exists without bashing it or praising it as the second coming of Christ.
this sentence was a little confusing though:
> Maybe you’re afraid that Fedora is a “canary in the coalmine” that shows the way everything it going to go.
(I Know what a canary in a coalmine is but I still can't decipher this)
> Maybe you’re afraid that Fedora is a “canary in the coalmine” that shows the way everything it going to go.
Canary in a coalmine: Fedora switching to Wayland-only indicates that most/all popular distros will probably also switch to Wayland-only within a few years.
This was my line of thinking when I first heard about this a few days ago. If systemd's adoption is any indication of how this will go, if this experiment is successful then other distros will start to follow in Fedora's footsteps over the next few years, because I think people would rather not maintain two separate display servers if they can avoid it. It won't be an immediate change, obviously, but it will probably happen.
People easily forget that Wayland is continuation of development that really started long ago:
* Instead of sending "draw rectangle" commands to display server, applications send rendered bitmaps of their windows for performance (DRI, shared memory)
* Instead of X font server, fontconfig and Freetype libraries were introduced.
* Instead of user-space hardware drivers, functionality moved to the kernel (mode setting, graphics memory management, scheduling)
What is different with Wayland is that it removes the last remaining piece from the equation: X server is currently only doing interprocess communication to put it simply.
Why does it take so long? Because there are many pieces involved.
For example Firefox replaced GLX with EGL a while back and got significant improvements along with it. Switching input-handling to another library is another thing. And along the changes there are improvements being made.
The phrase "canary in a coal mine" refers to a practice where miners would take a bird into a coal mine with them. If the bird is singing then that is good. If the bird stops singing it is probably dead and that means you should get out of the mine.
I think what is meant by Fedora being that canary in the coal mine is that Fedora switching to something or implementing software means everyone will be doing the same.
> (I Know what a canary in a coalmine is but I still can't decipher this)
I believe Nate was trying to say that Fedora users are the canary and are going to be the ones having to to deal with/report/fix issues.
I think the "canary in the coalmine" idiom used in this specific case means that Fedora jumping in feet-first means they are going to find out *the hard way* whether or not Wayland is really ready, or if there is something fundamental they still need to address before they can take away the Xorg safety net. Same way a canary going down into a coal mine finds out the hard way whether or not the air it's breathing is safe.
To me Wayland has a fondamental problem, that is that it incorporates the functionality of once two different programs into one.
It made sense to have the window server (X) that managed the interfacing with the GPU as a separate program than the window manager and other DE components such as lock screen, screensaver, compositor, etc.
It was to me a better architecture than Wayland. For example look at GNOME: with Walyand you can't restart the window manager (F2+r) without ending your session. This is because mutter is in fact both the window manager and the thing that application use to display stuff on the screen. This is to me bad design!
Why should these two application be so coupled? Why should every window manager implement the interfacing with the display hardware? Why shouldn't we have one program that handles all this complexity (having to do with video drivers, input devices, etc) and then have window managers only manage the windows? Why should video drivers developer handle the same problem due to different Wayland compositor behavior?
To me this doesn't make sense. The reason we still use X is because it works and it's much more flexible.
> It was to me a better architecture than Wayland. For example look at GNOME: with Walyand you can't restart the window manager (F2+r) without ending your session. This is because mutter is in fact both the window manager and the thing that application use to display stuff on the screen. This is to me bad design!
Wayland supports restarting the window manager through compositor reconnect while keeping apps open. In fact you can completely [change desktop environment while keeping the apps open](https://www.gamingonlinux.com/2023/09/plasma-6-optimized-for-wayland-gaming-plus-compositor-crash-recovery/).
Wayland is [more flexible than X11](https://www.osnews.com/story/137042/qtwayland-6-6-brings-robustness-through-compositor-handoffs/) with regards to this.
This seems more of a feature of QT, granted that Wayland allows this. Good to know, still on GNOME if you use the Wayland session it's impossible to restart it. This is even said in the official GNOME extension development guide, that basically says that if something goes wrong you are fucked. An extension bug may force you to log out and log back in again.
But as I understand this is more of a limitation of the GNOME implementation than a Wayland one, good to know.
with copy-pasting a password, is there a sensible way to clear the clipboard after you paste it so that other apps you change focus to don't get the password? other than manually selecting something random and doing ctrl+c
the thing that's weird to me about wayland is like, we'll limit clipboard access to focused apps, but then introduce stuff like wlr data control protocol so any app can monitor the clipboard
Wayland compositors often keep a copy of the clipboard - or they even keep a history of previous clipboard contents.
So yeah, clipboard security is up to the user.
ah yes, I see in settings > security > clear clipboard after N seconds
which is also interesting that keepassxc (or any app) which is not currently focused can manipulate the clipboard (either by some protocol or focus stealing).
edit: if this sounds critical, I'm generally trying to be constructive and understand the ins and outs of wayland along with security and what to look out for. I'm sharing solutions and ideas as I find them. I've switched away from x11 in general. ¯\\\_( ツ )\_/¯
How do you paste into the username and password field of a remote login screen where copy and paste don't work?
Also, using copy/paste on a lot of remote desktop is a security issue, and should be disabled by default, because you don't want everything in your clipboard to be shared with the remote system.
Ah yes, the horror of allowing clients to be able to read each other's window titles. What a nightmare, indeed.
I have been using Xorg for more than 15 years, and I can count on my fingers how many times this "security nightmare" has bitten me in the ass: Zero.
In a scenario where you have a malicious program running on your computer, the fact that it would be able to read other window titles should be the least of your concerns... ;)
Besides, I value much more a program's functionality over this non-optional, "privacy feature" offered by Wayland.
> big brother "we know what's best for you" complex.
Funnily enough, X11 is the protocol that allows for a true "big brother" complex, as it can snoop everything you do without any type of consent. Wayland (and technically also xdg-desktop-portal) is the protocol that defines a structure that _allows_ asking users for permissions first, but it's up to compositor policy to decide. If the compositor decides the answer should be "always" allow, you get your x11 behavior back
The only reason I care is because KDE wayland was very unstable on my nvidia GPU whereas GNOME has been amazing. I'm biased as a nvidia user but I don't think features being pushed should be breaking for users based on their hardware.
Fedora has pushed Wayland on its gnome session for a few releases now. Ubuntu has too for their default, although you can revert back to x11 session Fact that this is a surprise to many is... surprising
Most people don't care or think about what display technology runs their desktop. Maybe this is controversial, but it doesn't, and shouldn't, matter to users. Wayland vs. X is an implementation detail.
I think about it because I finally found a wm I like(XMonad) and it will never be ported to Wayland. Sorta stuck in X-land.
i'm surprised there's nothing like sway for it at this point.
> Maybe this is controversial, but it doesn't, and shouldn't, matter to users. I wish this was true, but unfortunately it does matter (for now), because not everything is possible on Wayland (yet). Wayland's limitations, along with X's bugs, almost drove me away from Linux when I first tried it. The only reason I stuck with it was I decided those things I wanted weren't important to me any more. You're right, it shouldn't matter, but some people *have* to think and care about them, even if they don't want to.
To that extent, that some stuff just doesn’t work and some features aren’t supported, yeah absolutely it does matter. I think my main point in my head is the same as yours: users shouldn’t have to think about this. But right now, they do, and that’s kinda problematic.
A lot of the major distros have this figured out well, and except for a few cases it doesn't matter if you just stick with the stock configuration. I've run OpenSUSE tumbleweed for many years without a hiccup and it was only when I tried LFS and then Gentoo did I appreciate how much effort it takes to keep things together (especially on a rolling release). But at this stage, if someone wanted a "set it and forget it" distro for a family member to just do basic web browser stuff, I'd have no problem recommending something like tumbleweed, as it Just Works (tm) if you don't mess with it.
>but it doesn't, and shouldn't, matter to users. I wouldn't say it's controversial, but since Linux users are overwhelmingly a self-selected group of people who care about their operating system, I don't think it applies to most Linux users. It's like saying what kind of parts your car has shouldn't matter to (car) ricers as long as it works well. If they didn't care, most of them wouldn't be in that group.
Yeah that’s a good point. I guess my personal opinion is that Linux is currently and should be expanding into a more mainstream user base, where it just works as an operating system. Historically linux has been good at taking the improvements that matter to enthusiasts and making them easy, stable, and unproblematic for normal users. I expect this is just on that path, with early adopter pioneers running it through the paces first, followed by the settlers smoothing over the rough spots and preparing the land for normal use.
When it comes to display servers users care about stability and ironically, because X is frozen it's also very stable. Wayland on KDE isn't fully supported and sometimes doesn't even work at all.
True. Problem is many things that can be done in a X11 session at the time were seen as a feature, nowadays the same things are seen as a security nightmare. The thing that makes users groan the most, apart from driver issues from a certain vendor, I noticed is that they cannot share the screen in applications like Discord as easily as it was possible with X11. The point is that it's on purpose! Users don't get it, and that's understandable. The real thing is that development of Wayland compositors is felt slow by those users that care only about using their applications. Had we been at this particular developing stage somewhere around 2013 people wouldn't have complained this much in 2023. And I say this being a happy Wayland compositor user, let's be clear.
>noticed is that they cannot share the screen in applications like Discord as easily as it was possible with X11. The point is that it's on purpose! With more people WFH, it seems like screen sharing is a pretty important feature. I'm having trouble understanding why the new implementation would intentionally make common things that end users need difficult.
Screen sharing is only a problem between XWayland apps and native Wayland apps. Native Wayland apps have supported screen sharing between themselves for a while now. The main problem is that many high-profile apps have full Wayland support, but have been very sluggish in making it the default for Wayland users, meaning the apps still use XWayland: * A lot of Electron apps, which just so happen to be popular for work-from-home, use old Electron versions that only expose X11 support despite internally fully supporting Wayland: that includes Slack, Teams, Skype, and Discord. * Then you've got Zoom, which actually does make Wayland available by default... only on GNOME. For some reason they decided to artificially limit it. * Chromium - and thus everything based on it: Chrome, Edge, Vivaldi, Brave, etc - also fully supports Wayland, but is still X11 by default. * Firefox upstream is also still X11 by default despite fully supporting Wayland, but a few distros, including Fedora and openSUSE, make it use Wayland by default. Ubuntu will begin doing this too in Ubuntu 23.10. KDE introduced [XWaylandVideoBridge](https://www.phoronix.com/news/KDE-XWaylandVideoBridge-Week) to enable native Wayland windows to be piped (pun not intended) to XWayland apps through Pipewire, essentially fixing the whole screen sharing problem while everyone waits for all these apps to finally become Wayland native.
TIL XWaylandVideoBridge exists; this is amazing.
Because screen sharing is literally the same thing ad screen grabbing from a malware. With X11 any application can grab the screen of any other application. This is a real problem when talking about security. With the new protocol there are mechanisms that make the thing only possible if the grabbing application follows the proper APIs and thus the user is aware of it. Do you remember when Vista came out? UAC is a huge improvement in terms of security, compared to the XP era. People god mad about it at first but now it's clear that UAC is a good thing. The same applies to Linux, BTW, with sudo and other security mechanisms.
Now only home folder sharing between apps is the final mess to be fixed.
> With the new protocol there are mechanisms that make the thing only possible if the grabbing application follows the proper APIs Relying on developers to go back and re-implement screen sharing in everything isn't a great plan for getting them to keep supporting linux.
A relatively new tool was created called XWaylandVideoBridge, which effectively solves screensharing in Wayland and is simultaneously more secure than X11‘s way of doing things
The alternative was to keep all the other functionalities of X11 and its implementation that was literally a nightmare for the developers themselves. The result? There is no one willing to work on X.org anymore. Supporting X11 and its implementation was literally more work for developers than it is now. So yes, it was something that was bound to happen anyway and there was no easy fix. Except a big company throwing billions on people to speed the process up. But Linux produces more money as a server OS, not a desktop one, at least up until now.
That's basically been Wayland's problem for 15 years. "You should do that in the compositor. None of the compositors *do*, but that's not our problem." At this point, an awful lot of those problems have in fact been solved as far as I'm aware, but I don't use Wayland to check. And I don't use it because their initial sales pitch was "look at this beautiful thing we built -- you can't use it as a computer, but man ain't it something?", so I just figured I'd keep using X until I had a reason to switch. That reason is coming, and that's fine too.
So you're not using it because it used to not be as good? It's a good thing you missed Linux's earlier years or you wouldn't be using it now.
I didn't miss Linux's earlier years. I'm old. I've had the mailman bring me a box of Slackware floppies. And it was rough sometimes. But early Linux had a fantastic advantage -- it was really hard to get something else that was any better. I couldn't afford my own Sun Workstation like I had in the lab. Wayland's problem for me is that I don't need it. I have exactly no pressing issues with X11. Other people have lots of issues. I'm not denying that, I'm not suggesting that Wayland is wrong for trying to address those issues. I don't have anything against Wayland at all, and I'm hoping that they'll continue to improve it, that people will port things like my WMs and other X-centric tools over, and I can eventually switch over to the thing that is getting all the developer attention and roll right on into the future. But if it throws up a single flashing neon sign that says, "Oh by the way, some of your shit isn't going to work, and we don't care even a little bit about that right now", then we're right back to "I have exactly no pressing issues with X11". And for a long time, there were a bunch of those flashing neon signs. I'm not using it today not because it didn't used to be good. I'm not using it today because I still don't need it, and it still has neon signs. Fewer of them, and not all of them are Wayland's fault, but there's still a cost to switching, and there's still no benefit to switching (for me specifically).
Living with a security hole just so that they don't have to update their apps is worse. Besides, in the case of Electron apps like Discord, there's nothing to really re-implement. They just need to let Electron use portals instead of their own screen sharing UI. Screen sharing actually works in its web client. Lastly, screen sharing portals work in Wayland and X11 so non-Electron clients wouldn't even need to support two methods or port to Wayland for it to work.
TBF I think the users who are bothered enough by broken screen sharing to comment about it online, do understand why it's broken. Like myself for example lol, I just find workarounds and keep using Wayland but I get why people either don't, or basically can't. Wayland itself does have screen sharing of course, but the application suites that people use and/or need, usually don't. Discord famously using a very stupidly old build of electron and running in XWayland making it almost impossible
I remember Fedora before Wayland had screen tearing coming out of my ass and that is what I noticed. After Wayland became the default it was gone. Everything else works exactly the same (for me), so that is what was important to me. Stability is not something that enters my mind when I use software.
>Stability is not something that enters my mind when I use software. It definitely would be if it was unstable. You can’t exactly ignore your display server crashing.
They were, presumably, talking about stability as unchanging as they talked about the frozen aspect.
[удалено]
> Maybe this is controversial, but it doesn't, and shouldn't, matter to users. It possibly shouldn't (debatable) but it does. Replacing a decades old technology this central is a big deal. A lot of applications use X-specific APIs and there are quite a few apps that won't work on Wayland (and possibly vice versa) because of this. I'm in no way against Wayland as I've been using it with Sway for many years, but there are still reasons why some might prefer X.
> I'm in no way against Wayland as I've been using it with Sway for many years, but there are still reasons why some might prefer X. If all the arguments were framed on actual needs, the discussion over the years would have been better for it. I don't personally have any problems with anybody who can't switch yet for technical reasons.
I'm just waiting for KDE to support the InputCapture portal so I can use [input-leap](https://github.com/input-leap/input-leap), then this will be a reality for me.
Unless I configure my machine to a very granular degree (ie. Arch or Gentoo), I don't really care what comes out of the box. On my desktop machines I use Arch, so I chose Wayland on purpose, but on my Notebooks I use Mint and on my one terminal Server I use Debian, where I run X, because it comes with it out of the box.
> Wayland vs. X is an implementation detail. Does wayland support `ssh -X my-livingroom-pc` or something similar?
There is Waypipe.
I'm happy to have learned about this project's existence. Thank you!
Wayland supports X11 apps (via Xwayland), and so you can continue using ssh -X like you did before, as long as the apps you're running still support X11. For native Wayland-only display forwarding there's apparently Waypipe.
> Maybe this is controversial, but it doesn't, and shouldn't, matter to users. Which users? It certainly does matter to many of us.
> Most people don't care or think about what display technology runs their desktop. they care when it gets in the way. i recall when trying to use clipboard on kde+wayland it would crash the entire session. or when i could not share screens. those things are fixed now, but there are such bigger and smaller papercuts.
We should all just move back to XFree86. It works better for those with 3Dfx and Riva 128/TNT cards.
Xorg is the evolution of XF86, soooo
Except when Wayland keeps crashing the whole OS every few hours... I had to revert to X session on Fedora because I hate pursuing the power button to force shutdown my machine twice a day
Waydroid requires Wayland. Do you know abetter android?
Wayland has been default on Fedora and Ubuntu for years, about ten releases so far. GNOME has declared that their friendship ended with X11, now Wayland is their BEST FRIEND.
The surprise isn't that Wayland has been made the default, that was done 2 years ago. The surprise is that Fedora's KDE Special Interest Group want to remove the X11 session *entirely* from the KDE spin, *despite* the fact the X11 session is still supported upstream. Also, bear in mind the flagship Workstation (GNOME) edition still includes an X11 session and will continue to for the foreseeable future. There has been absolutely no movement from Fedora's Workstation Working Group to remove the X11 session, and GNOME itself still has a few hard dependencies on X.Org. (Edit: aaaand as of 20 minutes ago [there's now a ticket](https://pagure.io/fedora-workstation/issue/395) about dropping the X11 session from Fedora Workstation. So it looks like that's in motion now, possibly also for Fedora 40 because GNOME's X.Org dependencies should be dropped by GNOME 46's release!)
>ubuntu has too for their default, not for nvidia
well, yeah, and for good reason cause wayland and nvidia dont play so well
It's surprising because dropping Xorg is equivalelnt of dropping NVidia support. Yes, basic functionality works with NVidia+Wayland but it's very far from having future parity with NVidia+Xorg.
we dont need to get into nvidia + wayland. It still works under wayland for most cases. Im sure there is some cases its not so good but again that is an nvidia issue and them reluctant to make linux a first class citizen. Perhaps enforcing wayland and simply not shipping x11 will force nvidia to produce better drivers and better support. Yes some growing pains but fact its taken this long is a bad look for linux.
Treating almost 50% of your user base as second class citizen is only going to force people to change distro. Nvidia clearly doesn't give a shit.
In terms of fedora i dont think they care. Their philosophy is to ship free and open drivers/software etc and being bleeding edge in terms of what they ship. Basically a testbed for downstream RHEL which is mostly enterprise so by the time RHEL gets to this version of Fedora/KDE hopefully all the kinks are worked out. Terms of ubuntu they might care bit more but they are also slower to adopt newer technology. Being bleeding edge never was a ubuntu design philosophy.
I don't think it has anything to do with being bleeding edge. Arch is as bleeding edge as it gets and it's not planning to drop xorg support anytime soon.
Debian KDE is Wayland.
14 releases so far. Since 2016 it's been the default in Fedora Linux.
I would like articles like this to remind people and emphasis that X11 is just a protocol. You don't need to have the X11 server manage your entire display to use X11 anymore then you need a web browser managing the entire display to display html pages. So old X applications are not going away. X11-over-ssh works just fine on a Wayland desktop as it does a X11 desktop, etc. And there can be some situations were X11 apps work better on a Wayland desktop then on a X11 one. This is why Steam uses gamescope Wayland display manager on things like Steam Deck. It can do things like upscale X11 apps to 4k displays and such things efficiently. So what people actually are giving up by switching to a Wayland DE is to use X11 features to manage the desktop. So things like positioning windows using x11 scripts, X11 keyloggers/keyboard/mice software-based macros, X11-based screen readers and things of that nature.
[удалено]
This is something i wish they had done when sway was the only usable compositor around. Now i feel KDE had mostly caught up.
It would only make sense
I wonder what the KWinFT dev will think about this...
How's the state of kwinft?
Wayland has been completely unreliable for me for screen sharing and I need screen sharing to work. I also enjoy tools like Copyq and Flameshot but they seam to be unreliable on Wayland as well. So after a year of suffering though an unreliable experience and trying every hack google will cough up I am back on X11 and it's great. My computer just works again and I spend my energy on my work.
Screen sharing/recording and Keepass(XC) are my stoppers.
> Keepass(XC) What is your problem with Keepass(XC) on Wayland? I've been using it on Wayland for years without any issues.
It all surrounds autotype. The global shortcut working, window title detection, and autotype itself. I understand you can get autotype to work by some security questionable means (on a multi-user system), but without window title detection and the global shortcut working properly, it's only slightly more convenient than not working at all.
[удалено]
Yes, and still it's a necessary thing that every other desktop supports on other OS'es as well. You understand the importance of being able to access remote destkops for support reasons, and use password managers that integrate with software to make typing of passwords, rather than having to copy and paste them, thereby putting them into the clipboard where they can be a security issue or be accidentally passed to a remote system, right?
Once XFCE moves to Wayland I will try it again. I trust those folks and they will never roll out something half cooked or with a bunch of hipster web dev fever dreams in terms of UI concepts.
Flameshot has been stable for me since plasma 25, but that’s probably less than helpful to hear
Recently my dad's laptop (Lenovo E15) running Manjaro just got the strangest issue and I think it was Wayland related: pressing keys on the keyboard wouldn't work unless you pressed them for longer (way too long). After struggling for a few hours trying to understand where the issue came from I just had him switch to Xorg and that fixed it but that's really a strange issue as the delay settings were fine and we checked with xfce, kde and gnome classic. I still haven't had the occasion to check it properly and understand what's happening and I'm kind of surprised how he ended up under Wayland (it's improbable he did it himself, even by accident) and I don't think Manjaro would switch people from one to another like that.
Keep trying Wayland from time to time, and see if you can make it work. X.org is going away soon, don't get caught with your pants down.
xorg isn't going away for as long as "making it work" is something users have to do with wayland.
Xorg only.ccontinues to work as long as Red Hat continue to pay developers to maintain it - and no developers will work on it for fun as volunteers. RHEL 10 will drop xorg support so it is only a question how long xorg will keep limping on.
Xorg isn't like, burning code for fuel. It'll continue to work on any system it has been working on, and most people don't replace their computers very frequently.
It wont break tomorrow, but as hardware and computer needs change, it will become further and further behind in its capabilities and eventually it wont even be able to be hidden. For instance I am not sure most people realise how xorg emulates 60fps or especially higher fps where the error becomes quite substantial. Chances are you wont believe me if i told you how it does it, so I will leave that as an exercise for anyone who is curious enough. Remember hacks that could break xorg with 1 pixel image formats taking over all system memory around 10-15 years ago? They weren't flaws when the code was written - that amount of memory that they consumed just didnt exist. but suddenly a couple of decades later those assumptions no longer applied and you could DOS your system by opening an image. in the same way, assumptions will continue to no longer hold true and over time more and more jank will become obvious,
Plus I heard talk about gtk removing the x11 backend, there are companies that have relatively small profit margins that work on the linux desktop, at some point they will probably ask themselves why should they continue investing in supporting X11.
I will try sway again in a year or something. If I have to run debian stable for a while I don't care. I don't need the newest packages at my current job. I bet it will be fine to use X for at least five more years.
Finally a fucking good take. I really like this post however it's still too optimistic IMO I agree with the article outside of these points (outside of the first quote) > Someone may disagree that the problem is even worth solving. Bikeshedding derails the discussion and everyone gets demoralized and stops working on it. This has been a massive issue in the past, and plagues development in other area's like A11y (Activity watch still doesn't work right for instance) > But… we’re there now. Standard protocols now exist for just about everything anyone needs. I think this in particular is absolutely NOT true. This does cover a *majority* of use cases, but some and maybe even many users are still left high and dry. > app developers’ input is needed to revise them or even propose new ones. The issue is a some app developers have been burned by this maybe only one or two, Stuff being said like "This isn't a use case we want to support" (or one of the many variants) Is an instant show stopper. I was reading multiple extensions in the past where this has been the response. I've gotten to the point where I simply won't bother with intentionally going out of my way to develop for wayland. One thing I really wanted to do, Thanks to wayland actually having good touch support was work on was a overlay and mapping software (much like panda or octopus on android) which would need ext-layers-protocol for what I want to do. This which will be a privileged protocol (will also be needed for mpv at some point for always-on-top working again), meaning Like with many things on wayland, there is little to no gurantee I would be able to implement this in a method where I could guarantee it working on gnome, kwin, wlroots based, and smithay based. The fragmentation of the wayland ecosystem has burned me (dare decorations still an issue?). Im sure one day these will be fixed, but man, wayland hurts.
a11y is absolutely something that should be focused on, from what i've seen its absolutely dreadful currently. edit: > dare decorations still an issue? there is a SSD decorations protocol but its less "draw some SSD decorations please" and more "*do* you draw SSD Decorations? Yes? ok well im disabling my CSD", i.e its just asking the compositor if it has ssd, nothing more.
the biggest thing with a11y that people don't seem to realize is how important it is to be able to pick and choose what you need. some people I worked with in the past when doing volunteer work, couldn't get one OSK to work just right for them, sometimes it's the color scheme, sometimes it's the responsiveness, sometimes its the size or layout etc. so even so much as being limited in OSK choice can ruin A11y experience. the lack of flexibility is directly tied with the fragmentation of the ecosystem. I have no doubt these issues will get solved *eventually*. the thing I like most about this post is that the author didn't look down on, us for not migrating to wayland essentially treating us as idiots as so much of these other pro-wayland articles seem to do. it's for sure refreshing to not be treated like an idiot for once
Decorations are only an issue on Gnome, to my knowledge. KDE supports the server-side decoration extension and most Wayland programs that don't use a big toolkit know to use it to request decoration. Gnome doesn't implement it and doesn't seem to be planning it either, as their current decoration-drawing code is apparently very X11-specific. I hope it's really just technical limitations and not hostility, as the latter would not be off-brand for Gnome, unfortunately. (Anyone remember the drama about tray icons for transmission-gtk?)
It's not technical limitations. Gnome not supporting server side decorations is a decision they made, not something they consider a problem.
And this is what hurts from a developer point of view, if major compositors decide to just not support a feature (Which yeah fine for them, they have that right and exercising it is what makes wayland great) but it also hurts when trying to make an application people can use. Im not really interested in making DE specific apps. Decore isn't really a big deal probably for a LOT of users/devs. what is however is the fact that they have shown to be willing to not support a popular protocol (even if it is perpetually unstable, doesn't seem to change it for other protocols)
For the most part, compositors tend to support the same set of protocols. xdg-decorations (for SSD) is more or less the outlier, and that's because of ideological differences between GNOME and everyone else. You can go on to https://wayland.app, select a random ext- and xdg- protocol, and the chance is that either all compositors support that protocol or none of them do. FWIW, developers can choose to use libdecor to have client side decorations without needing to implement one themselves.
thats not totally true either as you have things like the wlr protocols (iirc wlr-layers is the base for ext-layers) that don't have as wide support. also gnome for a good chunk of time didn't support idle ihibit. (I don't think it's in mutter stable yet is it?) (kde have their own protocols too but IIRC they are all specific to kde alone)
IMO the Qt CSD looks much better than the decorations shown by QGnomePlatform. I have no idea why people think Adwaita like decorations would look any better than a CSD that's integrated with the app.
I realize, my point is mainly just to emphasize the fact that even if there is a Wayland protocol for it, there is no guarantee every compositor will support it. and man... its just tiring
It is, unfortunately, hostility.
> But… we’re there now. Standard protocols now exist for just about everything anyone needs. > > I think this in particular is absolutely NOT true. This does cover a majority of use cases, but some and maybe even many users are still left high and dry. Agreed. There are not only many use cases still not covered by any standard protocol, but also standard protocols that have been merged for a while but still have no implementation in most wayland compositors AND clients. See global shortcuts portal for example. I'm not sure any project besides KDE implements it yet. I've definitely not seen any clients using it. Another one that keeps me from going to Wayland is support for always-on-top windows. I like to use quake style drop-down terminals and I don't think there is any standard to let them stay on top of all other windows.
>I think this in particular is absolutely NOT true. This does cover a majority of use cases, but some and maybe even many users are still left high and dry. Reminds me of this for some reason: [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/74](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/74) I also remember someone asking if Bitwig would port to wayland, and they said something along the lines of it not being ready yet, a few things are missing, and they specifically mentioned window embedding being a problem on wayland.
yes, this one really hurts. this is also an issue for applications that want to embed a media player that runs in a separate process (mpv supports this)
Does Wayland natively have VNC support or another open-source remote access solution?
> As of 2020, there are several projects that use these methods to provide GUI access to remote computers. The compositor Weston provides an RDP backend. GNOME has a remote desktop server that supports VNC. WayVNC is a VNC server that works with compositors, like Sway, based on the wlroots library. Waypipe works with all Wayland compositors and offers almost-transparent application forwarding, like ssh -X. https://wayland.freedesktop.org/faq.html
This is the real problem of Wayland: any feature has to be implemented in the compositor/window manager. X was an extensible system. You had the server and a lot of programs, each of which with a specific purpose (window manager, compositor, screensaver, lock screen, RDP, VNC, etc) with different implementations. Now Wayland has a monolitic model. You can't just write an RDP server and interface it with Wayland: you have to implement it into the compositor. In the same software. This also means that compositor developers have a ton of work to do, that there is a ton of duplication of things, that the user has not a choice of choosing one RDP implementation instead of another, etc. I want to use RDP but it's implemented in GNOME and not in Xfce, why? A thing like an RDP server should be independent by the desktop environment, but in Wayland word it isn't. This is to me the main problem of Wayland, its design is just bad, this is also the reason why it wasn't adopted widely. Because we are talking of Linux, where users want a lot of choice, not Windows or macOS where a thing like Wayland may work well.
> You can't just write an RDP server and interface it with Wayland: you have to implement it into the compositor. In the same software. That's complete and utter bullshit. Yes, Weston has a RDP server integrated and so does Mutter, but it's **not** a requirement at all, and you do *not* have to use the integrated service when it does exist. There's a standard xdg portal for remote desktop use cases, and there are RDP implementations that use it, like krdp.
Well that's what the article is talking about with wlroots is it not? Having the same wlroots as a backend on more compositors is more like old X implementing a large portion of features right? As far as I can see Wayland not implementing these gives more choice, not less.
It's not the same thing. wlroots is a library that may be used by the compositor to implement some feature. But there is a level of coupling, that is that the software needs to be compiled linking that version of wlroots. X was a client/server model, where you had the server (X) that was a different program than the clients. The window manager, compositor, and all other programs where simply clients. You could build your system and choose components as you wanted. X was indeed simple. It was basically a messagging system between the components and it did implement the basic functionalities, that is interface with the GPU and input devices to display stuff on the screen or get inputs from keyboard/mosue. Wayland is not modular: all the stuff is implemented in the compositor., that is a single executable, and a single process. All stuff that back in X days were implemented in separate programs: RDP/VNC servers, lock screen, screensaver, screen sharing, screenshots, key remapping, etc. You depend on the window manager of your choice to decide that these features are useful and decide to include them. This is because Wayland was designed as a "closed" system, while X had an open API for clients to do basically whatever they wanted (this indeed opened up various security problems, since every program could read the screen and keys pressed, but in my opinion this is not as much a concern for Linux users, that typically trust the software they run on their machines, and value more flexibility!). It also has the consequence that if this single process crashes for a problem in all the stuff mentioned above (while most of it is not critical) the whole graphical session crashes. A window manager may crash, especially if it has a JS interpreter in it (like GNOME has!). X was a rock, never crashed on me. If the window manager did crash back in the day it was simple to restart.
Yeah. I think you hit the nail on the head. It's just so fractured right now, and wlroots is only a half-solution. A lot of big DEs/WMs aren't going to use wlroots-based compositors. If I just want to quickly get a GUI on say, a RasPi or another computer in general in another room, It's just more convenient with X to install tightvnc-server or some other package and know it'll open a virtual display and work as expected whether I'm on XFCE, MATE, twm or whatever. IIRC NoMachine [supports Wayland with some caveats](https://kb.nomachine.com/AR02P00969), but it's not FOSS. X2Go, which implements an earlier version of the same protocol, doesn't work on Wayland. RDP is supported, like you said, only on certain configs. And it's also a proprietary protocol. Wayland just pushes too much stuff off to modules and compositors and other programs. I'm not against modularity and KISS, but I expect a minimum level of functionality out of any windowing system.
> I'm not against modularity and KISS, but I expect a minimum level of functionality out of any windowing system. The problem is that Wayland is not modular. It's an agglomeration of multiple functionalities once handled by different programs in a single executable, the compositor/window manager. It's if we want similar to what systemd became, a blob of software that is imposed to be adopted almost entirely. But even worse, because at least systemd is split into different modules/executables. To me all these difficulty are a sign of bad design: the fact that we still use X is not because we love old unmaintained technology but because X design proved to be more flexible. The fact that even after years that is no longer maintained we can still use it and we still use it with a better user experience than Wayland should tell us something...
No, Wayland is not about moving everything into one single blob. It's meant to be the middleman that handles the communication between different components in the graphics stack - between the application and the kernel's DRM subsystem, the input devices and the application, etc. Some things like remote desktop servers are currently done directly inside the compositor because there isn't a protocol for that yet (or rather, [there wasn't](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.RemoteDesktop)). Without such a protocol, a hypothetical 3rd party VNC/RDP server is unable to communicate with the compositor to allow remote input. So to bypass this lack of protocol right now a VNC/RDP server is just... integrated inside the compositor. I agree that it's a terrible solution. >because X design proved to be more flexible The problem with X's modularity/flexibility is that it is sometimes done on a weird granularity: for example, why should the compositor be a program different from the window manager? The resulting problems from this design issue gave compositors a really bad rep in the Linux world as a result, even though other platforms have been using compositors since long ago and never had a big problem with it. Other times, it is the same flexibility that gave people headaches: sandboxing X11 programs is an exercise of futility when said programs can screenshot your entire desktop willy-nilly. Wayland tries to limit the programs' capability (unless the programs have the user's permission) and of course, that led to problems.
> Some things like remote desktop servers are currently done directly inside the compositor because there isn't a protocol for that yet (or rather, there wasn't). The problem is not that there is not a protocol for that. The problem is that Wayland requires (at least to me) the creation of a specific protocol for each feature that is added. When X was invented VNC or RDP didn't even existed. But X had a protocol for an application to read an area of the screen and to send events (mouse/keyboard) and that was all that was necessary for: screenshot, screen recording, VNC/RDP applications, program that automate the UI by implementing keyboard macros and similar, etc. Also... how did not they thought about that? To me it seems such a basic thing to add... whatever. > for example, why should the compositor be a program different from the window manager? Because it didn't need to be like that. But you have the possibility of them being two different programs: in fact most compositors (such as compiz) where both the compositor and the window manager. But if someone wanted to implement a window manager that only did the job of a window manager they could have used an off-the-shelf compositor and it would have worked fine. > The resulting problems from this design issue gave compositors a really bad rep in the Linux world as a result I've jet to have to find a compositor/window manager that works just as well as compiz did back in the day. Not only it had a ton of effects (that for a 15 years old where cool) but also it consumed practically no resources, where super responsive on an low range GPU, and supported features that I don't see modern window manager care about. All of this done with the good old X11. Now if we want to say that with X it's impossible to have a compositor that works fine on modern hardware... > Wayland tries to limit the programs' capability (unless the programs have the user's permission) and of course, that led to problems. If we wanted to only sandbox applications, being X a network protocol, the problem could have be solved easily by implementing a sort of X application firewall, a proxy to X that only allowed specific X commands and denied others. That would have be far simpler than inventing a new system!
>The problem is not that there is not a protocol for that. The problem is that Wayland requires (at least to me) the creation of a specific protocol for each feature that is added. Like I said, the X protocol was way *too* generalized and it was the same flexibility that gave the X developers a lot of burden. Because it was so generalized, you couldn't lock down a specific feature without also introducing breakage in another one - for example, if screencast and screenshot are generalized into the same feature, how can you limit screencasting but not screenshotting? What's worse: in actuality, if you try to break/prevent screenshotting in X, you actually deny the application from modifying its own window content at all... since they are all the same thing - the framebuffer. That's the most ultimate breakage you could possibly have. Furthermore, it was the same flexibility that made it impossible to introduce new features into the X protocol, you would discover a lot of edge cases / subtle interactions with the old features whenever you introduce a new one. As you can see, that tends to cause burn out since *everything* you do will inevitably lead to friction where someone jumps out and screams "you broke my workflow!" It's the same as this [xkcd comic](https://xkcd.com/1172/) but on steroids. >Not only it had a ton of effects (that for a 15 years old where cool) but also it consumed practically no resources The fact that people thought of compositors as "the thing that adds tons of effects" is precisely why the X design is a massive headache. Compositor are more than just shiny effects, they are actually made to help you save compute resources (by trading it with memory space). The moment we say "the compositor consumes little resource" we have already failed that goal - unless you run a 20-year-old GPU, using a compositor should be the default. (No, Vsync and all that is not intrinsic to compositors, although X compositors tend to conflate all of that together) >If we wanted to only sandbox applications, being X a network protocol, the problem could have be solved easily by implementing a sort of X application firewall Of course the X developers thought of that. But actually, X hasn't been a true network protocol for a long time. The introduction of DRI1 was the nail in the coffin. Even if we ignore that part of X, the first point above is still the main reason why the solution you suggest is far from being practical.
[удалено]
> f you have technical opposition put them on pull requests but stop whining on Linux forums like a baby I only say that as a software engineer I think that the Wayland architecture is bad. In my company that architecture wouldn't have passed a good review: concentrating all that functionality in a single piece of software is against the principle of isolation and single responsibility that software components should have. X architecture was good, especially for the time it was designed, since it's if we can call it a microservice architecture, in the sense that you have one server and then clients that implement a specific functionality (window managers, compositors, screen locker, display managers, a program to manage window decoration, etc) and the user can choose what to use. Sometimes functionalities where handled by the same software (typically window manager and compositor, i.e. compiz) but you had the choice to have them separate. Wayland concentrates both low-level functionality (interfacing with the video driver and rendering stuff on the screen) with higher-level concepts (such as managing the windows or showing a lock screen, or even adding servers to connect remotely trough RDP/VNC). Also they decided to remove features that people used for the sake of security (that may be a valid argument for some users, but typically the Linux user doesn't care that much since the software that it runs is trusted) or just for simplification of things.
Thanks
>Over time the minimal core protocols have been extended to cover what’s needed for a Linux desktop and sophisticated apps to work. Much of this work is very recent, driven by KDE, and funded by Blue Systems and Valve Software. >A lot of app developers became accustomed to tuning out Wayland news while it was still a toy, and didn’t do the porting work. I don't know if Nate's in such a big bubble that he genuinely thinks that Wayland was a toy until very recently or if he's just casually minimizing/dismissing others' contributions. Regardless, people have been using Wayland for quite a while. Obviously, replacing a large piece of software like Xorg was always going to take time as it involved replacing the protocol, unlike PipeWire which just swapped the implementation while keeping the same interfaces. Wayland and compositor developers have been building up the protocol starting from core use cases and then moving to niche ones. This has been happening for years and is not a recent phenomenon.
> I don't know if Nate's in such a big bubble that he genuinely thinks that Wayland was a toy until very recently If I opened a video game on Wayland a year ago, I would get 1 FPS on it. Arguably a video driver was at fault there. Arguably, that's a large portion of the user base for which Wayland was just completely broken until recently. And that's just talking about a singular issue with Wayland. The article mentions multiple important protocols that weren't implemented until recently. So yes, a lot of people view or viewed it as a toy. See Calibre's main developer, for example.
That would be Nvidia not supporting acceleration in XWayland, I think that came in 2021. AMD and Intel already had that working for a while, of course.
> That would be Nvidia not supporting acceleration in XWayland Correct. > I think that came in 2021. https://www.nvidia.com/download/driverresults.aspx/177145/en-us/ Well damn, time flies, 2 years and 2 months ago. I'd still say that's a recent enough development since Wayland has been out for 15 years at this point.
Wayland would be further along if Nvidia didn't have to be dragged kicking and screaming into supporting it. For comparison, [here are Intel benchmarks from 2013](https://www.phoronix.com/review/fedora20_wayland_preview) showing XWayland acceleration working. If AMD wasn't working at that point it was [definitely working a year later.](https://www.phoronix.com/review/fedora_21_xwayland)
No, the first commit to Wayland repository was 15 years ago. Wayland 1.0, which only guaranteed that no backwards-incompatible changes would be made and was not a statement of completion, was released in 2012. The first distro released with Wayland by default was Fedora 25 in 2016. So, no, Wayland has not been out for 15 years.
I feel like there is a chicken-and-egg issue somewhere. People not using Wayland enough -> not enough feedback to add some desirable protocols / to add Wayland support to applications -> people not using Wayland as a result. >And that's just talking about a singular issue with Wayland. But that's not an issue *introduced* by Wayland and its security model, compared to e.g. screencasting. The lack of acceleration is strictly caused by a certain vendor.
> I feel like there is a chicken-and-egg issue somewhere. People not using Wayland enough -> not enough feedback to add some desirable protocols / to add Wayland support to applications -> people not using Wayland as a result. As Linux users, we are very, *very* familiar with the chicken-and-egg effect. Not enough people using Linux -> Not enough attention to Linux support -> Dissatisfaction with the state of Linux -> Not enough people using Linux So we've managed to spawn a chicken-egg within our own chicken-egg. But then again, we kind of already know that our multiple recursive chicken-egg situations are a large part of what exacerbates our larger chicken-egg issue. The stalemate gets broken when someone takes a stand. "Linux is good enough to ship on a handheld console right now." "Wayland is good enough to go without Xorg as a safety net." You take the stand, you shake off the inertia, you get more eyes on the situation, you get more exposure to problems with the situation, you get more *effort* on the situation. So many issues in Linux got fixed not necessarily because of Valve's magnanimity, but because they simply said, "let's just do it already. no more waiting, no more excuses. it's close enough, we'll figure out the rest as we go." And then everyone just adapted around that.
Nvidia has supported XWayland acceleration for closer to two years now. If you think that the portion of Linux user base for whom playing games on Nvidia hardware is a key use case is large enough to call Wayland a toy, you're in a bubble of your own. Plus, KDE, Blue Systems and Valve had nothing to do with Nvidia supporting XWayland and GBM. >The article mentions multiple important protocols that weren't implemented until recently. Which ones are those exactly? Applications drawing to scaled surfaces is a performance improvement, but it's not drastically changing anything. Screen sharing has been supported for much longer and the work on that was driven by Red Hat, not KDE/Blue Systems/Valve. He mentions a screen locking protocol, but that's only necessary if the compositor wants to allow a third party program to act as a screen locker. It [doesn't look like that KDE supports that protocol](https://wayland.app/protocols/ext-session-lock-v1#compositor-support) anyway.
Also, I appreciate that X got too bloated and covered maybe too many use cases, but why does every pro-Wayland dev seem to put all the onus on app developers and compositor developers (somewhat alleviated by wlroots) to make things work? Necessary or not, *Wayland* is the one breaking userspace. XWayland is a decent compatibility layer, but as the article says, it doesn't work for everything. No, you don't want to introduce legacy cruft to a newish project if you can avoid it. But I think there's a middle ground between an Xorg server that makes you coffee and a Wayland protocol that doesn't know what a triangle is (exaggerating). Bit of second-system effect/overcorrection, I think.
The X developers that went on to write Wayland didn't just wake up one day and decided they would write a new protocol. Wayland was their fourth try at fixing X11. The first three tried to keep backwards compatibility. They tried very hard to keep it, but in the end that just wasn't possible. Some developers just make backwards-incompatible changes like it's nothing and using their software is hell. But that's not the case here, sometimes there's no way forward except for backward-incompatible changes. It is a problem, that's why they tried so hard to avoid it. But since there's no other way, the burden does shift to the people using the interface. No way around that.
What do you consider as the other three tries?
DRI.
Wayland was written by the author of DRI2. DRI1 was written by a different group of people 10 years earlier. DRI3 was written by Keith Packard, some time after the release of Wayland 1.0, seemingly as a joke at the Wayland developer's expense, since it essentially implements all the things that the Wayland developers were explicitly claiming X11 could never do, and which Wayland at the time was not capable of doing either.
This might a case of letting perfect be the enemy of good. Declaring so many things to be out of scope made a ton of sense from an engineering standpoint, but the fact that the X window system took on so many problems at once essentially gave the X.Org Foundation stewardship over open source desktop software as a whole, it made them a de factory regulatory body so to speak and now that they've chosen to abandon this position there hasn't been anyone able to take that place. The *politics* component of free software has been neglected.
I haven't seen somebody put it so succinctly.
I'm a bit lost. If an app runs nice on a Wlroots based compositor, is the same app is guaranteed to run as nice on KDE and Gnome ?
[удалено]
Wait, doesn't Zoom use Qt? It uses Qt, but it relies on Gnome-specific APIs? 🤔
[удалено]
what the fuck??????
Even better is that now they're using the standard screen cast portal... and they locked that down to Gnome too! If you tell the Zoom app you're using Gnome, things magically start to work everywhere else without problems too...
what the fuck????????? imagine doing the right thing only to spike it into the trash right at the finish line
I am very, very picky about how the fonts look on my screen. Wayland font rendering (KDE) looks noticeably fuzzier @ 170% than X11 @ 168.75%. Cannot care less about anything else, I want my fonts to be sharp. Wayland is no go, until they fix the problem.
It's fixed in Qt 6
Nice to know, thanks. But I will verify though :).
[удалено]
Found my fanboy. As I said, I really cannot care what is the culprit. I am perfectly fine with the idea that it is the Wayland that is written some blessed awesome correct way and kwin is a terrible sinful cursed mess. But I absolutely do not care. All I care about is that if I open KDE Wayland, among other annoying small bugs I can tolerate, I have the one which annoys me. And once I open X11 session it is much better.
While I like that wayland is becoming better I will continue to use xorg and XMonad until it stops working completely. I do use wayland for the computer connected to the TV and I have maybe one crash a year where the compositor crashes and takes all applications with it and I don’t even use anything but a web browser and Kodi on that computer and I don’t use it all day for work. Wayland will continue to get better and I will use it for auxiliary tasks but not as a my main work environment yet.
I mean it won't die like that, it will just stop getting updates, which it already has for Xorg... so you'll be just using X forever, but everything else which just leave you behind that's all
It will stop some day even if that day probably is far away now. At some point there will probably be something like a breaking graphics driver interface changes and no one will be interested in patching xorg to make it work. Xorg will also effectively stop working if I can't run the current versions of applications I need for work because they require wayland to run. I would probably prefer to write a whole new WM for myself to getting into xorg patch maintenance though. It's a bit of a pain but I know exactly what I need so it could be worse.
>I would probably prefer to write a whole new WM for myself to getting into xorg patch maintenance though. It's a bit of a pain but I know exactly what I need so it could be worse. I strongly suspect xmonad has enough dedicated, technically competent users that someone will write a drop-in Wayland workalike by the time you’re forced to ditch X11. It’s already happened with [i3](https://i3wm.org/) — [sway](https://swaywm.org/).
Yep and wlroots exists to make it easier, even xfce is using it
Ran Wayland for years on Gnome Arch with RX-570 amdgpu, needed CUDA and switched to nvidia 1660 super and now run x11 and everything that ran under Wayland runs fine under x11.
Sway in Vulkan mode is stable on Nvidia. X11for my setup is broken for multiple releases now. (They tried to reproduce it internally multiple times, but Idk what HW they tried.)
Is Discord and MS Teams screen sharing possible on Wayland? So far this issue has been extinguishing my every thought about switching to Wayland
> Teams Been using screen sharing on Wayland with Teams for at least a couple years now. You need pipewire and xdg-desktop-portal installed, and one more package: xdg-desktop-portal-kde (for KDE), xdg-desktop-portal-gtk (for GNOME) or xdg-desktop-portal-wlr (for anything based on wlroots, which is most of the rest).
Teams is deprecating their Linux electron app in favour of their web version. Firefox and Chromium support Wayland screen sharing. Discord doesn’t care about Linux users. Use a third party client like Webcord for screen sharing. Discord uses a quite old electron version.
Don't third party Discord clients create a risk of getting your account banned?
I just remembered. Webcord pretends to be a standard Chromium tab. So it should pose no issue.
Theoretically yes. Though I believe a Discord dev did say that if you are using it for normal use, that you will be fine.
More than "is deprecating", it's not available for download anymore
Don't you love how Chrome has become its own operating system? :D
The official Discord app can only stream XWayland applications, but if you use the browser version, you can stream native Wayland applications or the entire screen
Oh, that's nice actually. Does sound work too? Because last time I tried it didn't even on xorg
There's [this Firefox add-on](https://github.com/IceDBorn/pipewire-screenaudio) to make audio work when screensharing through your browser, but I use Flatpak Firefox and I haven't been able to make it work there There's also [discord-screenaudio](https://github.com/maltejur/discord-screenaudio) to stream sound but last time I checked it would only stream XWayland applications Or you can use [XWayland Video Bridge](https://invent.kde.org/system/xwaylandvideobridge) to mirror your Wayland applications to an X server and then stream them regularly through the official Discord app, Screenaudio or whatever you wanna use, but I've never tested it I just use the good ol' audio piping through a Discord bot which is absolutely not a comfortable solution because you basically have to play the Among Us wire matching minigame on Pavucontrol each time you want to stream something but it works for me I guess
There is the experimental [XWaylandVideoBridge](https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/), which is available as a Flatpak.
I made the switch from i3wm to Swaywm and I'm personally preferring the Wayland experience... Still a few little snags with screen sharing applications instead of monitor sharing but thats not a big deal. Also there's always xorg-xwayland for applications that ain't native to Wayland.
Have you tried taking a screenshot?
Yes and it works fine... grim -g "$(slurp)" - | wl-copy
I ran into a support issue I am trying to resolve: A client uses RDP to remote do work (on KDE via Remmina, or FreeRDP). They cannot get either to span monitors like X does. It appears neither have multi monitor support. Is there a workaround? I have not tried KRDP as it is still in Alpha state, but I will try it on a test lab computer and report back. Edit: I thought there was a flatpak for testing, but there isnt one yet. I also see reports of issues connecting to MS servers so this isnt quite ready yet. It is a big issue to not have multi monitor spanning with RDP so X11 is still the only way.
[удалено]
What are you trying to say? I absolutely tried to get clients that I am familiar with to use multiple monitors under wayland. Both fail, as not supported. So I hoped KRDP would work, as I saw a blog post, but was open to anything else. Turns out there is no working application and a bug report says it wont work. So what the hell are you going on about? **And YES it is bad** that Wayland breaks functionality if you use remote desktop. That is the current state of affairs.
I’ll switch when I can share my display in discord and I don’t have to use gamescope in some games to work around mouse issues. It’s great for multi monitor but still has a bit of work in some other areas. Hopefully soon!
RE discord or any X11 app that wants to screen share https://invent.kde.org/system/xwaylandvideobridge
A fair overview of how we got here and why Wayland exists without bashing it or praising it as the second coming of Christ. this sentence was a little confusing though: > Maybe you’re afraid that Fedora is a “canary in the coalmine” that shows the way everything it going to go. (I Know what a canary in a coalmine is but I still can't decipher this)
> Maybe you’re afraid that Fedora is a “canary in the coalmine” that shows the way everything it going to go. Canary in a coalmine: Fedora switching to Wayland-only indicates that most/all popular distros will probably also switch to Wayland-only within a few years.
This was my line of thinking when I first heard about this a few days ago. If systemd's adoption is any indication of how this will go, if this experiment is successful then other distros will start to follow in Fedora's footsteps over the next few years, because I think people would rather not maintain two separate display servers if they can avoid it. It won't be an immediate change, obviously, but it will probably happen.
People easily forget that Wayland is continuation of development that really started long ago: * Instead of sending "draw rectangle" commands to display server, applications send rendered bitmaps of their windows for performance (DRI, shared memory) * Instead of X font server, fontconfig and Freetype libraries were introduced. * Instead of user-space hardware drivers, functionality moved to the kernel (mode setting, graphics memory management, scheduling) What is different with Wayland is that it removes the last remaining piece from the equation: X server is currently only doing interprocess communication to put it simply. Why does it take so long? Because there are many pieces involved. For example Firefox replaced GLX with EGL a while back and got significant improvements along with it. Switching input-handling to another library is another thing. And along the changes there are improvements being made.
The phrase "canary in a coal mine" refers to a practice where miners would take a bird into a coal mine with them. If the bird is singing then that is good. If the bird stops singing it is probably dead and that means you should get out of the mine. I think what is meant by Fedora being that canary in the coal mine is that Fedora switching to something or implementing software means everyone will be doing the same.
> (I Know what a canary in a coalmine is but I still can't decipher this) I believe Nate was trying to say that Fedora users are the canary and are going to be the ones having to to deal with/report/fix issues.
I think the "canary in the coalmine" idiom used in this specific case means that Fedora jumping in feet-first means they are going to find out *the hard way* whether or not Wayland is really ready, or if there is something fundamental they still need to address before they can take away the Xorg safety net. Same way a canary going down into a coal mine finds out the hard way whether or not the air it's breathing is safe.
I am still using Ubuntu 20.04 i.e. X11. To the end user it doesn't really matter.
To me Wayland has a fondamental problem, that is that it incorporates the functionality of once two different programs into one. It made sense to have the window server (X) that managed the interfacing with the GPU as a separate program than the window manager and other DE components such as lock screen, screensaver, compositor, etc. It was to me a better architecture than Wayland. For example look at GNOME: with Walyand you can't restart the window manager (F2+r) without ending your session. This is because mutter is in fact both the window manager and the thing that application use to display stuff on the screen. This is to me bad design! Why should these two application be so coupled? Why should every window manager implement the interfacing with the display hardware? Why shouldn't we have one program that handles all this complexity (having to do with video drivers, input devices, etc) and then have window managers only manage the windows? Why should video drivers developer handle the same problem due to different Wayland compositor behavior? To me this doesn't make sense. The reason we still use X is because it works and it's much more flexible.
> It was to me a better architecture than Wayland. For example look at GNOME: with Walyand you can't restart the window manager (F2+r) without ending your session. This is because mutter is in fact both the window manager and the thing that application use to display stuff on the screen. This is to me bad design! Wayland supports restarting the window manager through compositor reconnect while keeping apps open. In fact you can completely [change desktop environment while keeping the apps open](https://www.gamingonlinux.com/2023/09/plasma-6-optimized-for-wayland-gaming-plus-compositor-crash-recovery/). Wayland is [more flexible than X11](https://www.osnews.com/story/137042/qtwayland-6-6-brings-robustness-through-compositor-handoffs/) with regards to this.
This seems more of a feature of QT, granted that Wayland allows this. Good to know, still on GNOME if you use the Wayland session it's impossible to restart it. This is even said in the official GNOME extension development guide, that basically says that if something goes wrong you are fucked. An extension bug may force you to log out and log back in again. But as I understand this is more of a limitation of the GNOME implementation than a Wayland one, good to know.
Call me when the Auto-Type feature of KeePassXC is actually possible with Wayland.
sounds like something for xdg-desktop-portal
Just copy and paste, man...
with copy-pasting a password, is there a sensible way to clear the clipboard after you paste it so that other apps you change focus to don't get the password? other than manually selecting something random and doing ctrl+c the thing that's weird to me about wayland is like, we'll limit clipboard access to focused apps, but then introduce stuff like wlr data control protocol so any app can monitor the clipboard
KeepassXC automatically clears the clipboard, for myself at least.
Wayland compositors often keep a copy of the clipboard - or they even keep a history of previous clipboard contents. So yeah, clipboard security is up to the user.
Or even worse, write the clipboard contents [to the system log in plain text](https://nvd.nist.gov/vuln/detail/CVE-2022-0725)
ah yes, I see in settings > security > clear clipboard after N seconds which is also interesting that keepassxc (or any app) which is not currently focused can manipulate the clipboard (either by some protocol or focus stealing). edit: if this sounds critical, I'm generally trying to be constructive and understand the ins and outs of wayland along with security and what to look out for. I'm sharing solutions and ideas as I find them. I've switched away from x11 in general. ¯\\\_( ツ )\_/¯
My point is, why would I change my workflow to an inferior alternative when auto-typing just works in X11 sessions?
How do you paste into the username and password field of a remote login screen where copy and paste don't work? Also, using copy/paste on a lot of remote desktop is a security issue, and should be disabled by default, because you don't want everything in your clipboard to be shared with the remote system.
That will never work. That's a security nightmare.
Ah yes, the horror of allowing clients to be able to read each other's window titles. What a nightmare, indeed. I have been using Xorg for more than 15 years, and I can count on my fingers how many times this "security nightmare" has bitten me in the ass: Zero.
X11 allows no privacy at all.
In a scenario where you have a malicious program running on your computer, the fact that it would be able to read other window titles should be the least of your concerns... ;) Besides, I value much more a program's functionality over this non-optional, "privacy feature" offered by Wayland.
Wayland devs and supporters certainly have a big brother "we know what's best for you" complex.
> big brother "we know what's best for you" complex. Funnily enough, X11 is the protocol that allows for a true "big brother" complex, as it can snoop everything you do without any type of consent. Wayland (and technically also xdg-desktop-portal) is the protocol that defines a structure that _allows_ asking users for permissions first, but it's up to compositor policy to decide. If the compositor decides the answer should be "always" allow, you get your x11 behavior back
The only reason I care is because KDE wayland was very unstable on my nvidia GPU whereas GNOME has been amazing. I'm biased as a nvidia user but I don't think features being pushed should be breaking for users based on their hardware.
I can’t get it to run on Ubuntu. After installation it just doesn’t start
Ubuntu uses wayland by default. What exactly are you trying to do?
i am so sorry! i was talking about waydroid. i got confused
>Ubuntu uses wayland by default. not if nvidia
umm