←back to thread

Are We Wayland Yet?

(arewewaylandyet.com)
96 points picture | 3 comments | 07 Jul 22 22:22 UTC | HN request time: 0.819s | source
Show context
Silhouette ◴[07 Jul 22 23:20 UTC] No.32020958[source]▶
IMHO the most frustrating thing about Wayland is how it's fracturing the Linux landscape again.

For example Ubuntu switched to using it by default a while back. Unfortunately since Wayland prevents the usual screen sharing in many popular communications applications from working I usually have to go back to X in order to do any real work remotely.

Combine that with some significant bugs that seem to happen in recent versions of Ubuntu/X but not Ubuntu/Wayland and now I have no fully working GUI on my Ubuntu machine because both options now have game-stopping problems.

I do understand that there are good reasons for Wayland wanting to do what it's doing and breaking the old-fashioned screen sharing is a consequence of those. I understand that applications should be updated and other packages should be used and so on. I hope that these issues can be fixed sooner rather than later and we can all benefit from the technical advantages of Wayland.

But if I'm in a conference call with important people about an important subject you can count the number of excuses I care about on the fingers of no hands. Wayland won't be ready for "normal" users until essential functionality works out of the box.

replies(1): >>32021181 #
cowtools ◴[07 Jul 22 23:46 UTC] No.32021181[source]▶
Do you have xdg-desktop-portal-gnome installed?

Screen-sharing is working out of the box for me on both gnome and wlroots. File a bug to your distro maintainers if it doesn't.

replies(2): >>32021393 #>>32021412 #
smoldesu ◴[08 Jul 22 00:15 UTC] No.32021412[source]▶
Part of the problem, as I understand it, is that the onus is now on each individual desktop environment to provide it's own implementation of screensharing. If Wayland made this an optional, standardized feature, maybe downloading packages and checking with our distro maintainers wouldn't be a part of this.

Overall, this is one of the big architectural things that is horribly wrong with Wayland. Not offering a "batteries-included" path for everyone still using legacy systems is going to destroy adoption rates once you start looking outside the hobbyist crowd and towards enterprise/LTS markets. I get why you'd want to keep these components separate, but there's really no point now. Nobody is using this code as a module, they're simply re-implementing the same thing into different desktops over-and-over again. It's one of those rare moments where Xorg's monolithic codebase isn't a detriment, for once.

replies(1): >>32021848 #
cowtools ◴[08 Jul 22 01:16 UTC] No.32021848[source]▶
I'm not sure I completely agree. You have a middleground where smaller DEs (wayfire, sway, etc.) huddle around larger "hub" implementations of wayland like wlroots in the same way that X11 DEs used Xorg.

It's really only the larger DEs that will want to roll their own compositor like GNOME/mutter. Wayland allows them to do that in a feasible way, but it doesn't force them to because they can use something like wlroots.

replies(1): >>32021899 #
nsajko ◴[08 Jul 22 01:23 UTC] No.32021899[source]▶
The information you present is completely consistent with what smoldesu said.
replies(1): >>32021965 #
1. cowtools ◴[08 Jul 22 01:33 UTC] No.32021965[source]▶
Maybe I should be more specific:

>the onus is now on each individual desktop environment to provide it's own implementation of screensharing

wlroots-based DEs can simply use wlroots' screen-sharing implementation for example.

The wayland equivalent to the smaller DEs that relied on Xorg to reduce their complexity and maintenance is just smaller DEs using wlroots or similar.

The larger DEs like Gnome and KDE will have no problem bearing the onus of implementing wayland themselves. I've had it screen sharing working perfectly on gnome for the better part of a year already.

replies(1): >>32023064 #
2. smoldesu ◴[08 Jul 22 04:15 UTC] No.32023064[source]▶
wlroots is really not that mature, and it's sort of a too-little-too-late situation. A lot of DEs are just never going to get around to switching to Wayland, but that doesn't mean they're going to stop development either. That's a pretty considerable fragmentation that people shouldn't take lightly.

My example of a project doing this well is PipeWire. They looked at the Linux audio scene at the time (arguably worse than xorg on many accounts) and created a replacement that both supported old paradigms while simultaneously promoting lower-latency, higher-quality ways to connect. Wayland should have taken the same approach: it's never going to kill it's past, so it may as well adopt it. If I could use Wayland as a compositor while keeping x11 as my window server, I would. I wouldn't get the "full security" of Wayland, but I'd be onboard with their project if the maintainers weren't so allergic to user choice.

replies(1): >>32023546 #
3. kaba0 ◴[08 Jul 22 05:16 UTC] No.32023546[source]▶
That’s why Wayland has XWayland for seamless backwards compatibility with X applications? That’s pretty much the equivalent of a PA sink in PipeWire.

I don’t see how your supposed compositor/window server hybrid would solve any of the problem of the past - what would even be the task of wayland there? It would be what kde plasma does with its compositor.