Introduction

FreeBSD continues to make strides in desktop support, but Linux still holds an advantage in hardware compatibility. After running openSUSE Tumbleweed on my mini PC for several months, I decided it was time to switch to a solution I could control more closely. Not because Tumbleweed doesn't work well - it works great! - but I prefer having direct control over what happens on my machine. And I want native ZFS, because I prefer it over btrfs and it allows me to manage snapshots, backups, and rollbacks just as I do on FreeBSD, using the same tools and procedures.

The choice of Void Linux comes from its BSD-like approach: modular and free of unnecessary complexity. This makes it an excellent solution for this type of setup.

ZFSBootMenu is an extremely powerful tool. It provides an experience similar to FreeBSD's boot loader and natively supports ZFS. I strongly recommend reading the documentation and exploring its features, as some of them - like the built-in SSH daemon - can be genuine lifesavers in recovery scenarios.

Prerequisites and Audience

This guide is not for absolute beginners. If you're new to Linux or Unix-like operating systems, you'd be better served by a ready-to-use distribution like openSUSE Leap (or Tumbleweed for a rolling distribution), Linux Mint, Debian, Ubuntu, or Manjaro. The purpose of this article is to demonstrate a stable, upgradeable, and reasonably secure base setup for users already comfortable with system administration. It uses the glibc variant of Void Linux. The musl version requires different commands, for example for locale generation.

Use at your own risk.

This guide synthesizes instructions from several sources:

• Void Linux (UEFI) from ZFSBootMenu - which doesn't address swap. Using a zvol for swap (not the best solution) prevents hibernation and resume. Our approach uses a separate encrypted swap partition that enables proper resume.
• Void Linux Full Disk Encryption - excellent for btrfs or ext4, but we want ZFS. We'll borrow the swap configuration approach from here.
• Install Void Linux with a desktop environment + Flatpaks - for the desktop portion.

If your setup differs from what's described here (NVMe disk, UEFI boot, Secure Boot disabled), consult the linked guides for explanations and variations.

Installation Script (Optional)

If you want to reproduce this setup quickly, I maintain a script that automates the procedure described in this guide: disk partitioning, ZFS pool and dataset creation, encrypted swap for hibernation resume, dracut configuration, and ZFSBootMenu EFI setup. An optional KDE Plasma desktop installation is also supported.

The script is interactive and will ask for the required parameters (target disk, timezone and keymap, passphrases, desktop options). Requirements, usage instructions, and known limitations are documented in the repository README

That said, I still recommend going through the manual process at least once. Understanding each step is part of the value of this setup, especially when troubleshooting or adapting it to different hardware.

Boot Environment

Since ZFS isn't supported by the base Void Linux image, we'll use hrmpf, an excellent rescue system based on Void Linux that includes ZFS support out of the box.

After booting, you can either proceed directly or SSH into the machine to continue remotely. I generally prefer SSH since it makes copy-paste operations much easier - especially when dealing with UUIDs and long commands. To enable SSH access, set a root password and allow root login:

passwd

Edit /etc/ssh/sshd_config and enable:

PermitRootLogin yes

Restart the SSH daemon:

sv restart sshd

Find the machine's IP address:

ip addr

You can now connect via SSH from another device.

Initial Setup

Set up the environment variables and generate a host ID - we need it for ZFS:

source /etc/os-release
export ID

zgenhostid -f 0x00bab10c

Disk Configuration

Identify your target disk and set up the partition variables. This approach keeps everything consistent and reduces errors:

# Set the base disk - adjust this to match your system
export DISK="/dev/nvme0n1"

# For NVMe disks, partitions are named like nvme0n1p1, nvme0n1p2, etc.
# For SATA/SAS disks (sda, sdb), partitions are named sda1, sda2, etc.
# Set the partition separator accordingly:
export PART_SEP="p"  # Use "p" for NVMe, empty string "" for SATA/SAS

# Define partition numbers
export BOOT_PART="1"
export SWAP_PART="2"
export POOL_PART="3"

# Build full device paths
export BOOT_DEVICE="${DISK}${PART_SEP}${BOOT_PART}"
export SWAP_DEVICE="${DISK}${PART_SEP}${SWAP_PART}"
export POOL_DEVICE="${DISK}${PART_SEP}${POOL_PART}"

Verify your configuration before proceeding:

echo "Boot device: $BOOT_DEVICE"
echo "Swap device: $SWAP_DEVICE"
echo "Pool device: $POOL_DEVICE"

Wipe the Disk

