Working with Wayland and Sway

Published: Thu Jul 30 2018
This is part of the arch­Linux col­lec­tion.


There is re­ally noth­ing wrong with the x11 win­dow sys­tem. However I read re­cently on Phoronix, that way­land based sys­tems are bet­ter for power con­sump­tion (less is bet­ter).

As my lap­top had been wal­low­ing in win­dows for a while now, I de­cided to give way­land a go. Techinically this in­cludes notes on set­ting up ArchLinux but those are not com­plete nor rec­om­mended in any way. Follow the Arch Way. Use the in­stal­la­tion guide. Mostly these notes are to re­mind me why I chose a par­tic­u­lar pack­age or con­fig­u­ra­tion.


Thankfully, wayland and x11 both don’t have any­thing to do with the sound setup (mostly). Hence I kept to a tried and tested pulseau­dio setup to han­dle all kinds of in­puts. pactl can be bound eas­ily to the me­dia keys as well.

The only change I do is what I al­ways need, a change in /etc/libao.conf for pi­ano­bar as de­scribed here.

# dev=default

Window Managers

Of course the most well known of the way­land win­dow man­agers is prob­a­bly GNOME now that it sup­ports way­land, how­ever be­fore GNOME there was the toy DE, Weston.

None of the above are tiling win­dow man­agers, so nat­u­rally they were dis­carded. I de­cided to use the ex­cel­lent sway win­dow man­ager.

Switching to Sway

Migrating from a rather cus­tomized bspwm + shxkd + lxde (session man­age­ment only) setup was sur­pris­ingly easy. I once tested i3, which sway cites as a ma­jor in­flu­ence, but I had found it to be lack­ing, mostly due to a lack of gaps sup­port (i3-gaps seemed un­sta­ble at the time).

Finding Wayland Binaries

For a long time I was sim­ply try­ing asi­nine meth­ods of de­tect­ing weather I was run­ning a wayland ap­pli­ca­tion or an xwayland com­pat­i­bil­ity ver­sion of the same. These in­cluded a com­mon hack, namely:

  1. Run xeyes
  2. See if the eyes fol­low you over the win­dow

The idea was that if 2. is true, then it’s run­ning with xwayland, oth­er­wise it’s a way­land ap­pli­ca­tion.

However a much more ro­bust method is:

ldd $application_path | grep wayland

I first be­came aware of this ex­cel­lent method from the sug­ges­tion here.

This is much bet­ter since it also lets you know weather an ap­pli­ca­tion is just choos­ing to use xwayland or if it re­ally does­n’t sup­port wayland. (eg. Thunar prefers xwayland but can be made to run na­tively)

File Managers

Thunar has been my de-facto linux file man­ager across a host of DMs and even dis­tros and I was hop­ing that it would work out of the box. However, most GNOME ap­pli­ca­tions seem to have scant lit­tle sup­port for way­land.

I found the file copy di­alogs tak­ing up the whole screen which was a real deal breaker. However, with the ldd trick above I re­al­ized it was just not run­ning as a wayland ap­pli­ca­tion, which I fixed by sim­ply adding:

# Force GTK to use wayland

