It's like the python3 adoption story again. Wayland compositor with hw acceleration doesn't work well with programs specifically written for x11. I gave up on it fast once I realized that I can't take screenshots or record the desktops.
Screenshots and desktop recording has been supported since years.
Initially with non-standard Wayland protocols (so it was quite hit or miss wrt. which capture programs worked under which Wayland compositor).
Since a while there are now standardized ways using PipeWire and the desktop-portal interface.
(Through at least a few month ago sway still did only support full screen capture, and not per-window capture (out of the box), but that's not a Wayland but a sway problem. As far as I can tell currently there is simple no one who 1. cares about it 2. wants to implement it 3. has the time/skill to do so. On KDE/Gnome it per-window capture works. On sway it might still work with some workarounds, just not out-of-the box.)
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!
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.
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.
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.
I'm using Plasma on Wayland and there doesn't seem to be any screenshot tool that works properly.
Grim only works on Sway. Flameshot's GUI mode doesn't recognize the secondary screen. Spectacle fails to copy the screenshot to clipboard when running in background mode. KSnip doesn't have a region select mode. Shutter only works in X.
Out of Spectacle and Flameshot, Spectacle is more responsive and works across both screens. I'm thinking I can work around the clipboard issue by having it save to a temporary file, and use `inotifywait` to monitor that file and copy to clipboard with `wl-copy`. I wish I wouldn't have to use such workarounds though.
Specifically, I record the browser window or the terminal window to demonstrate bugs and accomplished tasks for projects. (I don't have to, but it feels like a nice jest and documents things clearly)
Do you know of a program which does that on wayland with hw acceleration? I admit I couldn't do it a few months ago and haven't tried since.
