From X to wayland on minimalist debian

[osprey]

This post is about a change in display server from X to wayland on a couple of machines here. The project was to run wayland to satisfy the needs of a user like me who was previously running X. The installations used minimalist tiling window managers such as dwm, and were running debian forky and sid (testing and unstable respectively). These systems I'm referring to don't use or need Desktop Environments like Gnome, KDE, Cinnamon etc., so this post is likely of quite limited interest. Since the "conversion" to wayland was successful with minimalistic systems, it may of interest to some who are more inclined that way.

Some inspiration to move to wayland was the advocacy by @dos2unix over a few years as seen here from 2024: https://www.linux.org/threads/advantages-of-wayland-over-x11.49441, and here in January 2026: https://www.linux.org/threads/why-do-people-hype-up-wayland.61907. There have been sundry other posts in a similar vein which have also been part of the mix.

Some issues I had with wayland were outlined in this post: https://www.linux.org/threads/why-do-people-hype-up-wayland.61907/post-294431. There were apps of interest to me that were either unavailable or limited in wayland, and also apps I was unaware of until more focused investigation. I set about trying to compensate or replace what I'd been using in X so that I could get to a point where I could make a purely wayland system work for me.

A second inspiration for this post was a post by @JasKinasis here: https://www.linux.org/threads/a-way-to-change-window-title-colors.62914/post-297257, who mentioned that he ran the minimalist dwm window manager, which he had mentioned in previous posts as well some time ago. The dwm window manager has been the default window manager here in X on a number of machines used by a number of people.

For many users, the straightforward way to run wayland has been to install a distro that runs it natively like fedora where the Desktop Environment of Gnome or KDE can run in wayland, and the whole underlying display serving system is opaque to the user. The use of minimalist tiling window managers in the case here is not so much to do with saving space or being frugal with resources, but rather about the ways in which the installations are used. Apps are called from the command line which obviates the need for a more elaborate GUI. It's about usage rather than economy here, though a lot of minimalist enthusiasts are more concerned with the economical use of resources.

Here goes.

There have been three parts to the change:
1. Install the wayland software.
2. Replace window management of dwm with wayland apps dwl, or sway.
3. Identify the apps that work with wayland that can satisfy current needs obviating the need for X apps.

The details for each step follow.

1. Wayland software packages installed for the wayland environment:

wayland-protocols
libinput-dev
libwlroots-0.19
libwlroots-0.19-dev
libfcft-dev
libxkbcommon0
libxkgcommon-dev
pkg-config

2. Installation of dwl and/or sway:

dwl
===
To build dwl the installation needs tools like gcc installed. They are available in the build-essential package.

The dwl installation was made in the following order:
Make a directory to hold dwl code.
Change into that directory and run:

git clone https://codeberg.org/dwl/dwl.git

Change into the directory: dwl.
Read the README file and have the dependencies satisfied.
Whilst in the dwl directory, create a new directory named: patches

Change into the patches directory.
Download the bar.patch whilst in the patches directory by running:

wget https://codeberg.org/dwl/dwl-patches/raw/branch/main/patches/bar/bar.patch

Change back to the dwl directory.
If wishing to change the behaviour of dwl, make the changes to the code in the file: config.def.h.

Patch the bar code into the dwl code from the dwl directory by running:

patch -i patches/bar.path

Compile the dwl code with the command: make.
When the dwl executable is built one can copy it to a directory in the PATH, and then it can be commanded in a console terminal to bring up the wayland display environment.

For the time and date to appear in the bar, one can use the slstatus app available from here:

https://dl.suckless.org/tools/slstatus-1.1.tar.gz

Download the tarball and decompress it.
Enter its directory and compile it with make.
Copy the resulting executable in the PATH and then when calling dwl, call it thus:

slstatus -s | dwl

Then the date and time appears on the right side of the bar when bring up dwl.

sway
====
An alternative to using dwl is the sway compositor. Sway doesn't need to use C code to configure it. One installs it through the apt package manager and then it's usable. It includes a bar similar to dwm, which is similar to the bar that was installed with dwl outlined above. Sway has a well commented configuration file for user's alterations if they wish to make them. One copies it from /etc/sway/config to ~/.config/sway/config.

3. Wayland apps to cover some X apps:

wayland-utils...This package includes the command `wayland-info`
                which provides lots of info including the protocols
                supported by the installation. Basically,
                wayland apps need supported protocols to run and
                this command provides that info.

wlr-randr.......Provides the screen info and configuration that
                xrandr does for X. Other wayland apps are needed
                to cover xrandr capability for gamma and
                brightness manipulations.