Warning: This operation will irreversibly destroy all data on the selected disk. Double-check that you've selected the correct disk and be sure to have a complete backup of your system!

zpool labelclear -f "$DISK"

wipefs -a "$DISK"
sgdisk --zap-all "$DISK"

Create Partitions

EFI System Partition

If you're not using UEFI boot, adapt this procedure following the appropriate guide linked at the beginning of this post:

sgdisk -n "${BOOT_PART}:1m:+512m" -t "${BOOT_PART}:ef00" "$DISK"

Swap Partition

The swap partition should be slightly larger than your RAM to support hibernation. When you hibernate, the entire contents of RAM are written to swap, so you need enough space to hold it all plus some overhead. In this example, I have 16 GB of RAM, so I'm creating an 18 GB swap partition:

sgdisk -n "${SWAP_PART}:0:+18g" -t "${SWAP_PART}:8200" "$DISK"

ZFS Pool Partition

sgdisk -n "${POOL_PART}:0:-10m" -t "${POOL_PART}:bf00" "$DISK"

Set Up ZFS Encryption

Encrypting the disk is strongly recommended, especially for laptops. Replace SomeKeyphrase with a strong passphrase that's easy to type. Keep in mind that during early boot, the keyboard layout might default to US, so choose a passphrase that's easy to type on a US keyboard layout:

echo 'SomeKeyphrase' > /etc/zfs/zroot.key
chmod 000 /etc/zfs/zroot.key

Create the ZFS Pool

Create the pool with conservative, well-tested options:

zpool create -f -o ashift=12 \
 -O compression=lz4 \
 -O acltype=posixacl \
 -O xattr=sa \
 -O relatime=on \
 -O encryption=aes-256-gcm \
 -O keylocation=file:///etc/zfs/zroot.key \
 -O keyformat=passphrase \
 -o autotrim=on \
 -o compatibility=openzfs-2.2-linux \
 -m none zroot "$POOL_DEVICE"

Create ZFS Datasets

zfs create -o mountpoint=none zroot/ROOT
zfs create -o mountpoint=/ -o canmount=noauto zroot/ROOT/${ID}
zfs create -o mountpoint=/home zroot/home

zpool set bootfs=zroot/ROOT/${ID} zroot

Export and Reimport for Installation

zpool export zroot
zpool import -N -R /mnt zroot
zfs load-key -L prompt zroot

zfs mount zroot/ROOT/${ID}
zfs mount zroot/home

udevadm trigger

Install the Base System

XBPS_ARCH=x86_64 xbps-install \
  -S -R https://mirrors.servercentral.com/voidlinux/current \
  -r /mnt base-system

Copy Host Configuration

Copy the files we generated earlier to the new system:

cp /etc/hostid /mnt/etc
mkdir -p /mnt/etc/zfs
cp /etc/zfs/zroot.key /mnt/etc/zfs

Configure Encrypted Swap

Now we'll set up the encrypted swap partition. This is where the hibernation magic happens - by using a separate LUKS-encrypted partition instead of a ZFS zvol, we can properly resume from hibernation.

Format the swap partition with LUKS:

cryptsetup luksFormat --type luks1 "$SWAP_DEVICE"

Open the encrypted partition, create the swap filesystem, and activate it:

cryptsetup luksOpen "$SWAP_DEVICE" cryptswap
mkswap /dev/mapper/cryptswap
swapon /dev/mapper/cryptswap

Preserve Variables for Chroot

Before entering the chroot, save the disk variables so they remain available inside the new environment:

cat << EOF > /mnt/root/disk-vars.sh
export DISK="$DISK"
export PART_SEP="$PART_SEP"
export BOOT_PART="$BOOT_PART"
export SWAP_PART="$SWAP_PART"
export POOL_PART="$POOL_PART"
export BOOT_DEVICE="$BOOT_DEVICE"
export SWAP_DEVICE="$SWAP_DEVICE"
export POOL_DEVICE="$POOL_DEVICE"
export ID="$ID"
EOF

Enter the Chroot Environment

xchroot /mnt

From this point forward, all commands are executed inside the new system.

First, load the saved variables:

source /root/disk-vars.sh

Configure fstab

Add the swap entry to /etc/fstab:

/dev/mapper/cryptswap   none            swap            defaults        0 0

Set Up Automatic Swap Unlock

To avoid entering the swap password separately after unlocking the ZFS pool, we'll create a keyfile stored on the encrypted ZFS dataset. This is secure because the keyfile only becomes accessible after the ZFS pool is unlocked.

