Libwsm: Wayland Security Module library for Wayland compositors
github.com
github.com
It's so so so frustrating the current state of Wayland fragmentation. X11 wasn't secure, but at least it worked.
Personally, I can't wait for the transition to finally end and for the Wayland ecosystem to achieve similar levels of maturity to X11. I've been donating to marcan's Patreon since the M1 was announced, and now that I own an M1 I intend to switch (back) to Linux when and if it becomes clear that everything will work smoothly (in terms of both hardware support and desktop Linux/Wayland in general).
X is cool and has the cachet of being such a venerable piece of software, but it needs replaced. If you actually talk to people who hack on X you'll find (for example) that it's been client-server in name only for quite some time, is full of kludges, etc.
Wayland has been around for what, 12 years now? It's still a disaster.
When will the Linux community admit that Wayland has failed and move on to something simpler/less ambitious?
Define disaster. Because it's been working fine on my machine under Gnome 3 for years now and now that we have PipeWire that includes everything we could do before working in a nicer way.
I don't know why people comment under post about abandoned very technical library like if they were in any way significant.
Wayland just works. Just install Fedora or Ubuntu. It ships by default.
Firefox is still X by default, meaning to me most significantly no high-DPI support or precise scrolling. You can force it to use Wayland via the MOZ_WAYLAND_ENABLE environment variable, but it still has definite issues, like popup windows not being marked as popups, with effects like notifications being added to the non-floating windows and taking focus, rather than floating in the corner of the screen undecorated. (I use Nightly and am test-driving the process-per-site thing and it’s currently got other issues that are probably Wayland-specific, but that’s what you get for using prerelease stuff.)
Audacity has utterly crippling issues when run Wayland-native (its default). So I have a wrapper script that first clears the WAYLAND_DISPLAY environment variable so it will use XWayland, where it has fewer issues (it’s still pretty bad in places, e.g. all popup windows are start out at the minimum possible size and have to be resized before you can interact by anything other than keyboard, but I’m running high-DPI XWayland patches and I suspect this is at least partly due to bugs in that).
Krita I need to set QT_SCALE_FACTOR to match my XWayland scaling (a high-DPI thing). Note that I can’t set this globally, or else Qt apps that can run under Wayland (e.g. Zeal) will be huge.
cq-editor (CadQuery) crashes in Wayland and must be run with `--platform xcb` or with WAYLAND_DISPLAY unset. (Upstream’s distribution is built against a Qt that is not Wayland-enabled, so the problem actually doesn’t arise there, but if you build your own it’ll probably be Wayland-enabled.)
Zoom has taken to crashing on joining meetings under Wayland, and only implements some GNOME-specific screen sharing rather than xdg-desktop-portal screen sharing which is, I believe, what everyone else settled on—showing the internal fragmentation problem of Wayland. So because of the crashes, I run Zoom under XWayland, not even losing screen sharing because it was already broken. (Firefox and Chromium do screen sharing without any trouble, but only of whole outputs, not individual windows.)
But on the other hand, a few days ago I started i3 so I could do screen sharing on Zoom (of a second display, HDMI-A-1, 1920×1080@60Hz; main display eDP-1 being 2560×1440@165Hz), and ugh, the tearing! Full screen updates in Alacritty pretty consistently do the top half in one frame and then the bottom half in the next frame, and the block cursor moving while typing is super glitchy. I had forgotten how bad this stuff was because Wayland does it perfectly.
Weird cobbled together configuration using esoteric softwares will always have weird issues and things working like they were cobbled together. Just use a properly supported and cohesive desktop environment and everything will be fine.
I believe the problems listed with Firefox, Audacity and cq-editor would apply to any Wayland compositor. I will note that once you’ve done MOZ_ENABLE_WAYLAND=1, the remaining Firefox problems are likely to be significantly less obvious in a non-tiling, purely-client-side-decorations window manager. That doesn’t stop them from being bugs.
For the Krita one, in a high-DPI environment you’ll either need to use unsupported patches on XWayland and worry about QT_SCALE_FACTOR, or use the stable version and get a terrible result that will be nigh unusable for certain purposes (though normally you’ll just call it ugly and annoying); whereas if you use X right through, you can have proper high-DPI.
The Zoom crash, who knows; I certainly don’t, since they don’t make it easy to inspect what’s going wrong. There’s a good chance it’d work properly under at least GNOME.
For comparison, under i3 I don’t think I ever experienced general issues like these (that would apply to all WMs), and experienced WM-specific issues only a few times, minor and workaroundable each time.
The distinct impression I’m getting is one of immaturity. I’m still using it, because it does solve a couple of things that X didn’t do well that I consider moderately important, and more importantly because I’m an intrepid idiot willing to put up with a lot in the name of daily-driving the future to help iron it out for others. (As another such thing, Firefox Nightly has been my daily driver for just over a decade except for a cumulative total of about a year.)
Firefox is esoteric nowadays?
https://lists.freedesktop.org/archives/wayland-devel/2014-Fe...