diff options
author | Aaron Ball <nullspoon@oper.io> | 2021-10-15 16:08:18 -0600 |
---|---|---|
committer | Aaron Ball <nullspoon@oper.io> | 2021-10-15 16:10:23 -0600 |
commit | 6c8446f5c830075f736b7a400e763c2a007ff63b (patch) | |
tree | b590cada795953bbe3b357d50894737c793b50a7 | |
parent | 5b5e9857b21d968686e43dcc0786160c1b6cc69a (diff) | |
download | oper.io-6c8446f5c830075f736b7a400e763c2a007ff63b.tar.gz oper.io-6c8446f5c830075f736b7a400e763c2a007ff63b.tar.xz |
Linux:Switching from X11 to Native Wayland: Convert to rst
-rw-r--r-- | posts/linux:switching-from-x11-to-native-wayland.md | 199 | ||||
-rw-r--r-- | posts/linux:switching-from-x11-to-native-wayland.rst | 213 |
2 files changed, 213 insertions, 199 deletions
diff --git a/posts/linux:switching-from-x11-to-native-wayland.md b/posts/linux:switching-from-x11-to-native-wayland.md deleted file mode 100644 index 9207c45..0000000 --- a/posts/linux:switching-from-x11-to-native-wayland.md +++ /dev/null @@ -1,199 +0,0 @@ -# Linux:Switching from X11 to Native Wayland - -I recently switched from using X11 to Wayland when it became available in my -Linux distro (Crux). This of course means I had to switch from my currently -window manager, `i3`, to its Wayland equivelant, `Sway`. But while Sway claims -to be a drop in replacement for i3, that isn't strictly true. Switching to -Wayland and Sway took a lot more effort than I originally thought. Here is a -list of things I had to do to get things back to normal for the most part. - - -## Tooling Replacements - -### Setting the Wallpaper - -When on X11, I used `feh` to set my wallpaper on login. I had a cleverly named -script called `random_wallpaper.sh` which took one argument, the path to the -pictures directory from which to randomly select an image. It them set the -wallpaper with the command `feh --bg-fill "${picture}"`. - -This of course no longer works with Wayland, as `feh` does not have that -support. Fortunately, the Sway window manager provides a program with this -functionality: `swaybg`. There is a problem with this however. I don't know how -Wayland works very well, so there is probably a good explanation for this, but -`swaybg` doesn't set the wallpaper like `feh` does. Feh sets the wallpaper and -exits. Swaybg sets the wallpaper and stays running, and if you kill it the -wallpaper becomes unset again. Regardless, this makes _changing_ the wallpaper -difficult, as you must track down the existing `swaybg` process, kill it, and -start a new one with a different image. - -To do this, I wrote a wrapper script called `swaybg-singleton.sh`. This script -will set the wallpaper from the provided directory or image, backgrounding the -swaybg process. It also writes a pidfile however, so subsequent runs know which -process to kill when setting the wallpaper again. When changing the wallpaper, -it starts a second swaybg process, which overrides the first on the display, -and then kills the first (old) process so there is no blip in the wallpaper -between setting it from old to new. It can be run as many times as needed -without creating conflicting processes. - - -### Startup Script and Properly Setting GTK Themes - -When my computer boots up, the login screen is a tty. I don't use any of those -fancy login managers like gdm or even lightdm. That said, to start up the GUI, -I would log in and type `startx` previously. That obviously doesn't work -anymore (well, if I want to use Wayland at least). - -So, I wrote up a wrapper script to handle a few of the init processes, very -similar to my old `.xinitrc` file. Right now this is called `runsway.sh`, but I -think it might get renamed to something like `startwl` at some point. - -This script contains the following: - -```bash -#!/usr/bin/env bash - -export XDG_RUNTIME_DIR=$(mktemp -d /tmp/xdg.XXXXXXX) -export GTK_BACKEND=wayland - -gsettings set org.gnome.desktop.interface gtk-theme 'Pop-dark' -gsettings set org.gnome.desktop.interface icon-theme 'Papirus' -gsettings set org.gnome.desktop.interface font-name 'Iosevka Aile 12' -# If you want to set this for the cursor -#gsettings set org.gnome.desktop.interface cursor-theme 'Pop' - -dbus-run-session sway -``` - -### Clipboard management - -With X11, I used the `xclip` program. With Wayland, there exists an unofficial -replacement called [wl-clipboard](https://github.com/bugaevc/wl-clipboard), -which provides the commands `wl-copy` and `wl-paste`. They work fairly -similarly to xclip. - -This isn't particularly needed for many folks probably. I used xclip as a means -to programatically place things in the clipboard, such as text (usernames and -passwords most often) and images (screenshots). - - -### Watching Videos - -With i3, I typically used [mplayer](http://www.mplayerhq.hu/) to watch videos -on my system or listen to some audio (I typically use `mpd`, `mpc`, and `ncmpc` -for consistently listening to music). Unfortunately, mplayer does not yet -support wayland. Also on my system however, I had `ffplay`, which is the video -player utility that comes with `ffmpeg`. This worked on Wayland, but lacked the -ability to play multiple videos in sequence without a wrapper script. I did -some research, and came up with [mpv](https://mpv.io/). This tool works great, -and even better, it works somewhat like mplayer (because long, long ago it was -[forked from -mplayer](https://github.com/mpv-player/mpv/wiki/FAQ#How_is_mpv_related_to_MPlayer)). - - -### Keyboard Automation - -Under X11, I often used `xdotool` to type things automatically. Specifically, I -used xdotool to type usernames and passwords. However, due to lack of support -for unicode typing (many of my passwords contain characters across the unicode -range), I also used `xclip` to copy, and xdotool to paste my passwords -automatically to sidestep the issue. - -The consistently recommended replacement for these two tools are -[wl-clipboard](https://github.com/bugaevc/wl-clipboard) for clipboard -management and [wtype](https://github.com/atx/wtype) for sending keyboard key -strokes. - -I have had a large amount of trouble trying to get `wtype` to press control+v -for me and it actually pasting the contents of the clipboard which I set with a -script with `wl-clipboard`. For some reason it doesnt work across windows (in -other words, I can't copy in my terminal and paste in my browser). That problem -aside, I also haven't had any issues with `wtype` typing unicode characters -yet, so I am just using that for now without using copy/paste between the two -programs. - - -### Lightweight Terminal - -On i3 I used [xterm](https://invisible-island.net/xterm/) for my terminal -emulator. It's old, but still very well maintained, and very lightweight. -However, it does not work on Wayland unfortunately. After some research, I -quickly found `wterm`, which is now an unmaintained project. My distro kindly -provides the [foot](https://codeberg.org/dnkl/foot) terminal, which is also -very lightweight and works great on wayland. It even copies on highlight much -like xterm does (one of my favorite features). - -### Screenshots - -With X11 and i3, I used imagemagick to take screenshots, specifically the -`import` tool. This of course does not yet work on Wayland, so an alternative -had to be found. - -After some research I found I needed two tools to do what I wanted. -Imagemagick's `import` tool allowed you to select what part of the screen you -wanted to screenshot, rather than just always capturing the whole screen. The -common advice for Wayland is two tools for this. - -First we need [slurp](https://github.com/emersion/slurp). This tool doesn't do -much other than grey out the screen a bit and allow you to select a rectangle -of it. The output of this operation (to STDOUT) is the screen geometry of the -selection (eg: `149,117 668x335`). This output is fed into the next tool, -[grim](https://github.com/emersion/grim). Grim takes the actual screenshot, but -if geometry is specified, it only does so of that geometry. So, to tie this -together, my new screenshot command (which is now in my -[screenshot.sh](/src/nullspoon/bin.git/tree/screenshot.sh) script) looks like -this: - -``` -grim -g "$(slurp -w 4)" "${savepath}/screen.${date}.jpg" -``` - -### Viewing Photos - -To be clear on this one, this is referring to things like jpgs, pngs, etc. This -is not referring to photo editing or raw image processing (eg: gimp or -darktable, respectively, both of which I use though gimp doesn't support -Wayland until version 2.99.2 or later). - -As mentioned in the wallpapers section, I prevously used `feh` to set my -wallpaper. `Feh` also happens to be a very lightweight image viewer, which I -used often. Some research quickly brought up a good Wayland replacement: -[imv](https://github.com/eXeC64/imv). - - -### Viewing PDFs - -On X11 and i3, I used [mupdf](https://mupdf.com/) to view and work on PDFs. -But, as with most of the other tools in this post, mupdf also does not yet work -on Wayland. After some research, I found -[zathura](https://pwmt.org/projects/zathura/), which actually uses mupdf to -render pdfs on Wayland. Zathura works very well and can display much more than -PDFs even. - - -### Web Browsing - -Fortunately here, I didn't need to change the applications I use. For a while -now I have used two browsers, [Gnome Web -(Epiphany)](https://wiki.gnome.org/Apps/Web) and -[Firefox](https://www.mozilla.org/en-US/firefox/new). Gnome Web supported -Wayland out of the box and I had to do nothing to start it up on Wayland. -Firefox was _almost_ that easy. By default, Firefox tries to work on X11, and -obviously fails on Wayland with this. The common recommendation on the internet -is to set the environment variable `export MOZ_ENABLE_WAYLAND=1` which will -make Firefox try the Wayland protocol (with which it should work fine). After a -lot more research though, I found a more universal way to set this (not that -this solution is bad at all). It turns out that Firefox also reads a more -generic environment variable, `export GTK_BACKEND=wayland`. Setting either of -those should make Firefox work on Wayland. - - -## Summary - -Switching to Wayland was not an easy task for sure. It took me over a week to -find all of those replacements. But that said, Wayland is definitely lighter -weight and seems to run much faster on older hardware. I especially appreciate -that I don't need to run a special compositor in addition to my display manager -just to get some transparency on windows. So far I like Wayland, but this early -on I am still unsure if I will stick with it for the longer term. If I run -into any other gaps in my processes, I'll post how I solved them here. diff --git a/posts/linux:switching-from-x11-to-native-wayland.rst b/posts/linux:switching-from-x11-to-native-wayland.rst new file mode 100644 index 0000000..eb211aa --- /dev/null +++ b/posts/linux:switching-from-x11-to-native-wayland.rst @@ -0,0 +1,213 @@ +Linux:Switching from X11 to Native Wayland +========================================== + +I recently switched from using X11 to Wayland when it became available in my +Linux distro (Crux). This of course means I had to switch from my currently +window manager, ``i3``, to its Wayland equivelant, ``Sway``. But while Sway +claims to be a drop in replacement for i3, that isn't strictly true. Switching +to Wayland and Sway took a lot more effort than I originally thought. Here is a +list of things I had to do to get things back to normal for the most part. + + +Tooling Replacements +-------------------- + +Setting the Wallpaper +~~~~~~~~~~~~~~~~~~~~~ + +When on X11, I used ``feh`` to set my wallpaper on login. I had a cleverly +named script called ``random_wallpaper.sh`` which took one argument, the path +to the pictures directory from which to randomly select an image. It them set +the wallpaper with the command ``feh --bg-fill "${picture}"``. + +This of course no longer works with Wayland, as ``feh`` does not have that +support. Fortunately, the Sway window manager provides a program with this +functionality: ``swaybg``. There is a problem with this however. I don't know +how Wayland works very well, so there is probably a good explanation for this, +but ``swaybg`` doesn't set the wallpaper like ``feh`` does. Feh sets the +wallpaper and exits. Swaybg sets the wallpaper and stays running, and if you +kill it the wallpaper becomes unset again. Regardless, this makes *changing* +the wallpaper difficult, as you must track down the existing ``swaybg`` +process, kill it, and start a new one with a different image. + +To do this, I wrote a wrapper script called ``swaybg-singleton.sh``. This +script will set the wallpaper from the provided directory or image, +backgrounding the swaybg process. It also writes a pidfile however, so +subsequent runs know which process to kill when setting the wallpaper again. +When changing the wallpaper, it starts a second swaybg process, which overrides +the first on the display, and then kills the first (old) process so there is no +blip in the wallpaper between setting it from old to new. It can be run as many +times as needed without creating conflicting processes. + + +Startup Script and Properly Setting GTK Themes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When my computer boots up, the login screen is a tty. I don't use any of those +fancy login managers like gdm or even lightdm. That said, to start up the GUI, +I would log in and type ``startx`` previously. That obviously doesn't work +anymore (well, if I want to use Wayland at least). + +So, I wrote up a wrapper script to handle a few of the init processes, very +similar to my old ``.xinitrc`` file. Right now this is called ``runsway.sh``, but I +think it might get renamed to something like ``startwl`` at some point. + +This script contains the following: + +.. code-block:: sh + + #!/usr/bin/env bash + + export XDG_RUNTIME_DIR=$(mktemp -d /tmp/xdg.XXXXXXX) + export GTK_BACKEND=wayland + + gsettings set org.gnome.desktop.interface gtk-theme 'Pop-dark' + gsettings set org.gnome.desktop.interface icon-theme 'Papirus' + gsettings set org.gnome.desktop.interface font-name 'Iosevka Aile 12' + # If you want to set this for the cursor + #gsettings set org.gnome.desktop.interface cursor-theme 'Pop' + + dbus-run-session sway + + +Clipboard management +~~~~~~~~~~~~~~~~~~~~ + +With X11, I used the ``xclip`` program. With Wayland, there exists an +unofficial replacement called +`wl-clipboard <https://github.com/bugaevc/wl-clipboard>`_, which provides the +commands ``wl-copy`` and ``wl-paste``. They work fairly similarly to xclip. + +This isn't particularly needed for many folks probably. I used xclip as a means +to programatically place things in the clipboard, such as text (usernames and +passwords most often) and images (screenshots). + + +Watching Videos +~~~~~~~~~~~~~~~ + +With i3, I typically used `mplayer <http://www.mplayerhq.hu/>`_ to watch videos +on my system or listen to some audio (I typically use ``mpd``, ``mpc``, and +``ncmpc`` for consistently listening to music). Unfortunately, mplayer does not +yet support wayland. Also on my system however, I had ``ffplay``, which is the +video player utility that comes with ``ffmpeg``. This worked on Wayland, but +lacked the ability to play multiple videos in sequence without a wrapper +script. I did some research, and came up with `mpv <https://mpv.io>`_. This +tool works great, and even better, it works somewhat like mplayer (because +long, long ago it was `forked from mplayer +<https://github.com/mpv-player/mpv/wiki/FAQ#How_is_mpv_related_to_MPlayer>`_). + + +Keyboard Automation +~~~~~~~~~~~~~~~~~~~ + +Under X11, I often used ``xdotool`` to type things automatically. Specifically, I +used xdotool to type usernames and passwords. However, due to lack of support +for unicode typing (many of my passwords contain characters across the unicode +range), I also used ``xclip`` to copy, and xdotool to paste my passwords +automatically to sidestep the issue. + +The consistently recommended replacement for these two tools are `wl-clipboard +<https://github.com/bugaevc/wl-clipboard>`_ for clipboard management and `wtype +<https://github.com/atx/wtype>`_ for sending keyboard key strokes. + +I have had a large amount of trouble trying to get ``wtype`` to press control+v +for me and it actually pasting the contents of the clipboard which I set with a +script with ``wl-clipboard``. For some reason it doesnt work across windows (in +other words, I can't copy in my terminal and paste in my browser). That problem +aside, I also haven't had any issues with ``wtype`` typing unicode characters +yet, so I am just using that for now without using copy/paste between the two +programs. + + +Lightweight Terminal +~~~~~~~~~~~~~~~~~~~~ + +On i3 I used `xterm <https://invisible-island.net/xterm/>`_ for my terminal +emulator. It's old, but still very well maintained, and very lightweight. +However, it does not work on Wayland unfortunately. After some research, I +quickly found ``wterm``, which is now an unmaintained project. My distro kindly +provides the `foot <https://codeberg.org/dnkl/foot>`_ terminal, which is also +very lightweight and works great on wayland. It even copies on highlight much +like xterm does (one of my favorite features). + +Screenshots +~~~~~~~~~~~ + +With X11 and i3, I used imagemagick to take screenshots, specifically the +``import`` tool. This of course does not yet work on Wayland, so an alternative +had to be found. + +After some research I found I needed two tools to do what I wanted. +Imagemagick's ``import`` tool allowed you to select what part of the screen you +wanted to screenshot, rather than just always capturing the whole screen. The +common advice for Wayland is two tools for this. + +First we need `slurp <https://github.com/emersion/slurp>`_. This tool doesn't +do much other than grey out the screen a bit and allow you to select a +rectangle of it. The output of this operation (to STDOUT) is the screen +geometry of the selection (eg: ``149,117 668x335``). This output is fed into +the next tool, `grim <https://github.com/emersion/grim>`_. Grim takes the +actual screenshot, but if geometry is specified, it only does so of that +geometry. So, to tie this together, my new screenshot command (which is now in +my `screenshot.sh </src/nullspoon/bin.git/tree/screenshot.sh>`_ script) looks +like this: + +.. code-block:: sh + + grim -g "$(slurp -w 4)" "${savepath}/screen.${date}.jpg" + + +Viewing Photos +~~~~~~~~~~~~~~ + +To be clear on this one, this is referring to things like jpgs, pngs, etc. This +is not referring to photo editing or raw image processing (eg: gimp or +darktable, respectively, both of which I use though gimp doesn't support +Wayland until version 2.99.2 or later). + +As mentioned in the wallpapers section, I prevously used ``feh`` to set my +wallpaper. ``Feh`` also happens to be a very lightweight image viewer, which I +used often. Some research quickly brought up a good Wayland replacement: `imv +<https://github.com/eXeC64/imv>`_. + + +Viewing PDFs +~~~~~~~~~~~~ + +On X11 and i3, I used `mupdf <https://mupdf.com>`_ to view and work on PDFs. +But, as with most of the other tools in this post, mupdf also does not yet work +on Wayland. After some research, I found +`zathura <https://pwmt.org/projects/zathura>`_, which actually uses mupdf to +render pdfs on Wayland. Zathura works very well and can display much more than +PDFs even. + + +Web Browsing +~~~~~~~~~~~~ + +Fortunately here, I didn't need to change the applications I use. For a while +now I have used two browsers, `Gnome Web (Epiphany) +<https://wiki.gnome.org/Apps/Web>`_ and `Firefox +<https://www.mozilla.org/en-US/firefox/new>`_. Gnome Web supported Wayland out +of the box and I had to do nothing to start it up on Wayland. Firefox was +*almost* that easy. By default, Firefox tries to work on X11, and obviously +fails on Wayland with this. The common recommendation on the internet is to set +the environment variable ``export MOZ_ENABLE_WAYLAND=1`` which will make +Firefox try the Wayland protocol (with which it should work fine). After a lot +more research though, I found a more universal way to set this (not that this +solution is bad at all). It turns out that Firefox also reads a more generic +environment variable, ``export GTK_BACKEND=wayland``. Setting either of those +should make Firefox work on Wayland. + + +Summary +------- + +Switching to Wayland was not an easy task for sure. It took me over a week to +find all of those replacements. But that said, Wayland is definitely lighter +weight and seems to run much faster on older hardware. I especially appreciate +that I don't need to run a special compositor in addition to my display manager +just to get some transparency on windows. So far I like Wayland, but this early +on I am still unsure if I will stick with it for the longer term. If I run into +any other gaps in my processes, I'll post how I solved them here. |