Ask HN: When do you think Wayland will be broadly supported?
I mean at this point high DPI laptops on small screens are common, and fractional scaling is necessary for a good experience... Yet Wayland support is not yet there, thinking of how Plex doesn't support it, due to Qt. Or of how VSCode Wayland compatibility has been broken.
104 comments
[ 3.4 ms ] story [ 175 ms ] threadI’d guess adoption will continue to accelerate. My experience with Wayland has been nice so far with a few minor kinks. I don’t do anything complex though.
I tried to use Sway for a few months (as a regular user of i3) and I ran into too many frustrating issues to want to keep with it.
The greatest problem with the Wayland protocol is how much work a compositor has to do. Requiring every window manager to also have to take on tasks like processing keyboard and mouse input is a massive tradeoff for what Wayland offers.
IMO, we needed something not far off what X11 does. Really, X11 was fine but could use some rearchitecture for modern times and a purge of all the 80s drawing cruft nobody uses anymore. And address the input security stuff.
No, not really. Everything that Wayland does is stuff that X11 compositors were already doing. With those the compositor is already taking on all processing of input, and the X11 server is only creating an additional unnecessary step by passing all the input through. Thus why that extra step was removed in Wayland.
Sounds not like a very modular/orthogonalized approach, and also limiting the choice of the user.
Regarding the issue of "choice", please read this page: http://www.islinuxaboutchoice.com/
But X is two things: a protocol and a de facto standard server that window managers could easily interface with.
I wonder if we’d be in a different place if Wayland as well as offering the protocol also offered a de facto standard server (not simply a reference implementation in weston) with a window manager protocol that more or less forwards on client <-> server messages that a window manager would care about. Client buffers shared with the server can also be shared with the (separate) window manager process which then shares its composited buffer with the server for final rendering.
What we needed was a server and a standard library. Not a barebones protocol for everyone to implement with a different set of bugs.
wlroots showed up too late to the game. Now we have GNOME, KDE, wlroots, and maybe some other implementations floating around out there.
I fail to see why it would not have worked for Wayland.
There is a remote possibility that some person comes along and builds a server and library that will work for everybody. But such things would probably be very large, much larger than systemd. Actually, the closest thing to what you describe is probably a web browser and HTML5, but building a desktop on that seems to be not popular aside from Chrome OS.
> X11 was fine
People with deep knowledge of this area (like Keith Packard) stated the exact opposite many times (that this mess cannot be simply cleaned up and they really did have to start from scratch), but whatever.
Here's one of those articles (I think, but it's been years and I don't want to re-read it just to check):
https://lwn.net/Articles/491509/
I put a lot of effort into using Sway and the experience sucked.
> People with deep knowledge of this area (like Keith Packard) stated the exact opposite many times (that this mess cannot be simply cleaned up and they really did have to start from scratch), but whatever.
I never advocated keeping X11 and just doing cleanup. But the solution probably should look more like X11 than it does.
For all that deep knowledge we have a project a decade old, with relatively low adoption and a number of critical blunders along the way (no forethought given to apps that need global keybinds, no forethought to screen capture).
Wayland is shaping up to be a fragmented mess instead of the successor standard that the Linux desktop needed.
Please see this pull request for a description of some of the current challenges with getting global shortcuts to work: https://github.com/flatpak/xdg-desktop-portal/pull/711
>no forethought to screen capture
The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it.
In any case, X11 also does not have any forethought in relation to hotkeys or screen capture. Technically it has no API for either of those, it has APIs that allow all applications to intercept all keys, and to allow all applications to read the contents of any window. Those APIs can be used to do hotkeys and screen capture in a rudimentary and somewhat broken way but they are not ideal. Just copying those (or an API that looks like those) into Wayland would be an unwise idea.
> The plan for a while has been to put screen capture in Pipewire, this is already working for apps that support it.
> In any case, X11 also does not have any forethought in relation to hotkeys or screen capture
IHMO screen capture and screen sharing are more basic functionality in 2022 than frame perfect. The reason is that if every frame is not perfect we can still understand what happens on our screens. If I can't make screenshots and I can't share the screen I can't work so I will use something else. X11, Windows, Mac, etc.
X11 eventually solved those problems (actually the solution derives by trusting every client of the server) and Wayland will solve them too. But as Wayland started in a world where screenshots and screen sharing were already work tools, one of the very first questions should have been: how do we design both a secure system and one that allows screenshots and screen sharing? If it was asked it wasn't given the right priority.
Having apps to collaborate with Pipewire (which was added later on if I'm not wrong) is bad design. The screen is there, I want to be able to grab it and share it no matter which app is on screen. Those pixels are mine, right?
That did already happen, Weston had a built in screenshot tool. Pipewire was adopted because it was an improvement on the Weston design.
Why is it unreasonable to ask that from a window manager in the general case? The protocol should provide for every basic feature suitable for the problem domain. But these things can be refactored out to third-party libs like wlroots, making a simple window manager implementation similarly easy as under X.
Now that distributions mostly default to wayland and pipewire I feel that the linux desktop is in a solid place.
Like another comment pointed out, requiring every single program to support Wayland is a tough pill to swallow. That AreWeWaylandYet site is cute, but the fact it lists individual apps is exactly the problem. If your workflow requires other apps, or if you'd just like to use something else, you're SOL.
Switching to Wayland today means replacing most of the apps you're used to already. No wonder adoption is slow.
If you mean things like xdotool or a screenshotter, then sure. Otherwise, I can't imagine why you'd do this — at least I didn't have to replace anything (besides a couple of low-level things mentioned above). Old stuff continues to work via xwayland and I only ever notice it because I added a special marker to xwayland windows (to remove xwayland from my system when I notice that it's not used anymore by anything).
> requiring every single program to support
Wayland compositors do not require "every" application to support them. Most old applications continue to work fine through xwayland (for me it's mostly JetBrains' IDEs — you don't notice it's not a fully "native" application unless you look for it), and everything using toolkits like Qt should just work.
That's good to know and I stand corrected. I would still have to switch away from my window manager (bspwm) and hotkey program (sxhkd), which are inevitably tied to X11. While alternatives do exist for Wayland, it would be a substantial change of workflow of my two most used programs.
That’s more of a social phenomenon not a technical one (bazaar vs cathedral)
> Switching to Wayland today means replacing most of the apps you're used to already. No wonder adoption is slow.
That’s just plain false. Most application uses a framework and basically all of them has seamless support for multiple render targets, including wayland.
The touted benefits of Wayland aren't manifest or relevant to me. Screen tearing? I don't get screen tearing when using kwin with compositing on my intel iGPU. I know what screen tearing looks like, I've experienced it before with other configurations, and it doesn't happen for me with this configuration. Security? My whole $HOME is readable and writeable to just about any application I run; using Wayland is like locking my windows but leaving my front door wide open. X being an abandoned project that is no longer supported? Well it's still performing better than Wayland for me.
If Wayland devs really want me to switch, they'll need to either make Wayland work much better, or make X work much worse. Until then, I won't switch.
If you don't care what I use, then my above comment shouldn't upset you. I'm merely describing why I continue to happily use what I use.
There was a question on a topic, and someone shared their opinion on this topic. It was cleanly focused on what it would take for them to adopt Wayland, and answering the question from a personal point of view.
This is what generally happens on discussion boards like HN. This will happen a lot here.
> "Wayland devs" absolutely don't care if you switch or not
Citation please showing that "Wayland devs" do not care about why people aren't using Wayland and do not find people posting issues with their pains in adopting Wayland helpful in any way.
https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.ht...
It shows pretty clearly what these "discussions" did to at least one maintainer of a compositor I've spent thousands of hours in front of. Thanks for burning him, I guess.
When I recount difficulties with any FOSS application, I try to be very humble, always remembering the immeasurable amount of work put in by developers to give me this thing for free. Somehow you don't see a lot of this in these Wayland threads. A commenter waltzes in, leaves a classic screed ("you won't see my business unless this XYZ thing works!"), and marches out. Leaving no word of thanks for work that has already been done, not throwing a couple of bucks for a coffee.
Maybe it's a cultural difference, I don't know. Seems very entitled to me.
This is probably just a bug. If you are using kwin compositing on X11, and not using the option that disables it for games, then it will be doing more or less the same thing as Wayland. So there is no reason it should be causing such a performance hit.
Exactly. Like, holy moly did the people working on Wayland get carried away by the mobile OS world. And second system syndrome too probably. I'm using $DISTRO because I trust them enough to not package spyware/malware in their repos. I know it's not 100% safe, there have been and will be security bugs that don't get fixed in a timely manner, or even ones that got introduced by distro-specific patches in the first place, but holy hell my OSS desktop is not a proprietary smartphone OS loaded with random closed-source apps from god knows who that tries to steal my data for profit. If I get pwned then it's certainly not through my display server.
I mean, eventually, like always, the open source world will get its shit together, and Wayland will probably become usable, but we only recently kinda solved the whole screen recording issue.
A few weeks ago I wanted to have a simple script, that would quickly switch between a couple display configurations. With X11 that was dead simple by using xrandr. It works with every DE/WM on this planet. You'd assume there's an equivalent tool for Wayland. But mumble mumble security, you cannot do that, so we got the same f#+ing situation as with screen recording again, every WM/compositor comes up with their own solution to something absolutely trivial. GNOME/Mutter have a dbus-API, wlroots-based ones have "wlrandr" via some protocol extension, KWIN I didn't even bother checking. But it's only 15 years since the project started right, why should something trivial as this have been settled upon yet? I even stumbled upon a discussion in an issue tracker that I cannot find just now where Wayland devs argued that you don't even want something like that. Like, go working for Apple with that mindset.
Give it another 10 years, and it might be ready to serve more than the absolutely trivial average Joe use-case.
In my opinion, Wayland has avoided this by deliberately being simpler than X11.
> I'm using $DISTRO because I trust them enough to not package spyware/malware in their repos
>but holy hell my OSS desktop is not a proprietary smartphone OS loaded with random closed-source apps from god knows who that tries to steal my data for profit
I think it is not reasonable for you to ask them to never plan for a day when that could happen, if that is what you are suggesting anyway.
>You'd assume there's an equivalent tool for Wayland
Not if you were aware of the current issues with Xrandr and why it is a poor target.
>But mumble mumble security, you cannot do that, so we got the same f#+ing situation as with screen recording again, every WM/compositor comes up with their own solution to something absolutely trivial. GNOME/Mutter have a dbus-API, wlroots-based ones have "wlrandr" via some protocol extension, KWIN I didn't even bother checking. But it's only 15 years since the project started right, why should something trivial as this have been settled upon yet?
It is absolutely not trivial, and there are security/usability issues with it. To do this "the right way" would be more or less duplicating the entire KMS API into every implementation. Even XRandr is still missing features compared to that, so it is not an adequate solution either.
Wayland is not really simpler than X11 unfortunately. The core protocols are very poorly documented, and a lot of practically important stuff is left to be implemented in unspecified ways by the compositor. Like a lot of freedesktop.org stuff historically, it's hard to tell what's prototype-quality from what's actually ready for daily-driver production use.
I would say it is. All the things you said are also true of X11 and are worse there, which is another reason why it has been so impractical to develop additional X11 servers, and why everybody always just used X.org despite its shortcomings. And by the way, freedesktop.org has for the most part merged with X.org now. It is the same group of people doing the same work.
Any examples? I found it much easier to grasp than X11. I have worked on libraries that have both X11 and Wayland backends and X11 code was always an impenetrable pile of workarounds that could break from looking at it, while Wayland code was usually relatively simple and easy to understand.
Then plan for it, architecturally, so that you can add or enable these features later on, or when you need it. Start with something sensible, appropriate for real-world usage. Wayland was everything but. With X11 the ship has sailed in that regard, but if you start over, don't create something that doesn't even offer these features in the name of security and then let the community come up with 10 different solutions to the same problems in the most uncoordinated way possible.
> Not if you were aware of the current issues with Xrandr and why it is a poor target.
xrandr works exactly fine for setting up your screens. You can pass resolution, refresh rate, position and orientation via command line in a simple and understandable way. It's a great example for a trivial real-world tool that should just exist.
> It is absolutely not trivial, and there are security/usability issues with it. To do this "the right way" would be more or less duplicating the entire KMS API into every implementation. Even XRandr is still missing features compared to that, so it is not an adequate solution either.
This completely confirms second system syndrome. It's only as complicated and non-trivial as you want it to be. I can only imagine what kind of convoluted security nonsense you think of when you say "the right way". Ask the display server for a list of screens and supported resolutions, and then tell it what you want to do with those. Done. X11 does it, Windows does it, macOS does it.
This is exactly what Wayland has done though. Few have a reason to run command line tools to change the screen configuration, real world usage is to use a GUI as is common on every other graphical OS.
>You can pass resolution, refresh rate, position and orientation via command line in a simple and understandable way.
A major problem here is because of the way the API works, technically any X11 client can do that at any time. The tool may seem trivial but the way it is implemented has great potential for misuse. It does not even have to be malware for this to cause problems, for example a typo in a random script could seriously screw up your screen. Or another common problem in X11 is with applications setting the resolution to something weird, crashing and then leaving the screen in a weird state.
>This completely confirms second system syndrome. It's only as complicated and non-trivial as you want it to be. I can only imagine what kind of convoluted security nonsense you think of when you say "the right way". Ask the display server for a list of screens and supported resolutions, and then tell it what you want to do with those.
If this was second system syndrome, then it would be in the kernel, not in X or Wayland. Because the kernel is where all the new KMS features happened. Again, the display server is not actually driving this feature. They are relaying information to and from KMS, which is the actual API that configures the screen.
But those few gravitate around OSes using X11. Any other graphical OS has way more users that use the computer they are given to perform the task they are given. No questions asked, no fiddling with settings. When you develop for people that use a system specifically because it allows fiddling, you must not take away functionality. If you do, prepare for criticisms.
And somehow, I doubt that even the most fervent of fiddlers really enjoy typing obscure command line incantations just to configure their laptop when they connect it to a projector.
What you are thinking of is an API, not a command line interface. That still exists, and it can be used to build a command line interface. Command line interfaces by themselves are actually very poor for automation and integration, as they force you to do lots of unnecessary formatting and parsing in and out of text strings at every step.
For graphical tasks such as this, the command line is indeed obsolete. The main usage for remaining with the command line in modern times is for manual administration of a remote server, but that is not relevant here as the whole problem space is about administering the local machine as a GUI.
Anyway, xrandr is already there and Google and stackoverflow are full of examples. I'm not surprised that people would invest half an hour copy pasting code from there instead of identifying and learning the underlying API. I don't see why that should be a problem.
It is not true that command-line interfaces are not used to remotely administer GUI desktops. This is actually a huge and very common problem space.
See my other comment about impedance mismatch for an explanation of the challenges with using command lines to remotely administer GUI desktops. It can be something that complements GUI administration, but can never possibly supplant it, because if you do that then you're intentionally trying to route around the problem space.
> It can be something that complements GUI administration, but can never possibly supplant it,
There are probably tens of thousands of people whose daily lived experience is that command-line administration of GUI desktops is all they've ever needed and yes, in fact, totally supplants the alternative. I am really struggling with this thread; it's my impression that you've a very narrow view of what people are doing with their computers.
Common problem? I’ve never heard of this happening. I suppose hypothetically random applications could trash my X settings but in 20 years they haven’t.
On Windows I have observed random applications do have this power and sometimes exercise it, but the worst it’s ever done is mess up my desktop icon arrangement, by some mechanism I know not the OS reverts the resolution change if the application crashes.
So we should settle for windows that can’t be locked for yet another 3-4 decades? Noone claims wayland will secure completely unrelated parts of the stack , but it is a start that is must have.
Wayland has solved more problems for me than it caused, but I'm bummed our that I can't use my laptop's external screen because of nvidia shenanigans (had to mess with some udev rules to even het the option!).
So, when it comes to my problems: when I buy a new AMD GPU for my desktop and replace my laptop in a couple of years. I'm not foolish enough to think that Nvidia is ever going to put effort into making Wayland work right on their hardware despite their "open" "driver". I'm sure there are people working for Nvidia that would like nothing more than to open the driver and just make Linux work with their hardware, but they're not the people who are allowed to decide to do so.
I think that particular issue has been fixed in the latest release. Tried it the other day on my Fedora laptop running NVIDIA 515.57 and it worked surprisingly well.
Things are improving at a steady pace but Optimus laptops continue to be an irritating experience unfortunately. Breaking suspend every month or so is basically tradition at this point.
try using firefox over X forwarding in 2022.
I've also seen it work fine with 100mbit speeds. But again, I'm not going to make the claim that X-forwarding is the be-all and end-all of remote display solutions; I use mostly RDP and VNC when I'm on the Internet. I never said that X-forwarding is the best remoting solution in all scenarios. You're the one making the argument that everyone who doesn't do things your way is doing it wrong, because you don't seem to understand that other people have radically different use cases than what you're used to. And the flexibility of X11 means that it supports those use cases and others out of the box...and Wayland does not.
In fact, the only thing I've seen going for it is that a) people don't want to maintain X11 and b) it addresses vague security issues like applications resetting your display settings that almost no-one ever had a problem with. It's not a mystery to me why people complain. You're telling people that they're wrong for using their computers the way they've been using them for decades, and if they only change their workflow and environment (which they may have no control over) then they will be compliant with what's new and happening. I'm not here to defend X11, I have no great love for it, but it's bizarre to be told not wanting major feature regressions is wrong.
I have not had a problem with any application thus far.
I don't. I deal with many thousands of Linux servers. Batteries-included languages and X forwarded are my bread and butter. Losing the latter would make my job much, much worse. Of course, it would be nice to install random packages, but I can't.
> The only reason it seems anyone would even consider using it is because ssh has built-in support for it, or if you only use a handful of small Xaw3d or Motif applications with no graphics or bitmaps.
This is absolutely absurd and a completely ridiculous exaggeration approaching slander. I use perfectly normal, modern applications with X forwarding every day with zero issue, including web browsers (Firefox), image editors (GIMP), file managers (Dolphin), IDEs (Eclipse), various developer tools (MySQL Workbench) etc.
Frankly, a comment like this is shocking because it's plainly untrue.
> The only reason it seems anyone would even consider using it is because ssh has built-in support for it
This is a tremendously bigger upside than you seem to be giving credit for.
I'm going to just say it in this comment, because HN rate-limiting is hitting me, but none of the solutions you mentioned meet the criteria I described in the other post.
For me, X11 forwarding:
- works out of the box, no config needed
- works on an application level rather than desktops; this is key
- doesn't require anything network-wise but SSH
- doesn't require me to modify servers in tightly controlled environments
These are all mandatory requirements for me.
https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar...
Zoom, on the other hand, only supports screen sharing on blessed combinations of OS and Wayland, and naturally arch/Manjaro aren't on the list.
Much easier than before where you had to change environment variables for that to work.
There 2 major software achievements may be all we need to finally get fusion (or economically efficient solar power) + economically efficient carbon sequestration
On X11 I had issues with screen tearing when reading pdfs and gestures not feeling smooth, so I walked away from it pretty quickly.
Zoom issues? That's Zoom's fault, and you can use their webapp as a workaround.
Plex? Whatever, webapp version will suffice.
VSCode compatibility broken? How so?
Screenshot & recording issues? Gnome 42 resolved a lot of that with their redone screenshot tool.
Stating this as from a more 'new user' perspective Wayland has been fine enough for me.
Edit: I still use Wayland whenever I can despite these limitations because it feels really nice in day-to-day use. Smooth scrolling and fluid touchpad gestures come to mind.
The worst part of this mindset is pointing to Xwayland. In my experience, Xwayland is more of a fig leaf than a real solution. Applications that need wayland-specific code and can't just use a newer version of GTK or SDL are usually apps that don't work with Xwayland anyway.
The second worst is pointing to Wayland-only apps as a replacement, when the previous apps were cross-platform, and not just X11 cross-platform, but Windows/Mac+Quartz/Linux+X11 cross-platform.
Wayland will stop sucking for people like you when distros and Wayland developers acknowledge that people like you have a point and real concerns, and that you are driven by something else than nostalgia and inertia. Until then, this discussion will always end with "you don't understand that Wayland is a much cleaner design than X11" and nothing will fundamentally change.
(Yes, the GNOME project’s obtuseness where it regards theming and “usability” is an entire sub-thread here, but the visual annoyances in the Linux desktop are a long way away from being fixed by Wayland alone…)
GNOME's regards towards theming is precisely because of things like Qt themes being broken all the time.
I also read a thread in some of the Firefox bugs, that because of unfortunate design decisions, compositing in Firefox on Wayland will never be as efficient and performant as on Mac or Windows.
Hopefully developers will find solutions and workarounds, but I don't think Wayland will be ready as replacement in the next 2-3 years.
>[...] y en cuanto a servidor gráfico incluido, decir que se trata de X.org 1.10.0. La próxima edición de Ubuntu, Oneiric Ocelot, que teóricamente saldrá en octubre posiblemente ya incluya Wayland. [...]
It says that Ubuntu 11.10 was probably going to include Wayland as a graphic server. But this is funny, since a few days ago, I tested the latest Ubuntu version on a laptop, but after all these years it still defaults to xorg.
I don't think that Wayland is a bad idea though. But it isn't there yet.