First, install cryptsetup in the new system:

xbps-install -S cryptsetup

Generate a random keyfile and add it to the LUKS partition:

dd bs=1 count=64 if=/dev/urandom of=/boot/volume.key

cryptsetup luksAddKey "$SWAP_DEVICE" /boot/volume.key

chmod 000 /boot/volume.key
chmod -R g-rwx,o-rwx /boot

Add the keyfile to /etc/crypttab:

echo "cryptswap   $SWAP_DEVICE   /boot/volume.key   luks" >> /etc/crypttab

Include the keyfile and crypttab in the initramfs. Create /etc/dracut.conf.d/10-crypt.conf:

install_items+=" /boot/volume.key /etc/crypttab "

Basic System Configuration

Configure keyboard layout and hardware clock. Adjust the keymap and timezone to match your location:

cat << EOF >> /etc/rc.conf
KEYMAP="us"
HARDWARECLOCK="UTC"
EOF

ln -sf /usr/share/zoneinfo/Europe/Rome /etc/localtime

Configure locales:

cat << EOF >> /etc/default/libc-locales
en_US.UTF-8 UTF-8
en_US ISO-8859-1
EOF

echo "LANG=en_US.UTF-8" > /etc/locale.conf

xbps-reconfigure -f glibc-locales

Set the root password:

passwd

Configure ZFS Boot Support

cat << EOF > /etc/dracut.conf.d/zol.conf
nofsck="yes"
add_dracutmodules+=" zfs "
omit_dracutmodules+=" btrfs "
install_items+=" /etc/zfs/zroot.key "
EOF

Install ZFS:

xbps-install -S zfs

Configure ZFSBootMenu

Set the basic boot properties:

zfs set org.zfsbootmenu:commandline="quiet" zroot/ROOT
zfs set org.zfsbootmenu:keysource="zroot/ROOT/${ID}" zroot

The Critical Step: Hibernation Support

Now we need to configure hibernation resume. This is the key insight that makes this setup work: normally, the encrypted ZFS root mounts first, and then it unlocks the swap partition. But when resuming from hibernation, the kernel needs to read the hibernation image from swap before mounting the root filesystem - otherwise, the saved state would be lost.

To solve this, we tell ZFSBootMenu to unlock the swap partition early, before mounting ZFS, by specifying its LUKS UUID.

Get the UUID of your swap partition:

blkid "$SWAP_DEVICE"

You'll see output like:

/dev/...: UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" TYPE="crypto_LUKS" PARTUUID="..."

Store the UUID in a variable for the next step:

SWAP_UUID=$(blkid -s UUID -o value "$SWAP_DEVICE")
echo "Swap UUID: $SWAP_UUID"

Now set the boot parameters using the captured UUID:

zfs set org.zfsbootmenu:commandline="rd.luks.uuid=$SWAP_UUID resume=/dev/mapper/cryptswap" zroot/ROOT/${ID}

Set Up EFI Boot

Create and mount the EFI partition:

mkfs.vfat -F32 "$BOOT_DEVICE"

mkdir -p /boot/efi

Add the EFI partition to /etc/fstab using its UUID:

BOOT_UUID=$(blkid -s UUID -o value "$BOOT_DEVICE")
echo "UUID=$BOOT_UUID    /boot/efi    vfat    defaults    0 0" >> /etc/fstab

Mount it:

mount /boot/efi

Install ZFSBootMenu

xbps-install -S curl

mkdir -p /boot/efi/EFI/ZBM
curl -o /boot/efi/EFI/ZBM/VMLINUZ.EFI -L https://get.zfsbootmenu.org/efi
cp /boot/efi/EFI/ZBM/VMLINUZ.EFI /boot/efi/EFI/ZBM/VMLINUZ-BACKUP.EFI

Configure the EFI boot entries:

xbps-install -S efibootmgr

efibootmgr -c -d "$DISK" -p "$BOOT_PART" \
  -L "ZFSBootMenu (Backup)" \
  -l '\EFI\ZBM\VMLINUZ-BACKUP.EFI'

efibootmgr -c -d "$DISK" -p "$BOOT_PART" \
  -L "ZFSBootMenu" \
  -l '\EFI\ZBM\VMLINUZ.EFI'

Microcode updates

Void Linux is modular, so you may need to install additional packages for your specific hardware. For the Intel microcode, you need the non-free repo: For example:

# For Intel CPUs
xbps-install -S void-repo-nonfree 
xbps-install -S intel-ucode

# For AMD CPUs/GPUs
xbps-install -S linux-firmware-amd

After installing microcode updates, regenerate the boot images and exit:

xbps-reconfigure -fa

Desktop Installation (Optional)

If all you need is a minimal system or a server, you're done and ready to reboot. For a complete desktop environment, continue with the following steps.

Install Core Desktop Packages

xbps-install -S vim nano dbus elogind polkit xorg xorg-fonts xorg-video-drivers xorg-input-drivers dejavu-fonts-ttf terminus-font NetworkManager pipewire alsa-pipewire wireplumber xdg-user-dirs unzip gzip xz 7zip

Install KDE Plasma

xbps-install -S kde-plasma dolphin konsole firefox kdegraphics-thumbnailers ffmpegthumbs vlc ark kwrite discover kf6-purpose

Enable Services

ln -s /etc/sv/NetworkManager /etc/runit/runsvdir/default/
ln -s /etc/sv/dbus /etc/runit/runsvdir/default/
ln -s /etc/sv/udevd /etc/runit/runsvdir/default/
ln -s /etc/sv/polkitd /etc/runit/runsvdir/default/
ln -s /etc/sv/sddm /etc/runit/runsvdir/default/

Configure PipeWire Audio

mkdir -p /etc/xdg/autostart
ln -sf /usr/share/applications/pipewire.desktop /etc/xdg/autostart/

mkdir -p /etc/pipewire/pipewire.conf.d
ln -sf /usr/share/examples/wireplumber/10-wireplumber.conf /etc/pipewire/pipewire.conf.d/
ln -sf /usr/share/examples/pipewire/20-pipewire-pulse.conf /etc/pipewire/pipewire.conf.d/

mkdir -p /etc/alsa/conf.d
ln -sf /usr/share/alsa/alsa.conf.d/50-pipewire.conf /etc/alsa/conf.d
ln -sf /usr/share/alsa/alsa.conf.d/99-pipewire-default.conf /etc/alsa/conf.d

Enable Additional Repositories and Flatpak (Optional)

xbps-install -S void-repo-nonfree void-repo-multilib void-repo-multilib-nonfree

xbps-install -S flatpak
flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

Create a Regular User and exit

For desktop use, create a non-root user with appropriate group memberships. Replace username with your desired username.

useradd -m username
passwd username
usermod username -G video,wheel,plugdev,kvm,audio,network
exit

Fix for NetworkManager

xchroot will bind mount /etc/resolv.conf and leave an empty file. Network Manager won't like it. So let's clean it up:

umount -l /mnt/etc/resolv.conf 2>/dev/null || true

rm -f /mnt/etc/resolv.conf
ln -s /run/NetworkManager/resolv.conf /mnt/etc/resolv.conf

Exit and Reboot

umount -n -R /mnt
zpool export zroot
reboot

Post-Installation

If everything went well, after entering your ZFS encryption password, you'll be greeted by the SDDM login screen.

Testing Hibernation

To verify that hibernation works correctly, you can clock the "Hibernate" button or:

loginctl hibernate

The system should power off. When you turn it back on, ZFSBootMenu will prompt for the password, unlock the swap partition, detect the hibernation image, and resume your session exactly where you left off.

If resume fails, check that: 1. The LUKS UUID in the ZFS commandline property matches your swap partition 2. The swap partition is large enough for your RAM 3. The dracut configuration includes the crypttab and keyfile

Conclusion

You now have a fully functional Void Linux system with native ZFS, full disk encryption, and working hibernation. The system is rolling, lightweight, and easy to maintain. Enjoy!

Wayland is a thing. It’s the future. If you listen to the hype then you’ll hear about all the different ways it’s better than X and how X is so outdated and old and… nasty.

And that’s true. X is old, and X is nasty, especially when you stray outside the happy path and get stuck in the customisation quicksand or the configuration quagmire.

But there’s something else true: X works. And unless you want to get stuck in that quagmire, unless you delve deep into the architecture and work up an emotion, unless you have a ideological opposition to what’s old, you don’t need to worry about any of that. Install your favourite distribution, pick your preferred desktop environment (please not GNOME3 though); things will just work.

Installing Wayland

But the mind is as the mind does, and the hype does wear you down after a while. You can have too much of a good thing. Comfort is normalised, things can’t just be OK, there must be something better out there… So it goes that way, I’ll switch to wayland then. At least to try it out, for a week. That’ll be fine. Everybody says it’s easy. What could go wrong.

Back to reality for a second, and for a bit of context: just before the government mandated period of home-working my main development computer was running more smoothly than it ever had before. I had a big 4K monitor, and one of those ubiquitous little old Dell monitors (to keep up on those slack distractions); I had a two-generations-old AMD graphics card with the open source AMD driver, and I had TearFree enabled so unneccessitating the wrangling of X and vsync. I had the big monitor with fractional scaling and the little one just running at native resolution. I had i3 set up and I had the keybinds ingrained into my muscle memory (just about). I had a compose key!¹ I had found a set of applications that worked well and suited my desktop lifestyle! Life was a dream!

But the world being the way it is, Crown Disease broke out and now I’m stuck with a 1080p monitor, and a rather old nVidia graphics card, and the video tearing is making my eyes water. So, wayland it is then. That extra frame of latency is a fair tradeoff for fixing the tearing. And sway exists², and it’s supposedly a drop-in replacement for i3.

So, I did what was suggested:

sudo apt-get install sway
mkdir ~/.config/sway
cp ~/.config/i3/config ~/.config/sway/config

First impressions, this downloaded quickly! That’s a good sign at least, maybe it isn’t bloated like all modern software development seems to encourage.

And so I foolishly followed the debian migration guide and copied this into my config file

input * xkb_layout "us,de,ru"
input * xkb_variant "colemak,,typewriter"
input * xkb_options "grp:win_space_toggle"
input "MANUFACTURER1 Keyboard" xkb_model "pc101"
input "MANUFACTURER2 Keyboard" xkb_model "jp106"

And then I tried logging out and back in again, this time with sway rather than i3. I was presented with a wonderful black screen, and half a second later unceremoniously dumped back on lightdm again. Something had failed. I wasn’t ready to give up at the first hurdle, so jumped on over to a text terminal, Ctrl-Alt-F1, logged in and tried a second time. A helpful error message, telling me that I can’t use the nVidia proprietary driver. That’s not unexpected, so time to nuke it from orbit:

sudo apt-get purge '^nvidia-.*'
sudo apt-get autoremove

Nice bonus: away goes DKMS, and slow kernel upgrades. And the basic text terminal looks sharp and full-res, not the fuzzy mess it was before. Makes me wonder why I even installed this piece of junk in the first place. But I’m definitely buying AMD next time… Anyway, back to the coal face:

One sway and it’s away. I was in! That happiness only lasted about a single second though, because I realised that I was completely unable to do anything in this new desktop environment. None of my keybinds worked, I couldn’t even find the way to get me out!

So I took my pick of recovery options. Back at the terminal, I realised a likely suspect for this problem. The keyboard layout must be wrong. The debian migration guide has suggested that the most common keyboard layout was colemak. I didn’t even recognise it as the name of a keyboard layout initially, unusual as it is. Why whatever debian developer writing that guide chose it as an example, I don’t know. Colemak… really? Anyway, I RTFMd (man 5 sway-input)³, and worked out a more sensible input command:

input type:keyboard {
    xkb_model pc105
    xkb_layout gb
    xkb_variant extd
    xkb_options compose:ralt
}

So it’s sway and away for the second time. I’m in for real this time. And I had my compose key back, without any hassle at all. It’s starting to feel good!

I had my two screens, and the left was on the left and the right on the right, and I could move the mouse between them! And I could open up kitty, and it worked as it should have done. Score 2 for wayland! Next thing, down come my fingers on the keyboard, the keys are pressed… and dmenu does not appear. Oh. Next up is firefox. Nothing there either. claws? No. Oh dear.

Maybe wayland adoption isn’t as far along as I had heard. It turns out Firefox does have support for Wayland, but it’s not a stable feature yet. dmenu I could replace with wofi. Similarly i3lock can be replaced by swaylock. There’s no substitution (nor any apparent development effort in terms of wayland adoption) for claws-mail though.

So you really can’t just use wayland on its own. It’s not realistic, there are too many applications that rely on X in one way or another. And I don’t think it will be realistic for quite some time yet, no matter what the wayland boosters say. Luckily there is a solution, and it’s just as simple to install as the rest of wayland/sway:

sudo apt-get install xwayland

That, plus a restart is all it takes. Suddenly all my applications work again. I haven’t been able to detect any issues using applications routed through it, so as far as I can tell xwayland has no downsides beyond being just another bit of software to install.

Can Sway replace Xrandr?

Even though I won’t be needing to change display settings regularly with this old desktop, I still decided to try out hotplugging the displays and moving things around. Through the limited set of challenges I tested it with, sway seems to behave fairly logically, albeit you have to control everything yourself with swaymsg input ....

