summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAaron Ball <nullspoon@oper.io>2021-10-15 16:08:18 -0600
committerAaron Ball <nullspoon@oper.io>2021-10-15 16:10:23 -0600
commit6c8446f5c830075f736b7a400e763c2a007ff63b (patch)
treeb590cada795953bbe3b357d50894737c793b50a7
parent5b5e9857b21d968686e43dcc0786160c1b6cc69a (diff)
downloadoper.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.md199
-rw-r--r--posts/linux:switching-from-x11-to-native-wayland.rst213
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.

Generated by cgit