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
Recently I found in my library an old Linux magazine (a real printed one!) from 2011 that my parents bought me in Sanborns. It included a cd with Ubuntu 11.04 which I (of course) installed in an old Pentium 4. I was 10 back then, so I didn't remember a lot about this magazine. But there is something that catch my attention (This is about Ubuntu 11.04):
>[...] 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.
>[...] 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.
What makes VSCode broken on Wayland?
I’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’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.
Qt and Electron both support it, so those applications just need to enable it. It is hard to understand what else fits your definition of broad support, because you have only listed two applications.
Unfortunately, I think Wayland really botched things. That's a shame because it would have been a great improvement. Wayland and friends have taken far too long to build and the tradeoffs to me, an end user, are not convincing.
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.
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.
>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.
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.
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.
The Wayland protocol is fine and provides the modern features expected (“every frame is perfect”).
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.
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.
It seems like the problem with Wayland is things that used to be solved by merging some code into X are now a big social synchronization problem, ie. get everybody to agree on a protocol.
Yes, that's a large part of it.
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.
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 believe it is a more fundamental “problem” due to the bazaar vs cathedral model. The linux ecosystem simply can’t just say X or Y will be the way forward like apple can, so some inefficiency is inherent in standardization.
Doing so requires writing a server and library that everyone can agree on, which probably will not happen and is probably one of the main reasons they did not do it in the first place.
Despite the whining of anti-systemd people, it worked for systemd.
I fail to see why it would not have worked for Wayland.
I fail to see why it would not have worked for Wayland.
Please see one of my other replies here. When implementing an X11 compositor those parts were already done separately anyway, and this is actually the entire point of X11 compositing. So the trend with X11 was already going away from the direction that you suggest.
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.
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.
You still had the same problems in X. It was a bad idea to try to get protocol code merged into X unless you could get everyone to agree on it. Because ultimately, in either case it is still the same set of people who will be using any new protocols.
Somebody could design that but it is not clear why you would. You do not need a separate process for that.
As long as X11 fans are going to complain without actually doing something, things are going to stay that way. Xorg developers had put it on life support years ago, and somehow nobody has stepped up to to their work.
> 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/
> 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 am not an X11 "fan". I use what works best for me.
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.
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.
>no forethought given to apps that need global keybinds
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.
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.
>> 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
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?
> 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?
>how do we design both a secure system and one that allows screenshots and screen sharing?
That did already happen, Weston had a built in screenshot tool. Pipewire was adopted because it was an improvement on the Weston design.
That did already happen, Weston had a built in screenshot tool. Pipewire was adopted because it was an improvement on the Weston design.
> 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.
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.
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.
> The greatest problem with the Wayland protocol is how much work a compositor has to do.
Sounds not like a very modular/orthogonalized approach, and also limiting the choice of the user.
Sounds not like a very modular/orthogonalized approach, and also limiting the choice of the user.
It is as modular as any compositor wants to make it, for example Weston has a plugin system.
Regarding the issue of "choice", please read this page: http://www.islinuxaboutchoice.com/
Regarding the issue of "choice", please read this page: http://www.islinuxaboutchoice.com/
I mean, if you allow every compositor to implement its own plugin system, then you end up with a lot of fragmentation and you effectively lock the user into one particular compositor.
So then you have to come up with a plugin system which everyone wants, which is probably not even possible because the definition of "plugin" is so vague that it could mean anything. If you ask me, fragmentation is just the default state of things in open source.
Yes, the default state is the state you get if you don't put any work into it. It is the "easy" state. Defining a good plugin system is not easy, true.
I remember at the time the Compiz developers were trying to get everyone else to either base their compositor on Compiz, or build in support for Compiz plugins. That might have been feasible if there was a working design, but Compiz plugins were very hacky and the code was a mess. IIRC the only desktop that actually did it was Unity, and that was discontinued. So you can see some of the troubles with that approach.
Mandatory link to https://arewewaylandyet.com
Now that distributions mostly default to wayland and pipewire I feel that the linux desktop is in a solid place.
Now that distributions mostly default to wayland and pipewire I feel that the linux desktop is in a solid place.
This, everyone claiming that "Wayland butchered everything" are just unwilling to accept that Wayland is already more than 10 years old
The fact it took more than 10 years for an alternative display server to be semi-usable is indicative of how much of an uphill battle it was and continues to be.
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.
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.
> Switching to Wayland today means replacing most of the apps you're used to already.
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.
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.
> Most old applications continue to work fine through xwayland
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 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.
> The fact it took more than 10 years for an alternative display server to be semi-usable is indicative of how much of an uphill battle it was and continues to be.
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.
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.
I'll switch to Wayland as soon as Wayland works better than X in ways I care about, namely performance. I get 25-50% more FPS in games using X than 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.
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.
> 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.
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.
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.
>And second system syndrome too probably
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.
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.
> In my opinion, Wayland has avoided this by deliberately being simpler than X11.
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.
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.
> The core protocols are very poorly documented,
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.
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.
>Wayland is not really simpler than X11 unfortunately.
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.
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.
> 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.
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.
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.
>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.
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.
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.
> 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.
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.
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.
Sure, you may not have heard of it. But it is a thing that can happen and is not possible to fix without changing (i.e. breaking) the API. X11 does not have a mechanism to fix it, that was never added.
> 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.
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.
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.
But you can still fiddle. Unless I missed something, the only complaint here is that the method of fiddling has changed.
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.
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.
Are you arguing against the value of a command line interface in the Linux world?
Command line is appreciated because of its simplicity and composability. The ability to automate and integrate with a huge ecosystem of compatible tools.
Is this really a debate still worth having?
>The ability to automate and integrate with a huge ecosystem of compatible tools
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.
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.
I did document administrative procedures as click here, click there, check that box, click there again. I also document them as commands that can be copy / pasted, even on my laptop. I'd say that GUI administration of a local machine is nice for casual tssks, but a waste of time for repetitive tasks and when I feel that I might need to do it again in future. A command line is much more reproducible. It's dconf vs gsettings.
But that is where you hit impedance mismatch. Some things that are easy to represent in a GUI (because they are graphical tasks) cannot be easily represented in a command line tool. XRandr is probably the worst example of a scriptable tool because you have to manually type in the coordinates and screen sizes which is at odds with how you would configure a graphical screen. If you want to set them based on some logic or calculations, you are better off reaching for a python script or something that is actually pleasant to write code in, and then use that to invoke the real API, not command line tools.
I didn't touch xrandr much in my life (I'm not the OP) and I don't know which APIs are available so I don't know if they are pleasant or not, but wouldn't I write coordinates and screen sizes in Python too?
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.
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.
Command-line interfaces do not have to be text-stream based.
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.
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.
Making a command line interface that outputs binary is even worse than a text stream, because then it cannot be used interactively at all, and that defeats the whole purpose of a command line user interface. At that point you are making tools for programmers, and are better off letting them reach for a real programming language and an API.
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.
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.
I had specifically Powershell in mind, which is object-oriented and absolutely can be used interactively.
> 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.
> 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.
> Exactly. Like, holy moly did the people working on Wayland get carried away by the mobile OS world.
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.
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.
>I get 25-50% more FPS in games using X than Wayland.
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.
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.
"Wayland devs" absolutely don't care if you switch or not. I don't get where this entitlement is coming from.
I feel no entitlement, I'm happy with what I'm using already. I do however perceive a vague desire from Wayland advocates / developers that I stop using what I like and get with their program. But I won't until it works better for me.
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.
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 is no entitlement.
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.
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.
I like this take:
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.
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.
All of my communications with Drew in the past have been amicable, although we never discussed Wayland specifically. I don't know who burned him out but it wasn't me, so you're barking up the wrong tree.
The only Wayland problems I face are all nvidia related. I brought that on myself when I bought team green.
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.
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.
Same here. I have an AMD 5500xt that has no issues with Wayland or X11. I upgraded to a 3080FE and Wayland is unusable and X11 is buggy as hell. It's so bad I'm tempted to ditch the 3080 and switch back to an AMD card once the next gen cards are available this fall. I fully blame Nvidia for this situation.
> 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!).
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.
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.
The last I heard, Wayland doesn't support remote rendering and it's considered out of scope. This is a critical feature for me, which leads me to hope the answer is "never."
remote rendering in X has been unusable for anything more than simple applications for over a decade.
try using firefox over X forwarding in 2022.
try using firefox over X forwarding in 2022.
It was a fine idea in Motif days when X was drawing lines and rectangles. These days it receives ready and extremely heavy bitmaps from applications, so anything besides writing to shared memory gets pretty slow. I wonder why you'd want to send this over network without efficient video compression like screen-sharing tools do.
This isn’t remotely an issue on gigabit links, where I use it. Not sure how much of a problem it is at lower speeds - it isn’t my go-to solution on the public Internet.
I am sure you can understand how that is a contrived situation if you are trying to test and deploy a general-purpose network application. In every other case with lower speeds it is a horrible option, the bandwidth usage is unacceptable.
There is nothing contrived about it. This is my daily reality. I have more than a hundred sites, each with hundreds to thousands of Linux servers, none of which are connected to the Internet.
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'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 use Firefox over X forwarding all the time (pretty much every workday) in 2022, and it works fine.
I have not had a problem with any application thus far.
I have not had a problem with any application thus far.
Glad to hear it is possible, but I need it to be default and correctly configured on all Wayland installs to be useful.
No, you can just install it if you need it. It is just another package, there is no special reason it needs to be default.
Many of us work in worlds where we absolutely cannot just install packages. Solutions that aren’t default are solutions we can’t use. And X forwarding is available by default - losing that is regression.
If you cannot install any packages at all without major hassle, then I think you would have a lot worse problems in many other areas besides this. As I said elsewhere in the thread, X11 is also a horrible remoting solution, pretty much worse than every other possible option in every way. 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.
> then I think you would have a lot worse problems in many other areas besides this.
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.
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.
That was my position too, but I was recently told there's a tool called waypipe that is supposed to solve this. Haven't tried it yet, though.
X11 forwarding is not even the best option for remote rendering on X11. You will get better results with VNC or NX/Xpra.
I guess it depends on what you mean by "best."
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.
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.
That is how all other remoting solutions work. X11 forwarding just happens to be the worst one.
No other solution I am aware of meets that criteria, happy to be shown otherwise.
I mentioned three solutions. In general you can make a lot of things "just work" with SSH, by using port forwarding.
id use it if it my apps would remember their window positions. that seems to be offloaded in wayland and it drives me nuts
I used to think 2025 tntio this year started but now i believe 2027 at the minimum, and 2030 if recession hits.
One first thing that has to be fixed is screensharing. Wayland users are really suffering.
Like when you are in a meeting and want to share your full screen with Google meet.
I think that just requires enabling a flag in chrome settings. Slack and Google meet are how I and sharing my screen when I need to.
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.
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.
You can force that now: https://wiki.archlinux.org/title/Zoom_Meetings#Wayland_scree...
Much easier than before where you had to change environment variables for that to work.
Much easier than before where you had to change environment variables for that to work.
I already love the arch wiki, but I love it even more. Thank you!
Don't know what google meet uses (never touched the thing), but anything relying on WebRTC should work fine. I use it almost daily.
https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar...
https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar...
I'm using Wayland on my laptop right now, and have been for months now. There are a few oddities here and there, but for the most part it works perfectly fine.
It's very clear to me that Wayland will be broadly supported on the year of linux on the desktop.
There 2 major software achievements may be all we need to finally get fusion (or economically efficient solar power) + economically efficient carbon sequestration
There 2 major software achievements may be all we need to finally get fusion (or economically efficient solar power) + economically efficient carbon sequestration
When it works with Zoom screen sharing
firefox is still full of nasty rendering bugs (menus) which I believe are happening only on wayland, though i'm too lazy to check
I switched to an Linux a year ago from MacOS, and Wayland to me is good enough on a hiDPI display. The only issue has been with electron apps but that's been getting fixed.
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.
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.
Supported where? Wayland's original target platform were in-vehicle infotainment systems. I unfortunately have no clue about those. If we're however talking about FreeBSD desktop, I'd say Wayland won't become "mainstream" at least until Nvidia decides to support it in their driver.
For creative applications, it's still missing support for colour management. Work is underway to implement it but it's a complex topic.
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.
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.
Well, the cool thing about it is that you can really easily install X and Wayland at the same time and just test your experience in Wayland or hack on the configs in your spare time. I was on X with dwm and I installed sway to test it. In my case, I never switched back. All my initial problems could be solved with configuration.
I don't fully understand https://doc.qt.io/qt-6/wayland-and-qt.html but it would seem they have the fundamental support for wayland in place.
Wayland will stop sucking when distros and Wayland developers stop dismissing these concerns by comparing them to people who didn't want to adopt systemd.
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.
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.
Well, one of my daily annoyances is having to put up with Qt apps not taking on the right GNOME theme under Wayland (especially window decorations), and that has been going on since forever, so… I don’t expect that to be fixed anytime soon.
(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…)
(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…)
That unfortunately is a Qt bug, not specifically a Wayland bug. An issue should be filed there if it is not already. But, it is not likely you will be able to correct it for every app, because Qt apps can technically do whatever they want with their own theme and override the system theme.
GNOME's regards towards theming is precisely because of things like Qt themes being broken all the time.
GNOME's regards towards theming is precisely because of things like Qt themes being broken all the time.
Wayland is broken by design (https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-x...).
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.
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.