It is a shame that it takes a seriously long time to properly replace 30+ years of hacks on hacks.

But I don’t think the answer is to not try; people use Waylands lack of support for things to justify not using it which then means there no testing or development of those things.

I am somewhat in favour of the wayland devs being a lot slower to the punch, because understanding the problem properly and creating a somewhat clean solution takes time by itself, and writing the software to do things the clean way (screen readers for example) also takes time and effort.

I am reminded that in the c64 days people would poke random memory addresses and it was normal. Protected mode in Windows was a huge step back for many developers who were used to just writing arbitrary bits to memory.

I’m not saying we should abandon everything for progress, it’s good to be critical. But in this case I think the critical eye is only really focused on preventing change, which as many people point out is sorely needed.

I’m not saying Wayland is perfect as-is or accessibility shouldn’t be fixed. That’s a total straw man.

Every post that even touches on Wayland in the smallest way gets flooded with “Wayland sux, just keep developing Xorg” posts.

Xorg is not getting useful/meaningful/future focused development. The fact new commits exist doesn’t mean it’s a healthy alternative.

I just happened to see this post yesterday and thought it was a pretty good summary, if pithy, about the state of X vs Wayland. I don’t blame them for being mad about people continuing to beat this horse.

It must feel a bit like if people continuing to demand that we give up on electric cars and go back to developing leaded gas.

I didn’t say you said it is perfect, so if there is a strawman here it is one of your construction.

I think I will not try to defend Xorg, as I don’t really even like it, and as you note the topic is kind of beating a dead horse at this point.

As if linux was so good at accessibility before that.. as one ex-X-maintainer once said: “there is only so much lipstick you can put on a pig before you question why you try to make it fly” (I may be butchering up the quote).

Does Zoom even support Wayland or you are running it through XWayland? All these proprietary clients usually have a lot of inertia with implementing Wayland support.

Zoom supports the xdg-desktop-portal for screensharing as of semi recently.

Sway's screensharing portal (via xdg-desktop-portal-wlr) only lets you share a full monitor at a time. You cant only share a screen region or a single window, so YMMV.

Some of the big proprietary clients have their own devs using linux. Devs tend to be that type of person, so them pushing for upgrades to tools they themselves use isn't too surprising. Discord just recently released an official flatpak and cited internal dev teams as a reason.

KDE should support desktop portal better. It works fine with OBS for example in the Wayland session for screen recording of individual windows.

Does Discord support Wayland at all? I've heard a bunch of related complaints from people using its native client.

I run it as a Wayland client since a year or so now.

The only problem I know of is that screen sharing does not allow you to select an audio stream which has already spawned multiple hacks / modded clients over the years (and might also apply when running as a X client IDK)

I haven’t the slightest clue, it is a terrible program and I just wanted to do the minimal to get it working. Switching to X11 meant I was able to waste fewer brain-cycles thinking about Zoom.

For what it's worth, Zoom has worked well enough in the browser for me every time I've been forced to use it.

The thing is, in a reasonably designed replacement that shouldn't matter. Requiring applications to update to the new thing just to keep working is absurd.

Reasonable applications would use something like SDL to abstract it.

But it depends on complexity. Wine for example implementing Wayland support is a big deal and it's not trivial.

Using SDL is a good idea but it isn't a stable interface either, e.g. SDL 1 programs will not run with SDL 2. SDL 2 is also not something you can rely on being installed, you generally need to ship your own copy and even if you want to rely on distro packages you will need to adapt your code eventually as old versions are purged. SDL is also not a reasonable abstraction for all kinds of applications as it is focused on games and game like use-cases.

Backwards compatibility really should be the primary focus for anything looking to replace a system component. We do have Xwayland for that but its an incomplete solution by design as X clients won't see non-X windows nor can they capture the whole desktop.

Anyone with more complex cases like Wine can work with Wayland directly. Wayland protocols are pretty stable. If they care to support X too they'd need two paths.

But something like freerdp for example managed to do it with SDL well enough.

SDL of all projects actually did think about translating older ABIs to avoid breaking changes. I.e. there is SDL 1 over SDL 2 helper. It would be nice to see more of such efforts on Linux.