Monthly Archives: July 2023

Hyprland: getting started (part 2)

This is the second blog post on getting started with Hyprland (see the first post here).

In this article, we install and configure a few other tools. We will also look at the customization of keyboard shortcuts.

Other tools

As noted here, you need an Authentication Agent:

Authentication agents are the things that pop up a window asking you for a password whenever an app wants to elevate its privileges.

Let’s install the suggested one:

And then we start it in the Hyprland configuration file with the “exec-once” directive:

Let’s restart Hyprland (such a change in the configuration file needs a restart), e.g., with the default shortcut SUPER + M, we exit Hyprland, and then we can log back in. When a program needs to elevate its privileges, we get the KDE dialog. For example, if we use the EndeavourOS Welcome App to update the mirrors, we get the dialog as soon as the mirror file must be saved:

The same happens if we run from a terminal a “systemctl” command that needs superuser privileges:

Having the authentication dialog tiled as the other windows is not ideal. So let’s create a Window rule in the Hyprland configuration to make it floating:

TIP: to know the values for “class”, you can use “hyprctl clients” when the desired application is running and inspect its output by looking for the “class:” part.

Keyboard shortcuts

Hyprland is about using keyboard shortcuts a lot. You might want to take some time to get familiar with the main keyboard shortcuts for launching and closing (look at the configuration file). Change them as you see fit if you don’t like the default ones.

These are the default ones as set in the example configuration we started with:

I prefer these (note that SUPER+Q now has an entirely different behavior):

Some additional shortcuts might be helpful as well, such as the following (“grouping” has to do with tabbed windows):

And for moving tiled windows:

Mouse gestures

Hyprland provides mouse gestures (swipe) for switching among workspaces. This is not enabled by default, but it’s easy to do: change the existing “gestures” section as follows:


Let’s configure the system to take screenshots.

First, we install “grim” (A screenshot utility for Wayland)

Let’s also install an image viewer, like “Eye of Gnome”:

You can try to run “grim” from a terminal to see how it works: by default, it takes a screenshot of the whole screen and save the corresponding images with names containing date and time in the “Pictures” folder. For example, after running “grim” twice, I get the following:

What if we want to take a screenshot of a region? We need another program, “slurp” (Select a region in a Wayland compositor)

And we configure a few key bindings (note the last one, which takes a screenshot of the currently active window: this requires several commands to get the active window through Hyprland and then compute a few screen coordinates to pass to “grim”):

Brightness and volume

How to set the screen’s brightness and volume through the corresponding keys?

First, install “brightnessctl”:

You can get the current brightness by simply running the program (or with “get” or “-m”) and changing it with the “set” and the value (e.g., increase/decrease by percentage). For example:

So, we need to bind the appropriate special keys to such commands:

For volume, we do something similar: assuming that “wireplumber” is installed, we use “wpctl”:

Note the use of “-l 1.0” meaning that we don’t want to allow the wireplumber to increase the volume above 100%.

Screen locking

If we want to have screen locking (using a keyboard shortcut), we need these two programs:

  • swayidle, Idle management daemon for Wayland
  • swaylock, Screen locker for Wayland

And then, configure the shortcuts (note that we define a variable, $lock, in the configuration file):

Now, when we press SUPER + L, the screen is locked (swaylock can be configured with colors and the like, but I won’t discuss that). You have to type your password: when you start doing that, you’ll see a circle with some parts changing. If you get the password wrong, swaylock will notify you.

The “exec-once” (remember, you need to restart Hyprland for that) will lock the screen after 300 seconds, but it will also turn it off using a “hyprctl” dispatch command. Note that when that happens, you need to press a key or move the mouse, and the instruction above instructs the system to turn the screen back on. Of course, then you’ll have to type your password.

That’s all for now! Stay tuned for more posts about Hyprland ๐Ÿ™‚

Hyprland: getting started (part 1)

In the past few months, I’ve heard (i.e., read articles and seen videos) many good things about the Wayland compositor Hyprland. I decided to try it, and I’ve been using it for almost one month as my daily driver. I’m still not into “tiling” that much, but in Hyprland, you can also switch to classic “stack” window management. I like Hyprland; it feels fast and reactive (also on a PineBook Pro; I’ll blog about Hyprland on a PineBook Pro in the future).