To the ap­pro­pri­ate startup script (or .bashrc, .zshenv etc.**

Update Sadly thunar is not re­ally pro­duc­tion ready. At the time of this test, sev­eral fea­tures were bro­ken, in­clud­ing di­rec­tory match­ing and scrolling.

However, it turns out the MATE desk­top has bet­ter sup­port, so caja is now the rec­om­mended file man­ager.

Similarly, archive-manager has been re­placed by engrampa.

Prettying it up

By now we have a rather well fleshed out sys­tem which seems to run a lot of ugly look­ing GTK themed ap­pli­ca­tions.

Naturally, the cheap­est (in terms of re­source us­age and de­pen­den­cies) is lxappearance and gtk-chtheme (I came ac­cross the sec­ond one from here).

Bluetooth Managers

For my pur­poses, I noted that blueman looked TERRIBLE. Similar to the is­sues with thunar it in­sisted in open­ing in a split with large blurry text. bluedevil had way too many de­pen­den­cies which made no sense. There seemed to be no rea­son to in­stall kwin re­lated pack­ages. Eventually I set­tled on the el­e­gant yet fea­ture­ful blueberry.

Finding a Bar

Though sway comes with it’s own in­built sway-bar, the sta­tusline con­fig­u­ra­tion is rather lim­ited. Luckily, the cross com­pat­i­bil­ity with i3 can be ex­ploited here. However, for per­for­mance and ease of con­fig­u­ra­tion I opted to forgo i3status and go with the per­for­mant i3s­ta­tus-rust.

Tray icon sup­port still seems pretty lim­ited.

Ditching the mouse

Most of the mouse al­ter­na­tives I use, like key­nav and it’s en­hanced forks all rely on xdo­tool. For us­age on my lap­top this is more an in­con­vinience since I can nav­i­gate with the track­pad and fo­cus shifts with the mouse cur­sor. However al­ter­na­tives are re­quired.


swaygrabex­ists but gen­er­ally is rather ham handed, com­ing from gnome-screenshot, it is dif­fi­cult to work with full screen im­ages only. Must look into scrot and friends.

scrot does not work with way­land. swaygrab has ac­tu­ally been re­moved in the newer AUR pack­age at any rate.

Luckily grim seems to work per­fectly. For par­tial screen­shots, it needs to be paired with slurp and used as:

slurp | grim -g - $outputFile

Wayland and browsers

Most browsers work pretty hap­pily with xwayland, the xorg com­pat­i­bil­ity layer. However that just seemed asi­nine. To the best of my knowl­edge most of the sys­tem pack­ages (ex­cept Fedora) of firefox are not built with wayland sup­port even though it ispretty much fea­ture-com­plete.

At any rate, the only firefox-wayland pack­age on ArchLinux were to be built from the mer­cu­r­ial source. After many hours of my lap­top run­ning out of mem­ory while com­pil­ing I fi­nally gave up on that. Instead, it turns out there is an up to date Flatpack pack­age for fire­fox on way­land cre­ated by the RedHat/Fedora peo­ple. Usually I am loathe to add more pack­age man­agers on a *nix sys­tem (notably, I am strongly against ana­conda), there was­n’t a choice.

However, though the flatpak pack­age in­stalled and did use way­land (with qt-wayland in­stalled) it seems in­sanely buggy and slow. (Sat Sep 1 17:02:39 2018) Crashes were fre­quent and un­doc­u­mented (digging into the flat­pak logs seemed like a waste of time). Currently I’m just go­ing to stick with the nor­mal AUR firefox-nightly.


Typically I use pianobar. However for lo­cal mu­sic, I used to pre­fer audacious for be­ing the light­est mu­sic player around.

However, since there is no tray sup­port for ap­pindi­ca­tors yet in sway, it seems point­less to use any sort of GUI based sys­tem.

Plus for a lap­top, low re­source us­age is para­mount. Hence, I shall set up mpd along with the ter­mi­nal ncm­pcpp and the ex­cel­lent QT5 can­tata for when I need lyrics and a GUI. Additionally, since my shift from synapse to rofi, I shall also need clerk to al­low me to use rofi to con­trol mpd.

Telegram and SDDM

Somehow, sddm was not re­spect­ing my en­vi­ron­ment vari­ables, so telegram had these ugly win­dow bor­ders. Additionally, run­ning telegram from the ter­mi­nal and ba­si­cally, with the en­vi­ron­ment vari­ables (after re­mov­ing sddm) caused a weird per­mis­sions FATAL er­ror.

Finally I de­cided to just go for the snap pack­age. I went with the al­pha re­lease and every­thing seems to be work­ing well.

LightDM seems to do well, plus there’s the beau­ti­ful Aether theme.

Caja and Udisks

I had to man­u­ally edit some of the poli­cies to al­low the active user to mount the dri­ves caja dis­played.

sudo nvim /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy