Trying to give Wayland (on Gnome) a fair shot

My system is all AMD and, as I understand it, that’s a good thing for Wayland. However, here’s a few things I’ve noticed…

  1. Wayland does not seem to permit programs to set global hotkeys. Since I like to use Guake, that’s a bit of a problem but, as a work around, I can set the hotkey through the Gnome desktop settings. Then again, I launched Steam, played a little No Man’s Sky and was able to take a screenshot in-game using Alt-F12 (can’t bind just F12 because…Guake). For that matter, the game seemed to play just fine (though I only tried it for a few minutes).
    .
  2. Wayland does not seem to be remembering window positions for applications. For example, Evolution does not remember that I want it to open on the right side of my screen.
    .
  3. Tray icon support is a bit dicey. Tray Icons Reloaded only works with a couple of them in Wayland, AppIndicator/KStatusNotifierItem does a bit better. The latter also works well with arch-audit-gtk, which I consider the most important since it gives an immediate visual notification if there’s a pending security related update.

Multiple references (including the ArchWiki) are saying Wayland is more secure so it’s worth giving it a look. Still though, it seems there are a few minor “glitches” yet.

https://extensions.gnome.org/extension/4736/smart-auto-move/

^an extension that supports Gnome 41/42 and Wayland support that remembers window screen size and placement for the next time you open it. It works great for me on X11 Gnome 42. But it’s preference handling in the extension settings is a nightmare to adjust since it saves every single window settings, so over time it’ll build up in the extensions settings list. You can enable/disable it on a per app basis, so you don’t need it for every single app. I genereally keep it on all my apps except for the ones like a web browser and my terminal, which I typically want a certain way. Feel free to tinker and see if it’s a right fit for you. Good luck.

1 Like

I should also mention. I also took a look a Wayland on my old “distro-tester” machine (running Fedora). That’s a pretty old PC with a practically ancient nVidia card. On that machine, I get periodic mouse freezes and it just seems to work and play better with x11. The experience overall is much better on my “daily driver / all AMD” machine.

Wayland’s increased “security” is only because they annoyingly restrict or outright remove things. Like the hotkeys example.

1 Like

I’ve been running Ubuntu 22.04 LTS on X11 this past week, though it defaults to Wayland. Since I have a Nvidia hybrid setup, Wayland support has not always been implemented well (yet), but I just did a reboot to test it out. Other than one or two apps that won’t launch because their backends only support X11, everything else appears to be working just fine. This is only from 10 minutes of testing, so my experience may change for better or worse, but at the moment I am cautiously optimistic.

This is done through Steams overlay and only works for Steam games due to how they handle it. If you disabled the overlay it wouldn’t work. You can generally have hot keys within a focused window but they won’t work out of Focus and the programs can’t see/interact with each other unless explicitly designed to and given permission to do so.

If the applications are X11 and using xWayland they may not due to the xWayland session for those applications being destroyed upon exit. That’s my best guess.

The only one that works well AFAIK is KStatus extension.

Wayland increases security by restrictions to how applications can interact with each other. In X11 any application can freely record key presses or can even screen capture without your knowledge for example.

Wayland also drops everything being built directly into it like X11 did to having features be implemented through a sort of plugin system/extensions that can be added/removed. This makes auditing easier and maintenance easier as unmaintained code can easily be dropped as its not core to Wayland.

The common misconception is that “Wayland isn’t ready because ‘xyz’ isn’t built-in” when that’s not exactly how it works. That’s why things like the fantastic Pipewire have come about, to handle things like audio/screen recording. The core of Wayland is meant to be simple, easy to maintain, secure, and fast. The rest is meant to be filled out through extensions and other projects. Wayland is fine, the ecosystem around it is what’s developing the most right now.

1 Like

can even screen capture without your knowledge for example.

I’d rather have smth screen capture without me knowing than constant display glitches and not being able to screen capture.

“Wayland isn’t ready because ‘xyz’ isn’t built-in”

Wayland isn’t ready because a few things.

Wayland isn’t inherently bad, replacing X11 with something modern and secure is great. But what’s not great is

  1. Not every DE supports it (Cinnamon for example)
  2. Everything remotely related to DEs would have to be rewritten, XWayland works but isn’t ideal. Rewriting a bunch of window managers anyone?
  3. Some face issues with screen capturing, display glitches and stuff and that’s not great.

Of course these are all teething issues that will eventually go away as Wayland becomes more popular.

Pipewire is also great.

I’m not trying to say hurr durr wayland good X11 bad (or vice versa), I’m saying here that for now they have to coexist until Wayland can fully supplant X.

IMO, the days of X are numbered and I think in a few years if everything goes to plan then Wayland will replace X. But for now they kinda have to coexist.

My advice? Use what works for you.

Screen capture has been possible on Wayland for some time now, one of the Gnome devs specifically worked on it for well over a year. I havent experienced any display issues, but i cant be for sure on what others experience as i dont have their hardware.

This is a silly argument, this isnt Waylands problem if a DE doesnt support it.