wev.............Shows wayland events. It's similar to mouse and
                keyboard movements shown by xev in X.

wtype...........The wayland equivalent of xdotool which can
                simulate keyboard input.
            
wdisplays ......Adjusts dpi, position (geometry), resolution,
                refresh rate covering some xrandr functionality.

qpdfview........Displays both ps (postscript), and pdf files
                without needing xwayland.

foot............Basic wayland terminal. Others that work are:
                labwc, kitty, alacritty, lxterminal, tmux.
                There are others too.

waybar..........A separate configurable bar alternative for
                minimalist compositors.

gammastep.......Similar in function to xcalib in X for altering
                the red, green, blue proportions of color on
                the screen to control color temperature.

wlsunset........Gamma adjustment.

grim............Screenshot tool.

slurp...........Cropping tool.

imv.............Image viewer.

wmenu...........Similar functionality to dmenu in X bringing up
                app list for selection.

The above is an on-going project, so there's going to be more to it all, but for now, the basics are all in place to cover usage here.

 

[KGIII]

That looks like a whole lot of effort. If I'm reading correctly, it looks like you're skirting the 'FrankenDebian' thing, which is an interesting choice. It doesn't look too bad, but it does look like you're working with dependencies that might interrupt some other software. Hopefully, you're not, and you'll be just fine. All those bits of software will (in total) have a bunch of dependencies.

I'm actually more curious than anything. (I have zero issues with Wayland, but I'm not as energetic as you are.)

Also, I pronounce 'Debian' wrong in my head. I know it's short for Deb and Ian, but I pronounce it dee-be-an in my head. Fortunately, I never really have to say it outloud.

 

[osprey]

That looks like a whole lot of effort. If I'm reading correctly, it looks like you're skirting the 'FrankenDebian' thing, which is an interesting choice. It doesn't look too bad, but it does look like you're working with dependencies that might interrupt some other software. Hopefully, you're not, and you'll be just fine. All those bits of software will (in total) have a bunch of dependencies.

I'm actually more curious than anything. (I have zero issues with Wayland, but I'm not as energetic as you are.)

Also, I pronounce 'Debian' wrong in my head. I know it's short for Deb and Ian, but I pronounce it dee-be-an in my head. Fortunately, I never really have to say it outloud.

Fortunately, there are no dependency issues for the compiled dwl compositor. Once compiled, it's standalone and creates the windowing environment which the other executables work within. Unfortunately, it's not in the debian repos. The sway compositor on the other hand, is in the repos and works in a very similar way, so users have the choice.

Of note, I guess, is that dwm has been in the debian repos for some time now, but the recommended way to use it from the creators at suckless.org is to compile it independently. Again, when done that way, it has no dependency issues when placed in the PATH. The debian maintainers themselves actually say in the info on dwm:

Please notice that dwm is currently customized through editing its source code,
so you probably want to build your own dwm packages. This package is compiled
with the default configuration and should just give you an idea about what dwm
brings to your desktop.

In relation to apps generally that are not in repos, where users have to access the tarballs and compile them themselves, users do need to pay attention to dependency issues as you mention. It usually involves close reading of README and INSTALL files that usually come with the tarballs. In the cases of dwm and dwl though, those issues don't occur because of the nature of the apps themselves being compiled as standalone units. So, no "frankendebian" on the dwl front. The usual frankendebian problem arises when users combine different releases through including packages from debian testing or unstable with debian stable. In that case, where dependencies in the various releases rely on different versions of the same named packages, breakages can occur which can be very difficult to untangle.

I can't hear your pronunciation of "debian", but it's the meaning that counts more I think.

 

[KGIII]

So, no "frankendebian" on the dwl front. The usual frankendebian problem arises when users combine different releases through including packages from debian testing or unstable with debian stable.

That's good to hear. I was really mostly concerned with all the stuff in step #3 -- all of the Wayhald-specific stuff. I figure those are going to have their own dependencies, which may not be resolved with just the stuff already in the repositories, or may conflict with other applications.

Either way, I'm very curious to see how this works in the long run.

 

[osprey]

That's good to hear. I was really mostly concerned with all the stuff in step #3 -- all of the Wayhald-specific stuff. I figure those are going to have their own dependencies, which may not be resolved with just the stuff already in the repositories, or may conflict with other applications.

Either way, I'm very curious to see how this works in the long run.

To show how the dependency issues are dealt with, the following may make it clear.

