Item — HN Reader

What's an example of an X11 program you're having troubles with?

I just tested this with Wireshark and rest of the desktop. In fact, there is a built-in shortcut Ctrl+Alt+Shift+R which starts a screen recording and dumps it in the home directory. Worked flawlessly!

3 comments

Zoom. I can't share my screen. If it works, it has way less options than in x11.

You can't share a display or app, only a region.

Autokey shortcuts don't seem to trigger on Wayland, works with x11

Parcellite, I can't make it show up with shortcuts.

Those are the ones that made me revert to x11

The Zoom issue is related to the API they chose to use on Wayland. There's an API for sharing stuff like screens and windows, but Zoom is calling the GNOME (not even standard) screenshot API in a loop instead. As you might expect, that doesn't exactly work smoothly; performance is lacking and window coordinates would need to be tracked manually.

There's a whole thread about it here (https://community.zoom.com/t5/Meetings/Wayland-screen-sharin...) but I don't think Zoom cares enough about their Linux client to fix these issues.

I don't know about the shortcut issues you're facing, my guess would be the key logger protections built into wayland prevent your shortcut daemon from capturing the necessary keys. Autokey certainly runs into that problem (https://github.com/autokey/autokey/issues/87). Other programs seem to get similar features working, but not everyone had the time or expertise to bring out compatible versions of their software.

As someone mentioned, looks like https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar... solves the screen casting issues.

You can’t take a screenshot is different than Zoom not being able to.

You basically can take screenshots/record your screen in every major wayland compositor. On the other hand, screen recording by applications require interfacing with pipewire, which is pretty much done by many programs (including chrome (and thus electron), firefox, obs, etc), but plenty electron apps do not use the necessary flag.

If you don’t want to tinker with rebuilds I recommend using the web version of zoom in an up-to-date browser.

> On the other hand, screen recording by applications require interfacing with pipewire, which is pretty much done by many programs

And why doesn't xwayland support it out of the box? Is crippling existing X11 programs intentional or is it just an inherent limitation of the way wayland works?

Because seeing other windows is a fundamentally privileged action. Also, the implementation of xwayland is basically a nested X - so by using the X screen recording api, it will simply see other X windows.

The problematic one was called "simplescreenrecorder", I wanted to record an area or window. I couldn't get the inbuilt screen recorder to work using the shortcut. But perhaps it was not mature enough yet.

Security, X11 has a unfix-able problem with keylogging/clipboard scrapping and running less trusted applications making it somewhat incompatible with "proper" application sandboxing (what flatpack, snap might become). There are workarounds but they have other problems. (And yes I know we are not quite at the "proper" application sandboxing point yet).

A common misleading counter point to this is, that you can still keylog easily under Wayland using non-Wayland specific means. But this is a stupid argument IMHO, as if you don't start improving things you will never reach the goal and all the "key logging alternatives" are non DM specific and as such need non DM specific fixes (which already exists btw. just aren't often setup by default).

Then there are docents of improvements for developers, like the X11 code base is close to being unmaintainable (from what some of the X11 maintainers say, but I forgot who did so).

There are also improvements for a bunch of features you likely won't care about as a normal users, around multi-seat setups and some embedding specific stuff.

Or implementation details only relevant for people implementing the Wayland compositor.

Theoretically there can be performance/latency improvements for modern applications running on modern hardware. Practically this depends on the hardware/driver, Wayland compositor implementation and client program.

Also by now Wayland-only programs already start to pop up. For now mainly for some special purpose applications, but it's just a matter of time until this can become a problem for some users, needing to use some specific software.

Weather people like it or hate it, X11 on Linux is dying. Wayland will replace it. Incremental improvements will (and often already have) remove many of the limitations people have with it.

I don't see a successor for Wayland for years to come (for normal desktop usage). Through I guess there could be some "label" like "Wayland XXX" which is just the same Wayland but requiring more of the optional available protocols to be implemented. I think currently there is some form of living (incremental improving) standard of standardized Wayland protocols compositors "really"-should implement.

Already now I feel a lot of the complains fall into 4 categories:

- outdated, was fixed quite a while ago

- "my" X11 specific tool doesn't work under Wayland (but there is a Wayland specific tool which has nearly the same features but "I" don't care because "I" don't want to both switching over/porting my config).

- Ubuntu (somehow it really often pops up when people have problems with Wayland)

- fractional HDPI (got already better, will still get better)

I hope in the near future we will be left with only (mostly) the first two categories.

EDIT: Also with how PipeWire develops it's just a question of time until all kind of multimedia/audio/streaming/screen sharing applications will just work much more smoothly on Wayland with much less work required from developers of applications using/managing it.