By the way, if you don’t already know:

Hyprland is a dynamic tiling Wayland compositor based on wlroots that doesn’t sacrifice on its looks. It supports multiple layouts, fancy effects, has a very flexible IPC model allowing for a lot of customization, a powerful plugin system and more.

This post is the first of a few articles showing how to install, configure and use Hyprland and additional tools. You can find many GitHub repositories with installation scripts and configuration files for Hyprland, but you end up with the configurations of those repositories, probably without understanding the basic details of Hyprland. I found starting from scratch (following the Hyprland wiki) much more helpful, taking inspiration from some of the above-mentioned GitHub repositories.

By the way, most Hyprland configurations you find on GitHub are primarily about “ricing” (i.e., heavy aesthetic customizations of the desktop). While I love good-looking desktops, I won’t blog about aesthetic customizations much. I’ll focus mostly on configurations and tools for usability.

This first post is only about getting started and having a usable environment with minimal helpful tools: there will be follow-up posts for installing other tools (like a bar and notification system) and configuring other programs (actually, I have already blogged about Variety in Hyprland).

Moreover, all these posts are about Hyprland in Arch Linux since that’s the only OS where I experimented with Hyprland. In particular, I’m using EndeavourOS.

First, install EndeavourOS without a desktop environment (when you get to the installer’s part, where you have to select a desktop environment).

I will use the AUR helper “yay”, which is already installed in EndeavourOS. On Arch, you’ll have to install it yourself, e.g., with the following commands:

Let’s start from and install Hyprland from the official Arch repositories:

As suggested, let’s install the terminal “Kitty” (the default Hyprland configuration has a shortcut to run that).

Of course, later, you can also install another terminal.

Now, you can execute “Hyprland” in your tty. (Remember, I haven’t installed any desktop environment or a login manager).

Note for virtual machines: If you test this in a virtual machine, ensure that 3D is enabled. Moreover, it’s crucial to start Hyprland with the following environment variables so that the mouse is usable; please, remember that the experience in a virtual machine will not be optimal anyway:

When Hyprland starts, you see a warning and a few pieces of information:

To make the warning go away, we edit the generated default configuration file (use either “vi” or “nano” text editors that are already installed in EndeavourOS). To do that, we must start a terminal: by default, the keyboard shortcut is “SUPER + Q” (as shown in the yellow warning):

Now we can edit the file .config/hypr/hyprland.conf and remove the following line:

Save the file, and the warning will go away. In fact, one of the cool features of Hyprland is that it automatically applies changes to that file.

Let’s change the configuration file further. By default, the configuration uses a US keyboard layout. I had to change it to use the Italian layout: Edit that file and change the following part accordingly (in my case, I have an Italian keyboard):

Save the file, and the new keyboard layout will be immediately set.

You might want to install “neofetch” and run it in a terminal (in this example, I’m running inside a KVM virtual machine):

The default configuration uses the shortcut SUPER + E to start the file manager “Dolphin”, which is not installed by default. You could install it. Here, I’m doing something different: Let’s install the file manager “nemo”:

and change the line


Let’s save the file, press SUPER + E, and Nemo appears (tiled automatically)

Let’s install the application launcher “wofi” (personally, I prefer “rofi”, but I’ll blog about that in the future):

Wofi is already configured with the following keyboard shortcut:

For example, let’s use SUPER + R and run Firefox (already installed in EndeavourOS) using Wofi: just start typing “fir” until it appears in the list, move the cursor down to select it, and press ENTER (or keep on typing the other letters til “firefox” is the only choice).

Let’s exploit the blur effects of Hyprland: let’s modify the Kitty configuration file (create it if it doesn’t exist) ~/.config/kitty/kitty.conf by adding this line:

Save it and start another instance of Kitty and enjoy the blur effect with the default Hyprland background:

If “0.5” is too much transparency, make the value a bit bigger.

Let’s make Nemo transparent as well with an Hyprland window rule. By default, Nemo is not transparent:

Let’s modify the Hyprland configuration file by adding this line:

Save and restart Nemo, which is now transparent:

The two values in “opacity” set the opacity for the window when it’s focused and not, respectively. By changing the above line as follows:

The Nemo window will be less transparent when active and more transparent when not focused.

Monitor(s) configurations are specified in the Hyprland configuration and are applied on the fly as soon as you save the configuration file. This is the default configuration:

The last value is the scale value. Try to change it to “1.5” or “1.75”, save, and see the scaling automatically applied.

Note that, by default, when running on a real computer (not a virtual machine), Hyprland already scales the display for high resolutions (e.g., it sets it to “1.5” by default).

Running from a Display Manager

The default installation already created a file in the appropriate folder to let SDDM start the Hyprland session.

Let’s install the AUR package “sddm-git” (we need the Git version to avoid a bug that has been fixed but not in the current release; when reading this post, the official package might have already been fixed) with yay:

Then, we enable the service at boot:

If we want to start it without rebooting, the first time we run:

And now you can enter Hyprland from here.

If you’re running inside a virtual machine, you lose the environment variables we saw above: “WLR_NO_HARDWARE_CURSORS=1 WLR_RENDERER_ALLOW_SOFTWARE=1”. To restore them, you must modify the “/usr/share/wayland-sessions/hyprland.desktop” accordingly, in particular, the “Exec” line:

Then, restart “sddm” (by switching to a tty):

Or by rebooting the system.

That’s all for now! Stay tuned for more posts about Hyprland ๐Ÿ™‚

Installing EndeavourOS ARM on a PineBook Pro

I have already blogged about installing Arch on a PineBook Pro: the first article and theย second article.

In this blog post, I’ll describe how to install EndeavourOS on a PineBook Pro.

As detailed here,, there are 3 ways to install EndeavourOS on an Arm device like the PineBook Pro. In this blog post, I’ll experiment with the first one.

This method consists of a two-step installation process:

  1. use the standard EndeavourOS ISO, booting that from a PC, to install the installation image on an external device (in this example, I will use a USB stick);
  2. then boot the PineBook Pro with the created USB stick and use Calamares to finalize the installation on the very same device you booted from.

Note that I will install EndeavourOS for Arm on an external device, NOT on the eMMC of the PineBook Pro. In this article, I’ll leave a few hints on how to do that on the internal eMMC.

First step

On a standard PC, boot the EndeavourOS ISO (in this example, I’m using the Cassini 2023-03 R2):

After adjusting the keyboard layout and connecting to the Internet, choose “EndeavourOS ARM Image Installer”.

As noted, you need first to insert a USB stick. If you plan to install it on the PineBook Pro’s internal eMMC, you must extract it and place it in a USB adapter. Then, choose “Strat ARM Installer”. That is a textual installation procedure so the installer will open a terminal in full-screen mode.

After pressing OK, you must select the ARM computer (in this case, “PineBook Pro”):

Concerning the file system, in all my experiments, BTRFS has never worked: when rebooting the USB stick (see later), the screen stays blank forever after selecting the boot media. So, the only working solution is EXT4:

Then, you have to write the device where you want to install the installer; the dialog shows all the devices, and you must write the main path of the device, NOT of a possibly existing single partition (in this case, it’s “/dev/sdb”):

Small note: unfortunately, the colors of this textual installer are not ideal ๐Ÿ˜‰

Then, the procedure will prepare the device and download an archive from the Internet for the image to put on the USB stick (it’s a big image, so be patient):

Ultimately, it tells you about the temporary username and password for the installer copied on the USB. It also suggests unmounting the USB with a file manager. In the live environment, you use Thunar to unmount the USB stick. You can recognize the mounted USB stick to unmount because it should show two mounted partitions (the first one is about 128 Mb):

Umounting one of them will also unmount the other one.

Second step

It’s time to boot the PineBook Pro with the UBS stick we created with the abovementioned process. If, in the previous procedure, you created the installer on the eMMC (connected with a USB adapter), you should put the eMMC inside the PineBook Pro.

When the PineBook Pro starts, you should find a way to boot from the USB stick. If you’ve always used the Manjaro installation that comes with the PineBook Pro, you have U-Boot as the bootloader (see my previous blog post for a screenshot of U-Boot booting from the USB stick). If you’re lucky, it should give precedence to the USB stick (I’ve read that this is not always the case, depending on the version of the installed U-Boot). In this example, I have Tow-Boot as the bootloader, so when you see the message telling you to press ESCAPE (or Ctrl-C) to enter the boot menu, please do so:

And then, select the USB as the boot media (of course, if you installed the image on an SD, choose accordingly):

After some textual logs, you should get to the graphical environment for the actual installation. The Window Manager is OpenBox, so, differently from the standard EndeavourOS installer for PC, you don’t have a fully-fledged Desktop Environment (Xfce):

Now, you can choose whether to install an “Official” (e.g., KDE or GNOME) or a “Community” edition (e.g., Sway).

Remember: the installation will be performed on the same media you have just booted. In this example, it’s a USB stick. Again, if you want to install EndeavourOS on the internal eMMC, you first need to extract the eMMC, put it on a USB adapter, do the first procedure described above, put the eMMC back into the PineBook Pro, and start the installation from the eMMC.

As you can see from the screenshots above, there’s no section for partitioning the disk. The partitions have already been created during the first procedure. This installation procedure only finalizes the installation.

I’ve tried both KDE and GNOME.

Enjoy your EndeavourOS installation ๐Ÿ™‚

If you like it on a USB stick (remember, it should be a fast USB), you might want to install it on the eMMC (see the notes in this blog post about that). I have already done that, and it works much better than the original Manjaro!

My Ansible Role for “Oh My Zsh” and other CLI programs

I have already started blogging about Ansible; in particular, I have shown how to develop and test an Ansible role with Molecule and Docker, also on Gitpod.

This blog post will describe my Ansible role for installing “Oh My Zsh” and several command line programs. The role also installs the starship prompt or the p10k theme. As for the other roles I’ve blogged about, this one is tested with Molecule and Docker and can be developed with Gitpod (see the linked posts above). In particular, it is tested in Arch, Ubuntu, and Fedora.

This role is for my personal installation and configuration and is not meant to be reusable.

The role can be found here:

My other post has already described many parts related to zsh installation, configuration, and verification with Ansible and Molecule.

The main file “tasks/main.yml” is as follows:

Besides “zsh” and “git” (which are needed for installing other things, and, in general, I need it daily), this installs several command line tools, like ripgrep, procs, dust, exa, bat, zoxide. Note that, depending on the operating system, these tools must be installed differently (e.g., from the package manager or by downloading a binary distribution). In a few cases, the package names differ depending on the operating system. In such cases, the default names are defined in “vars/main.yml” and properly overridden depending on the operating system:

The task also installs a few fonts (nerd fonts, with emoji, or with icon characters), which are needed because “starship” and “p10k” need a few icon characters; the same holds for other tools like exa.

“Oh My Zsh” is installed by cloning its Git repository; the same holds for some external plugins. The task also sets “zsh” as the default shell for the current user.

Finally, depending on the variable with_starship, which defaults to true, it installs the starship prompt or the p10k theme. These are handled in the corresponding included files “starship.yml” and “p10k.yml”, respectively.

Note that both files copy the corresponding template for “.zshrc” (depending on starship or p10k, the contents of “.zshrc” are slightly different). For “p10k”, it also copies my theme configuration”; for “starship”, I’m OK with the default prompt. The copied “.zshrc” contains several “aliases” for the command line programs installed by this role (e.g., “ls” is aliased to “exa” commands).

Concerning Molecule, I have several scenarios. As I said, I tested this role in Arch, Ubuntu, and Fedora, so I have a scenario for each operating system. In such cases, I test the “starship” installation and verify that the tools that differ for their installations in different operating systems are installed correctly. This is the “verify.yml” (remember that this installs “starship” and NOT “p10k”, so it ensures that only the former is installed):

Concerning “p10k,” I have a separate scenario with a different “verify.yml” (I test this only on Arch since “starship” and “p10k” installations and configurations are the same in all three operating systems):

However, this “verify.yml” could also be used for the other operating systems since it performs the same verifications concerning installed programs. It differs only for the final part.

Of course, this is tested on GitHub Actions and can be developed directly on the web IDE Gitpod.

I hope you find this post useful for inspiration on how to use Ansible to automatize your Linux installations ๐Ÿ™‚