In the case of sway which is in the repositories, the dependencies are taken care of by the package manager. The dependencies are brought in by apt when sway is installed. They can be identified as follows, (where the unnecessary suggestions apt makes has been snipped out for brevity):

[~]$ apt depends sway
sway
  Depends: libgl1-mesa-dri
  Depends: swaybg
  Depends: libc6 (>= 2.34)
  Depends: libcairo2 (>= 1.10.0)
  Depends: libdrm2 (>= 2.4.113)
  Depends: libevdev2 (>= 0.9.1)
  Depends: libgdk-pixbuf-2.0-0 (>= 2.31.1)
  Depends: libglib2.0-0t64 (>= 2.12.0)
  Depends: libinput10 (>= 1.26.0)
  Depends: libjson-c5 (>= 0.15)
  Depends: libpango-1.0-0 (>= 1.44.3)
  Depends: libpangocairo-1.0-0 (>= 1.22.0)
  Depends: libpcre2-8-0 (>= 10.22)
  Depends: libpixman-1-0 (>= 0.25.2)
  Depends: libsystemd0 (>= 243)
  Depends: libudev1 (>= 183)
  Depends: libwayland-client0 (>= 1.21.0)
  Depends: libwayland-cursor0 (>= 1.21.0)
  Depends: libwayland-server0 (>= 1.23.0)
  Depends: libwlroots-0.19 (>= 0.19.0~)
  Depends: libxcb-icccm4 (>= 0.4.2)
  Depends: libxcb1
  Depends: libxkbcommon0 (>= 1.5.0)
<snip>

Once apt has installed the dependencies and sway itself, sway is able operate as a standalone app that one calls on the command line. Sway needs all those dependencies because they are libraries it calls upon to execute its functions.

If one is building the package independently, note that in post #1, the step mentioned:

Read the README file and have the dependencies satisfied.

This means that the user needs to satisfy the dependencies, rather than any package manager. It's not a difficult task because usually it consists of a list of packages that need to be installed, and they can usually be installed by the package manager, so the dependencies of dependencies should all be taken care of.

In the case of dwm, the dwm app in the debian repo shows the following dependencies:

[~]$ apt depends dwm
dwm
  Depends: libc6 (>= 2.34)
  Depends: libfontconfig1 (>= 2.12.6)
  Depends: libx11-6
  Depends: libxft2 (>> 2.1.1)
  Depends: libxinerama1 (>= 2:1.1.4)

It's a much smaller dependency list of packages that are either already installed like libc6, or easily installed by the package manager. These are the same dependencies that are needed if one is compiling dwm onself outside the package manager. And, if one is compiling independently, and doesn't run multiple monitors, the libxinerama can be excluded as a dependency, so there's actually more freedom in configuration if one compiles independently outside the package manager.

It should be clear from these examples how dependency issues are handled, and why they are not in any way a "dependency problem" if all the correct steps are taken.

In relation to the wayland apps shown in part 3 of post #1, each app will have its dependencies satisfied in either of the two means mentioned above, that is, by the package manager or by the user.

It's not difficult to induce a dependency problem, and users can do this inadvertently. For example, if one of the dependencies in the listing of sway's dependencies above is removed, for example, the libpcre which is used for regex parsing, then sway may fail, and apt may then place sway on the list of packages to be removed next time the user seeks to clean up the system with the autoremove option for packages.

 

[KGIII]

It should be clear from these examples how dependency issues are handled, and why they are not in any way a "dependency problem" if all the correct steps are taken.

That makes more sense to me, at this point. Thanks for making it clearer.

If you're energetic enough, you could let us know if this somehow turned into a problem, but the way you describe it makes it look like it's going to be just fine.

 

[CaffeineAddict]

Some inspiration to move to wayland was the advocacy by @dos2unix over a few years

I noticed advocacy made by @dos2unix but I won't let anyone convert me just yet.

Things didn't change to the better since Trixie release when I last time tested wayland and things won't change until next Debian release, so there's nothing for me to test further and make a switch.

We'll see how well wayland works in Forky, if it doesn't I'll just drop DE altogether.

And running testing branch of Debian is not good option IMO.

 

[osprey]

And running testing branch of Debian is not good option IMO.

Yes, one is best to have a reason for running the debian testing suite (currently forky) rather that say, stable. It could be any number of reasons, such as taking advantage of the latest drivers, which is sometimes relevant here, check out new kernel features of which there always seems to be a small flood in each new kernel, but the main reason here is actually congruent with the original purpose of the testing branch, which is to test the functioning of some new software and potentially report issues to the developers. Debian, as a community distro, thus does benefit from the design of its release arrangements.