This also isnt necessarily on Wayland as much as an issue of adopting newer technologies in general. Replacing X11 with just a drop in isnt feasible to my knowledge due to problems with X11 and its age/complexity. This isnt necessarily even an issue with X11 or Wayland but a lack of foresight in early Linux/X11 days that lead up to the situation we have now, but as they say hindsight is 20/20. X11 is not fit for the modern desktop and threats that they face.

This i have to wonder are we blaming Wayland for Driver or hardware issues? Linux frequently is missing workarounds for a lot of hardware that windows has, how much of this is on Wayland and not on the hardware/drivers?

This is fine enough, nobody absolutely has to use X11 or Wayland. The thing is that people need to understand though that Wayland cant be X11 because its specifically designed to not be and it never will be. If the benchmark is for Wayland to be X11 but newer then it will NEVER be ready as it wasnt designed to be that in any capacity.

On another note maybe we shouldnt derail OP thread too much in case there are some good questions/answers to be had lol

1 Like

I know most of these issues aren’t Wayland’s fault, what I’m trying to say is

  1. Don’t expect X apps to work perfectly
  2. Some things just don’t work.

If it works on X11 but not on Wayland it’s either a Wayland issue (i.e things being fundamentally impossible) or a driver issue and vice versa.

As far as display glitches. I’ve not seen them yet on my more modern and all AMD machine. The old beater computer with the old nVidia card does seem to have occasional stutters using Wayland. Enough of a problem that I just stick with x11 on it.

With respect to screenshots, both my screenshot utility and the PRT SC key on my computer work just fine.

For the tray icons. KStatus is working for all of them except Protonmail Bridge, but that icon will work in Wayland with Tray Icons Reloaded. Protonmail Bridge itself loads and runs fine, just no tray icon. It’s a known issue on Protonmail’s support page.

It works fine for me in tray testing it. Maybe I have something installed that makes it work with KStatus?

Would be worth investigating. Here’s Proton’s support page on the subject…

You may be right. After this morning’s update, a could libraries were replaced and now the tray icon is working. I’ll reboot to confirm but, that’s the first time I’ve seen it work with KStatus.

1 Like

TIL: Hardware video acceleration (VDPAU) has a ways to go on xWayland. Seems to be a known and actively pursued issue though.

For the most part, I’m finding Wayland a bit “rough around the edges”, but workable…

are you using nvidia or amd? on AMD you should probably be using VAAPI

edit: youre AMD so yeah you should be using VAAPI

For some reason, I thought VAAPI was only for Intel graphics but I’ll take a look, thanks :slight_smile:

Hold up, I do have VA-API and that seems to be doing just fine…maybe that’s what you meant?

====
vainfo: VA-API version: 1.16 (libva 2.15.0)
vainfo: Driver version: Mesa Gallium driver 22.1.7 for AMD Radeon RX 6700 XT (navy_flounder, LLVM 14.0.6, DRM 3.47, 5.19.11-arch1-1)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
…and so on…

you can also use vdpau on AMD but it generally doesnt work well as i think its a vdpau → vaapi layer

If you have a video player setup to use vdpau previously you should use vaapi. What are you having issues with VAAPI in?

I just discovered as I was reading up on software updates/changes. Did some looking around my own system and saw that VDPAU was working for me under X11 but not Wayland. Now I’m wondering if I can just get rid of VDPAU altogether and, thus, purge all vestiges of nVidia from my system…

UPDATE: If I understand correctly, this appears to be a VDPAU driver using a VA-API backend
https://archlinux.org/packages/community/x86_64/libvdpau-va-gl/

UPDATE 2: OK, it’s working on Wayland now. The hint was to setup translation between VDPAU and VA-API. Basically, make sure all of these are installed (I was missing the translation layers)

libva-utils
libva-mesa-driver (and lib32-libva-mesa-driver for Steam)
libvdpau-va-gl (translated VDPAU calls to VA-API and OpenGL)
libva-vdpau-driver (another translation layer)
mesa-vdpau (and lib32-mesa-vdpau for Steam)
vdpauinfo

Then, (for AMD) go into /etc/environment and add VDPAU_DRIVER=radeonsi

Now, running Wayland, I get this response to vdpauinfo:

display: :0 screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name width height types

420 16384 16384 NV12 YV12
422 16384 16384 UYVY YUYV
444 16384 16384 Y8U8V8A8 V8U8Y8A8
420_16 16384 16384
422_16 16384 16384
444_16 16384 16384

Decoder capabilities:
<…and so on…>

You can also just use VAAPI without VDPAU. VDPAU is mostly Nvidia and most players support VAAPI and that’s what’s used by Firefox for acceleration and is experimental in chromium I believe. You can continue to use it if you wish but its not necessary

I understand that’s generally the case but some software will have to be told to use it as they’re set up for VDPAU by default (or straight-up call it a dependency like ffmpeg and mpv). So, the emulation layers are nice if they just avoid me maintaining non-standard configs. That being said, If I can remove VDPAU without breaking any dependencies and just roll with the translation layers for when I really need it, that would work for me.