Trying out Wayland in 2025

Wayland — Published on .

Last month I tried out Wayland once more. I do this about once a year, to see if Wayland is actually ready yet for my use case. For most of my life now, I’ve been using X11 with a lot of pleasure. It is feature-rich, and a lot of different window managers exist for it to suit almost every use case I can envision for my systems. X11, however, is considered “old”, and therefore it must be replaced with something new. So far, every time I’ve tried a Wayland compositor, it has been lacking in several ways, and it causes me to switch back to my beloved AwesomeWM setup using X11.

The Requirements

There are a few requirements I have of any window manager or compositor to be considered usable. First and foremost, I strongly prefer a (dynamic) tiling window manager. I like my computer working for me, so manually arranging all the windows is just a senseless chore to me. In addition, I want monitor-independent tags (or workspaces), much like how XMonad and herbstluftwm handle their tags.

With those main requirements, there are some smaller ones such as how I want my bars to operate. They should appear on every monitor, not just the primary monitor. I prefer to have system stats in the top left, a clock in the middle, and a system tray in the top right. Additionally, one bar at the bottom to show me the tags and their state (using colors), and an overview of all open windows on the selected tag.

The Setup

This list of requirements brings me to Hyprland, the compositor that seems to do most of these things when coupled with Waybar. Previously I had tried out vivarium, but it seems this project has been abandoned1.

In addition to Hyprland and Waybar, I used swww for handling my wallpapers, as Wayland requires an active daemon for this. swayidle was used for idle detection to put my monitors to sleep. Fuzzel would function as my application launcher. Lastly, dunst actually works in both X11 and Wayland, so I didn’t need to replace my notification system.

With the setup ready, and a couple hours spent configuring the basics, I set out to actually run Wayland exclusively on my laptop and desktop for a while. As you may have anticipated, next comes a list of the issues I encountered that made me switch back to the much more stable and polished X11.

The Issues

My first issue I encountered is one I’ve encountered in every Wayland experience so far, and that’s copy-on-select. In X11, when I select text in any application, I can paste it using shift+insert. I use this a lot, more than the classical “ctrl+c, ctrl+v” that seems to be the norm these days. Every time I expect something to be copied because I selected it, this makes me spend some additional time being annoyed and having to switch between windows again to manually mark the text I already selected to also be copied.

Another Wayland specific issue that I couldn’t seem to fix is idle monitors. While it works fine in X11, using Wayland one of my monitors would simply refuse to stay idle. Whenever swayidle would issue the command to put my monitors to sleep (hyprctl dispatch dpms off), the left-most monitor would sleep for only a second before becoming active again, and staying active forever.

Hyprland

In Hyprland, workspaces don’t persist if there are no active windows on them, making them disappear from whatever bar you’re using. I dislike this design, but luckily there is an option to fix it, setting persistent:true on the workspace configuration. However, this doesn’t cause the workspace to exist when started, only to persist once opened. This means that my bar is “incorrect” until I open every tag once whenever I start a Hyprland session. This is considered a feature by the maintainer, and so I don’t expect this to get fixed.

Sleep inhibition seems to be another issue. Playing videos, whether full screen or not, does not inhibit sleep in Hyprland. Waybar luckily comes with a button to inhibit sleep, so you can ensure you can watch a video in full. This comes with the caveat that you must also manually turn off the sleep inhibition, or the monitors will simply never sleep ever again.

There also seems to be no “maximized” (better known as a monocle) layout for Hyprland. The maintainer suggests to set the window to be full-screened, which causes whichever window that is focused to be full-screen, even when switching focus. This only applies on the focused screen, however, meaning your windows will resize as you switch focus. Not an issue per se, but it looks really ugly to see a glimpse of a small screen try to stretch itself out immediately upon focusing.

Another issue with the lacking of a proper monocle layout is that new windows will spawn behind whatever window is focused. This makes it hard to deduce if a new window spawned at all, especially since Waybar doesn’t have a module to give an overview of all open windows on the selected workspace in Hyprland.

Waybar

In addition to not having a module to display open windows only for the selected workspace, there are two other issues I encountered with Waybar. The first one is just aesthetics, in that the bottom bar, the one showing my workspaces, does not seem to want to be smaller than 24px, even though I configured the CSS to make it 20px. When starting, it does tell me it’s setting it to 24px while 20px was requested, but it doesn’t tell me why it is being set to 24px.

A more annoying issue with Waybar to me is that the Wine systray does not get absorbed into Waybar’s systray. This means that one 1 workspace (where I tend to launch games), I’ll have two systrays with differing looks and feels. The Waybar systray itself is fine, if only it also incorporated the Wine systray.

Fuzzel

Now I’m getting a little more nit-picky, as Fuzzel looks okay and works fine in general. My main issue with it so far is that it doesn’t just let me run random scripts like Rofi does on X11. This means that to use several scripts I’ve kept in ~/.local/bin over the years, now need an additional .desktop entry in ~/.local/share/applications to continue working. While this is not a difficult task, it is more effort than I think should be required.

swww

As you may have gathered from an earlier passage, I find it rather annoying I need a program running in the background to have a wallpaper. This is a Wayland design issue, however, and not a fault of swww. In fact, swww seems to work pretty well on my laptop, coming with all the features I would like of a wallpaper manager.

On my desktop, however, I found that swww does not play well with different transformations between several monitors. I use a four monitor setup, with the outermost monitors being in portrait mode, while the inner two monitors are in the (default) landscape mode. Using swww, this caused my wallpaper(s) to be incorrect on the portrait mode monitors, showing only part of my wallpaper.

dunst

Dunst is the only piece of software I could keep using directly from X11, where it has been working well for years. As such I was hoping at least one part would leave me without any issues. Sadly, it seems that under Wayland, it only shows the notification title, not the body. I wonder why this breaks when switching from one display protocol to the other.

The Return

And so, after just over three weeks of trying out Wayland yet again, I returned to the safe and stable home of X11. My old setup launched, and everything just worked, exactly as I like my computing experience to be. I don’t mind spending several hours, or even several days, to configure my setup to be just right, but I do mind encountering unsolvable issues every other day when we’ve had software that fixed all of these problems for over a decade.

I understand that Wayland has been deemed as the Future for GNU+Linux, so it is quite sad that there’s so many regressions from a system that, to me, as a user, has been working fine for so long. For now I can still continue using X11, and I hope I can do so until Wayland steps up its game. That said, I am open to suggestions for other compositors and utilities that meet my requirements. I can use those to try out Wayland next year, perhaps.


  1. Most of the projects listed on the wlroots wiki seem to be abandoned, sadly. ↩︎