Switching my Archlinux desktop to Sway
Published on
I'm back at it again. I'm back at work. My routine is just like it was before traveling, however, something's off: I'm still using xorg
. Ugh.
I know, I know, xorg
is "fine", in the sense that everything is fine until utter disaster appears. "What disaster could happen to xorg
?", you might say, being an adamant defender of xorg
utilities and software.
Well, there might come a day when nobody wants to maintain it. Simple as that.
xorg
has a lot of maintenance issues, but xorg
has also a lot of time in the wild to be developed, patched, released, and built upon. There are a ton of software tools out there, and many communities have laid their foundation with xorg
right at the bottom.
The xorg
issue is how old it is, and nobody really wants to touch it. It's not... Pleasant? It's simple, but it's simple in the same sense of something from the 80s era being simple. My key take-aways from xorg
is:
In comes Wayland, a new architecture for a modern era. It's a new design of desktop clients talking to the desktop compositor and interacting with the underlying kernel. It shares some aspects with xorg
, but differs in a few ways that leave event decisions up to the individual programs, instead of leaving it up to the display system.
For this to work, programs can support a Wayland protocol, where they report back to the Wayland compositor, instead of the old xorg
ways of doing things.
There's probably a lot more to it, but Wayland has been a development for the better part of the last decade, and people are still split upon whether they should move or not, because most if not all of their software might break.
I take an issue with using old, outdated stuff that nobody maintains. Mostly because in the world of free software, if nobody is maintaining your stuff for you, are you?
I unfortunately, do not possess the skill to code the updates for all my software, and thus, I rely on others to push my desktop computing further and further. My Linux kernel is maintained by the Linux kernel developers, my system is updated regularly by Archlinux developers putting in new patches, and my Firefox is maintained by Mozilla.
The nice part about free and open source software is that anyone can work with the communities to supply necessary fixes and maintainence upgrades, should they have the right skill set. The less unfortunate, can inherently, benefit from those with greater skills than themselves, and I am one of those less unfortunate who can't code my way out of a paper bag if I had to figure out a Linux kernel patch.
Software is maintained by someone, and there will be a day where xorg
is maintained by no one. I think we're getting closer to that zero maintainers in xorg
status soon, maybe not a year or two, but a couple at least, before they realize they have a pile of technical debt and nothing to gain.
"X.org doesn't need patches because it's complete", an argument I heard once that I found completely ridiculous. There is no complete software. There is always something to be done.
"X.org is maintained by professionals", another joke argument passed around, clearly by someone who doesn't have a gauge on the X.org community in the slightest.
"Wayland breaks my software accessibility features that I use with X.org", describing a problem that your software relies on X.org features, but have you tried talking to your software maintainers to talk about future-proofing with Wayland? Probably not. Or just try xwayland
? That exists too.
"Wayland doesn't work with Nvidia" - it does, but not terribly old, out-of-band cards. The drivers for your card need to align with Wayland, which yes, is a hard problem to solve, but nobody is going to want to maintain your years-old Nvidia card for you for free.
The recurring theme here is that everyone wants perfection, but Wayland isn't necessarily perfection. The same can be said for xorg
, it's also not perfect. I think we all got accustomed to shittiness, and that is blinding us from moving on with our lives.
The only way Wayland can move forward is by having more users, and that is what I am going to resolve today.
By default, my installation of EndeavourOS doesn't come with Sway, I've been using a combination of lightdm
+ i3-wm
for a very long time now, but for me to move to Wayland, I need a different display manager service, so I'll be moving to sddm
instead, which supports Wayland.
Here's the basic playbook you can run. Log out of your session, head into a TTY, and do the following:
pacman -S sway sddm xorg-xwayland
mkdir -p ~/.sway
cp /etc/sway/config ~/.sway/config
systemctl disable lightdm.service
systemctl stop lightdm.service
systemctl enable sddm.service
systemctl start sddm.service
Once you start sddm
, it will bring you to a login, and you can log in with your user credentials and pick "Sway" as the desktop. There, now you're officially in Sway!
The copied default configuration will only get you so far, if you have multiple monitors, you will have to create some custom definitions so Sway can configure the monitors for you. I have three monitors, and it's not so horrible to set up. Do this to get your outputs:
swaymsg -t get_outputs
Then simply set the resolutions of each, set any transforms/positions, and you're all set. I frankly enjoy how I don't have to go into xrandr
to configure my monitors and Sway can do it for me. Very nice benefit.
The other issue is getting all your software up to speed to inform it to use Wayland if available. By installing Xwayland
, any xorg
-only software will defer to that instead, which will be our last resort for anything non-Wayland-y.
Depending on the software, should it implement the right stuff, like GTK3, then Wayland shouldn't be even something you have to think about; your software will just work.
But, some things will still need an environment variable or file edit just to get you started. This might make sense with applications that have multiple protocols, like Firefox, which won't enable Wayland by-default until version 121. For now, we have to set MOZ_ENABLE_WAYLAND=1
each time we want to run it, or have it set in your .bash_profile
somewhere.
But, you might say, isn't that kind of tedious having to edit and juggle environment variables? Yes.... Yes it is....
My last post detailed my journey to reaching a true Guix OS pledge status. In there I learned the woes of not having configurations define your life, so I switched over to using something called guix home
to define my home user environment.
Guix with guix home
is able to define a specification that meets your needs, and in this configuration we can define both packages, services, and other things like environment variables. Instead of juggling your environment variables in weird ways, you can simply use Guix instead to define and maintain them in a logical manner, and even incorporate Git to implement version tracking.
My original Guix home definition that lives on my Guix OS is unfortunately not going to be desirable for my Archlinux setup - at least, not yet anyways. I need some applications to be delivered through Archlinux's pacman
for rolling releases and updates, whereas some things I wouldn't mind moving over to Guix and have it all built from source that way. Steam, for example, I would prefer delivered through Archlinux than Guix, to avoid larger issues with video card drivers and whatnot.
My monitors are also different; my Guix lives on a laptop, and my Archlinux lives on a three-monitor desktop. The Sway config I manage with Guix will not actually be the same in this case. Everything else, like Emacs, Vim or what have you, is effectively the same. Even the environment variables. I think for now, I'll write a "non-Guix" home environment file and manage it that way.
(use-modules
(gnu home)
(gnu home services)
(gnu packages)
(gnu services)
(guix gexp)
(gnu home services shells))
(define s->p specification->package)
(home-environment
(packages
(specifications->packages
`("grim" "slurp" "wl-clipboard"
"arc-theme" "arc-icon-theme"
"hicolor-icon-theme"
"plasma-workspace-wallpapers"
)))
(services
(list
(service home-bash-service-type
(home-bash-configuration
(aliases '(("grep" . "grep --color=auto")
("ls" . "ls -p --color=auto")
))
(bashrc
(list (local-file "/home/steve/.bashrc"
"bashrc")))
(bash-profile
(list (local-file "/home/steve/.bash_profile"
"bash_profile")))))
(let ([arc-theme (s->p "arc-theme")]
[plasma-wp (s->p "plasma-workspace-wallpapers")])
(simple-service
'env-vars home-environment-variables-service-type
`(("MOZ_ENABLE_WAYLAND" . "1")
("GTK_THEME" . "Arc-Dark")
("SDL_VIDEODRIVER" . "wayland")
("SWAY_ROOT" . "")
("PLASMA_WP" . ,#~(string-append #$plasma-wp ""))
("_JAVA_AWT_WM_NONREPARENTING" . "1")
("GTK2_RC_FILES" .
,#~(string-append
#$arc-theme
"/share/themes/Arc-Dark/gtk-2.0/gtkrc")))))
(simple-service
'all-the-dotfiles home-files-service-type
`((".emacs" ,(local-file "dotfiles/emacsconfig"))
(".gitconfig" ,(local-file "dotfiles/gitconfig")))))))
Now, I made some choices with this, namely to incorporate using arc-theme
through Guix instead of Archlinux. Why? Because it's easier to locate where arc-theme
is on Guix (from this perspective) than it would for me to figure out where it is on Archlinux, which would make this Guix script not Guix compatible. Like yes, I know it's under /usr/share/themes/Arc-Dark
, but the goal is to have it manageable through Guix instead.
The environment variables here are listed on the Wayland Archlinux wiki page as some variables that can be set for various things. I play a lot of RuneScape, and the Java variable is required for better windowing in Java-based applications.
The Plasma wallpaper theme is my personal touch to get me a nice little background using the KDE wallpaper package, which is shot off as an environment variable for my Sway configuration to read.
slurp
, grim
and wl-clipboard
are all needed to grab screen info from Wayland from the composited windows, and wl-clipboard
can supply the wl-copy
program to copy the image into your clipboard for easy copy/paste.
You can tune yours how you like, but once you finish, run it with guix home container your-file.scm
to run it in a container to make sure files are linked/variables set correctly, then you can do guix home reconfigure your-file.scm
to load the profile to your home environment for real. Upon doing that, you should see symlinks to Guix store files instead of raw config files, meaning it's working.
Forgive me for the short post, but I wanted to share my discovery of finding a new use case for Guix Home, in that we can use Guix Home independent of the core operating system itself. Which is pretty cool.
NixOS can do the same thing I'm certain, maybe with home-manager, but home-manager
isn't in-band and is a third party provided service, while guix home
is. home-manager
also doesn't provide rollbacks, where Guix does (see guix home list-generations
).
This is furthering my goal towards mastery over Guix OS, which may or may not one day lead me to actually use Guix OS as a daily driver on my desktop. That day isn't quite there yet, still, since my desktop is my work computer. However, I'm getting decently comfortable, I would say.
Next week is Christmas, so I don't have many experiments lined up between here and there. Until the next post, have a happy holidays!