When I tried toggling a display off then on again, my workspaces all shuffled over to the active display, but to my great surprise as soon as the disabled display blinked into life again they were off, back to whence they came! This is very nice QOL improvement compared to what I had before with i3 and Xrandr - having to move the workspaces back to where they should be manually is a pain.

Unfortunately sway doesn’t support display mirroring, or any way to decouple outputs from the logical workspaces, to split one window across multiple montitors. This isn’t a feature I need on my desktop, but it’s nice to have this stuff (or the capability at least) if I were to install wayland on my laptop. There’s an issue open on GitHub although it has the usual affliction: lots of activity but nobody who can be bothered to do the work and submit a patch.

And if I ever get tired of doing the manual work setting up new displays, it looks like kanshi will be there to help.

I didn’t try messing around with HighDPI or backlight control, because this computer just doesn’t have the hardware to support that kind of experiment. Maybe it’ll turn out those are impossible to do if I install sway on compatible hardware, but that remains to be seen!

Impressions

After using my new DE for a few days, I feel I’m competent to give my initial judgement: It’s OK. That’s it! wayland+sway is a combination that works; it’s nothing groundbreaking, it hasn’t told me the winning lottery numbers or finished off all those projects at the top of my to-do list but it works and that’s all that matters really. It’s a bit nicer around the edges than X+i3, and with a little bit more maturation and new features I would have no qualms recommending sway over i3 as the best choice of desktop environment.

My eyes are no longer watering at the thought of display tearing, so the original objective has been satisifed at least, but in terms of the performance impact of compositing I can’t say I really noticed any difference. Probably everything else is so slow that it doesn’t make much difference. Either that or I got used to the difference immediately. Even the mouse cursor latency seems just as good as before.

The performance impact I did notice though was starting up a new kitty instance. Somehow it seems just ever so slightly slower to start up, so the first character or two of the command I was about to type in got cut off. Maybe I’m was just imaginging it, since I got used to the new latency after the first day anyhow.

So I’m going to keep using wayland and sway, unless some big show-stopping issue comes up; and when the pandemic-panic has reduced I will try it on my other computers as well. It’s nothing earth-shattering, but it wasn’t a pain to set up, and it the meat and potatoes of it seem just as good as X.

Niggling Issues

That said, there were still a few outstanding problems I discovered in the first few days, some of which I managed to fix or work around, and others I just couldn’t be bothered to do anything about, since they’re so minor.

One was that my monitors wouldn’t go to sleep when I locked my computer. The documentation was helpful once again and a solution was soon at hand, I had a new lock-script:

#!/bin/sh
revert() {
    killall swayidle
}
trap revert HUP INT TERM
swayidle -w \
    timeout 5 'swaymsg "output * dpms off"' \
    resume 'swaymsg "output * dpms on"' &
swaylock
revert

Admittedly it’s a bit ugly to spawn a new idle daemon and kill each time the screen is locked, but I had to do a similar thing with X as well, so at least it’s not gotten any worse with sway!

My scroll-wheeling speed also seemed to have gone down a little bit, so I tried increasing it. Now I can scroll 1.2 times faster!

input type:pointer scroll_factor 1.2 

scrolling inside kitty was still rather too slow, but I realised quite quickly that all I needed was a small tweak to kitty.conf:

touch_scroll_multiplier 6.0

Apparently wayland is handled as a ‘touch’ device inside kitty and does high-precision scrolling so it needs to be configured seperately.

Another issue resolved not to resolve itself: although my left screen was correctly placed on the left, and the right similarly on the right, and moving the mouse between the two worked as expected; the left screen was workspace number 2 and the right number 1. I like my workspaces to increase from left->right and as far as I can tell I can’t make this happen without lots of manual work on each boot.

lightdm still doesn’t work either, and I can’t be bothered to do anything about that, so I have just switched it off; it’s actually a bit nicer starting my DE manually. It would be nice to know why though, since lightdm and sway are at least notionally compatible with each other.

TL;DR

• wayland works
• it’s not perfect, xwayland is necessary, but does it matter?
• sway is everything good about i3, just better
• nVidia sucks
• compositing delay isn’t that bad when everything else is slow anyway

Postnote

One thing I haven’t mentioned is network transparency, and that’s because it’s not a display server feature I have ever used, or ever intend to use. I don’t understand why anybody makes a fuss about it. I can only put it down to display server fanboyism - it’s just completely irrelevant to the actual issues!

Footnotes