Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.

I would like them to keep that behaviour. At least make it an option or allow whitelisting certain applications. Nothing I hate more in an OS than windows stealing focus without asking.

What are the not-a-bugs? Things like covering up a Wayland window will block it’s rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private. Every game dev on the other hand is asking “WTF!?” as it causes their games to break randomly

Please don’t make up what “Wayland core folks” think. You don’t know it, and your claims are waay off.

It’s not about security. It was intended to allow the compositor to throttle apps to improve efficiency… Which of course in practice doesn’t work like this at all, because OpenGL swap buffers and Vulkan FIFO presentation modes were never intended to be used this way.

As for why that hasn’t been fixed yet, it’s not as big of a problem anymore:

• Mesa (at least for Vulkan) and Xwayland gurantee one frame per second as a minimum refresh rate
• toolkits and libraries use mailbox presentation internally and check frame callbacks themselves for when to render
• xdg shell now contains a flag for apps to know to inhibit rendering because they’re hidden. That doesn’t guarantee that presentation won’t otherwise block though
• a (set of) protocol(s) is being worked on to replace frame callbacks with a mechanism actually suited for OpenGL and Vulkan

Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.

That’s not even close to how activation works on Wayland, and no, it’s not just a security thing, it’s a usability thing. Apps can only raise themselves if the currently focused app gives them focus, so that random apps can’t cover up what you’re working on just cause they need to show you an ad or an “important” pop up question or whatever. If it doesn’t work for a specific app, make a bug report about it to the app.

Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private.

I do like that. I have encountered a number of bullshit things like HR mindless training videos (ok, the fourth time I’ve seen this guy contemplate accepting a bribe… I get it. Don’t accept bribes! Leave that shit to Clarence Thomas) or ad playbacks that refuse to proceed unless they are focused. It’s annoying as hell. The problem you point out also sounds really annoying.

Who even uses screensavers these days?

The article is 3 years old and some things are only presently being fixed NOW and due to filter down to stable distros in 2024. Furthermore wayland proponents have been claiming its totally ready for prime time and not broken at all since 2015 while promoting AMD GPUs that at that point in time still sucked hairy balls.

I would argue that promoting Wayland as production ready is still premature considering the number of excuses Wayland proponents have to make who is at fault for Wayland’s shortcomings (Nvidia seems to be a big one but people who have needs the short-sighted protocol design didn’t account for are a close second).

The problem, as I see it, is that the author of the original Gist does not really want wayland replacements for what he has, but rather what he has to also work on wayland.

Wayland didn’t break everything. It broke what relied on X11 specific stuff, which turned out to be a lot of things. The vast majority of issues still present with Wayland are edge-cases that will only see the light of day when the people with those edge-cases start using wayland. And as long as distros default to X11, that won’t happen. So that distros, like Fedora, started defaulting to Wayland “early” on (yes I put early in quotes, because it’s only perceived as early) is actually a good thing. Makes the compositor developers aware of edge-cases they can’t catch themselves.

I’vge been using Wayland exclusively for over a year and apart from a couple of small bugs, not even missing functions, I haven’t experienced any issues relating to Wayland directly. But that’s for my use case. YMMV as always.

The main issue here is not that some of the issues that are mentioned there are not genuine. They indeed are genuine and have mostly already been notified to the devs working on the protocols and the compositors. The issue here is how those are presented. By creating this almost cultish “battle between the 2 display servers” thing is not productive and demoralizes developers. Making criticism is one thing and productive but “boycotting” is not. And certainly not in the bad faith way the author of that article has done. I myself have both X and WL setups and I alternate between them frequently. I am not sitting here “boycotting” one display server in a prejudiced manner. This is Linux, not Windows or MacOS. Users are free to continue using Xorg and develop it according to them if they do not like something else. And similarly, they are free to use Wayland.

I didn’t have a great experience

Neither did I. I use Qtile, and I’m waiting for some things on Wayland to improve. It’s close, but not there yet.

No, running sway with the --unsupported-gpu flag launches it without any remarks about your hardware. It’s been like this for a good while.

Oh yeah, I forgot about the work on Plasma and QT6.

I didn’t know that about FreeBSD. Will add it.

FreeBSD’s Wayland support is through a Linux compatibility library. The major Wayland implementations are Linux only and there’s no way around it other than implementing Linux libraries like FreeBSD did.

removed by mod

Because it is the replacement for Xorg and X11 as a whole. This is like expecting all Unix applications to work on Linux. No, some things need to be ported or rewritten. I don’t want to force adoption of Wayland. Heck, I’m on Xorg because Qtile’s Wayland session is missing a thing or two I need (they’re in development but not there yet). I’m just tired of people pretending this article is accurate and up to date so I wanted to set some things clear. Granted, I didn’t do it that well, but I tried.

Also, whoever calls Wayland X12 is lying to themselves and everyone else. The only way in which such naming would make sense is if you consider the fact that the X11 maintainers (pretty much all of them RedHat employees) were sick and tired of maintaining it, so they started Wayland to replace X11 (NOT as a drop in replacement, mind you). So the only way such naming wpuld make sense is if you consoder the fact that Wayland developers and maintainers were the same people that were maintaining Xorg until they just gave up.

Because the people who developed X11 (that is Xorg) haven declared that. Maybe they should have named it X12, but they didn’t for whatever reason. However the people doing the work have already given up on working on X11 they gave up on X11 beyond the bare minimum almost 10 years ago because some real issues with X11 as a protocol are not fixable.

There were other attempts to a successor to X11, but they never got the support of people doing the work on X11 (in part because they didn’t understand the problem with X11 and so kept many bad things while ‘fixing’ things that were not broken)

Which is to say: you have two choices: get involved with continuing X11 development, or jump to Wayland. Throw a couple million $$$ per year at X11 (either pay developers, or convince a dozen developers to maintain X11) and I’ll retract my statement, until then X11 is dead. If you cannot do that then Wayland is your only option.

Yeah, I was going to ask if the Wayland protocol included some Linux-kernel-specific data structures or something that would make it somehow more awkward to implement on non-Linux kernels or something.

Like if I created a protocol that included sending data encoded using the Python serialization framework called “pickle”, one could say that was a Python-specific protocol in that while it would be possible to use that protocol from other languages, it would be very weird and awkward to do so at best.

Not really knowing much about the specifics of Wayland, I wouldn’t truly know if there could possibly be anything Linux-specific in Wayland. But as far as I know, it’s entirely possible theshatterstone54 knows something I don’t.

What they are talking about is that some of the Wayland compositors rely on things like libinput and libdrm which are Linux specific.

This is not “Wayland” really but, from the point of view of a regular user, it may as well be. As the OP points out, there is no /usr/bin/Wayland

It is not really a great criticism although it must be frustrating for the BSD folks and others. Of course, the answer like always is to contribute. Nothing stopping anybody from taking wlroots ( or whatever ) and adding abstractions that make it more portable.

Non-Linux operating systems have already added Wayland support ( like Haiku ). If I had the time, I would add it to SerenityOS myself.

Actually, if I had the time, I might write a WaylandServer for X. First, it would be funny. Second, the people that do not want to move could stay on X forever even when everything stops supporting it. I would have to make sure that my WaylandServer could run XWayland of course.

As for “wayland does not work properly on nvidia.” Solely nvidia is blame.

Nobody but Wayland apologists cares who is to blame. If it doesn’t work on their hardware that clearly is an issue with the idea that Wayland should completely replace X11/xorg because out of Wayland and Nvidia if one of those two goes away it will be Wayland, not Nvidia.

Good to know

No problem with GNOME and hyprland here, on 2 different laptops.

Dual monitor? Wayland on my intel works fine for single screen, but as soon as I plug in a 4k monitor, it gets black cube shadow like artifacts in KDE Plasma 5. A couple of kernel command line options for the module has not helped, either.

Well, I’ll agree with you. I’m okay with them being a thing that exists, as long as I can disable them.

removed by mod

For some reason I had assumed that this would easily be handled by Java’s write once run everywhere paradigm.

There are some hacky methods to make some Java software use Wayland. Iirc, https://github.com/openjdk/wakefield is the jvm version I used to test it on Minecraft and Mindustry. I did not really get that far, but it has been quite some time since I tested it so I do not remember exactly what the results were. Otherwise it is possible the subjected software itself needs extra editing to make it work on Wayland.

Yeah, I don’t know about Java. I often switch between X and Wayland myself, but I’m mostly on X because I use a tiling window manager (Qtile) which has a Wayland version but is still ironing out some issues before I can switch full time.