Working with Wayland and SwayThis is part of the archLinux collection.
There is really nothing wrong with the x11 window system. However I read recently on Phoronix, that wayland based systems are better for power consumption (less is better).
As my laptop had been wallowing in windows for a while now, I decided to give wayland a go. Techinically this includes notes on setting up ArchLinux but those are not complete nor recommended in any way. Follow the Arch Way. Use the installation guide. Mostly these notes are to remind me why I chose a particular package or conﬁguration.
x11 both don’t have anything to do with the sound setup (mostly). Hence I kept to a tried and tested pulseaudio setup to handle all kinds of inputs.
pactl can be bound easily to the media keys as well.
The only change I do is what I always need, a change in
/etc/libao.conf for pianobar as described here.
default_driver=pulse # dev=default quiet
Of course the most well known of the wayland window managers is probably GNOME now that it supports wayland, however before GNOME there was the toy DE, Weston.
None of the above are tiling window managers, so naturally they were discarded. I decided to use the excellent sway window manager.
Switching to Sway
Migrating from a rather customized bspwm + shxkd + lxde (session management only) setup was surprisingly easy. I once tested i3, which sway cites as a major inﬂuence, but I had found it to be lacking, mostly due to a lack of gaps support (i3-gaps seemed unstable at the time).
Finding Wayland Binaries
For a long time I was simply trying asinine methods of detecting weather I was running a
wayland application or an
xwayland compatibility version of the same. These included a common hack, namely:
- See if the eyes follow you over the window
The idea was that if 2. is true, then it’s running with
xwayland, otherwise it’s a wayland application.
However a much more robust method is:
ldd $application_path | grep wayland
I ﬁrst became aware of this excellent method from the suggestion here.
This is much better since it also lets you know weather an application is just choosing to use
xwayland or if it really doesn’t support
wayland. (eg. Thunar prefers
xwayland but can be made to run natively)
Thunar has been my de-facto linux ﬁle manager across a host of DMs and even distros and I was hoping that it would work out of the box. However, most GNOME applications seem to have scant little support for wayland.
I found the ﬁle copy dialogs taking up the whole screen which was a real deal breaker. However, with the
ldd trick above I realized it was just not running as a
wayland application, which I ﬁxed by simply adding:
# Force GTK to use wayland GDK_BACKEND=wayland CLUTTER_BACKEND=wayland
To the appropriate startup script (or
thunar is not really production ready. At the time of this test, several features were broken, including directory matching and scrolling.
However, it turns out the MATE desktop has better support, so
caja is now the recommended ﬁle manager.
archive-manager has been replaced by
Prettying it up
By now we have a rather well ﬂeshed out system which seems to run a lot of ugly looking GTK themed applications.
Naturally, the cheapest (in terms of resource usage and dependencies) is
gtk-chtheme (I came accross the second one from here).
For my purposes, I noted that
blueman looked TERRIBLE. Similar to the issues with
thunar it insisted in opening in a split with large blurry text.
bluedevil had way too many dependencies which made no sense. There seemed to be no reason to install
kwin related packages. Eventually I settled on the elegant yet featureful
Finding a Bar
sway comes with it’s own inbuilt
sway-bar, the statusline conﬁguration is rather limited. Luckily, the cross compatibility with
i3 can be exploited here. However, for performance and ease of conﬁguration I opted to forgo
i3status and go with the performant i3status-rust.
Tray icon support still seems pretty limited.
Ditching the mouse
Most of the mouse alternatives I use, like keynav and it’s enhanced forks all rely on xdotool. For usage on my laptop this is more an inconvinience since I can navigate with the trackpad and focus shifts with the mouse cursor. However alternatives are required.
swaygrabexists but generally is rather ham handed, coming from
gnome-screenshot, it is difﬁcult to work with full screen images only. Must look into
scrot and friends.
scrot does not work with wayland.
swaygrab has actually been removed in the newer AUR package at any rate.
Luckily grim seems to work perfectly. For partial screenshots, it needs to be paired with slurp and used as:
slurp | grim -g - $outputFile
Wayland and browsers
Most browsers work pretty happily with
xorg compatibility layer. However that just seemed asinine. To the best of my knowledge most of the system packages (except Fedora) of
firefox are not built with
wayland support even though it ispretty much feature-complete.
At any rate, the only
firefox-wayland package on ArchLinux were to be built from the mercurial source. After many hours of my laptop running out of memory while compiling I ﬁnally gave up on that. Instead, it turns out there is an up to date Flatpack package for ﬁrefox on wayland created by the RedHat/Fedora people. Usually I am loathe to add more package managers on a *nix system (notably, I am strongly against anaconda), there wasn’t a choice.
However, though the
flatpak package installed and did use wayland (with
qt-wayland installed) it seems insanely buggy and slow. (Sat Sep 1 17:02:39
- Crashes were frequent and undocumented (digging into the ﬂatpak logs seemed like a waste of time). Currently I’m just going to stick with the normal AUR
Typically I use
pianobar. However for local music, I used to prefer
audacious for being the lightest music player around.
However, since there is no tray support for appindicators yet in sway, it seems pointless to use any sort of GUI based system.
Plus for a laptop, low resource usage is paramount. Hence, I shall set up
mpd along with the terminal ncmpcpp and the excellent QT5 cantata for when I need lyrics and a GUI. Additionally, since my shift from synapse to roﬁ, I shall also need clerk to allow me to use roﬁ to control
Telegram and SDDM
sddm was not respecting my environment variables, so telegram had these ugly window borders. Additionally, running telegram from the terminal and basically, with the environment variables (after removing
sddm) caused a weird permissions FATAL error.
Finally I decided to just go for the snap package. I went with the alpha release and everything seems to be working well.
LightDM seems to do well, plus there’s the beautiful Aether theme.
Caja and Udisks
I had to manually edit some of the policies to allow the
active user to mount the drives caja displayed.
sudo nvim /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy