Archlinux System Tools, Mechanism and Configurations

发表于 本文字数： 8.6k 阅读时长 ≈ 8 分钟

Archlinux Linux system level stuff.

Login Manager: sddm

On Arch Linux, Hyprland (wayland) and sddm settings, I can’t get back sddm greeter after logging out with the canonical loginctl terminate-user $USER or loginctl terminate session "". This is also the default settings of swaylock. These only give me a black screen with a blinking cursor. Check the journal by sudo journalctl -u sddm.servie, it seems sddm-helper gets killed, which makes it think it had crashed.

Note that there isn’t a standard way to “log out” on various Linux distributions. It varies by wayland/x, DE, and login managers.

Finally, I found the most reliable ways on Hyprland: either press ctrl+M to exit hyprland, or hyprctl dispatch exit to exit hyprland. Either way it will return you back to the sddm greater, without hanging the computer.

For wlogout users, you can override the default action in layout configuration file, set the following

1
2
3
4
5
6
{
    "label" : "logout",
    "action" : "hyprctl dispatch exit",
    "text" : "Logout",
    "keybind" : "e"
}

sddm themes

The default sddm greeter page is quite crude in my view. You can use themes to make it look better. pacman provides some older themes. There are more in the AUR package, such as sddm-theme-aerial-git. Pick one you like and install it. The theme is placed in /usr/share/sddm/themes/, twist them as you like for fonts, images, etc.

To configure fonts displayed in the greeter, you have to ensure that the font is installed on the system directories, not user directory as the greeter is launched by sddm daemon which doesn’t have knowledge about which user is logged on.

The default configuration file for SDDM can be found at /usr/lib/sddm/sddm.conf.d/default.conf. DO NOT edit this file directly, this file gets overwritten when upgrading the package. Create new files under /etc/sddm.conf.d instead, see man 5 sddm.conf

An example is

1
2
3
4
5
6
[Theme]
Current=aerial

[General]
GreeterEnvironment=QT_SCREEN_SCALE_FACTORS=2,QT_FONT_DPI=192

The GreeterEnvironment option can be used to adjust the UI scale of the greeter. If the greeter is written in QT, you can set the QT_SCREEEN_SCALE_FACTORS option to adjust the font size. The larger the value is, the larger the font looks.

Fonts

  • To install a font for user, move the font to ~/.local/share/fonts/
  • To install a font system-wide, move the font to /usr/share/fonts (mkdir if the directory does not exist)

Usually that’s enough, run fc-cache to update the font cache if necessary.

Use fc-list to list all the fonts installed on the system and user.

About Nerd Fonts

Nerd Fonts are just fonts with special glyphs like ‘’. They are useful in the way of displaying information in areas like status bar. I use ‘JetBrainsMono Nerd Font’ in waybar for example. The font can be downloaded from here.

Note that there are three versions of each font: ‘Mono’, ‘Plain nerd font’ and ‘Propo’. The difference is

  • Pick ‘Mono’ (NFM) if your terminal emulator or so can only display monospace fonts
  • Pick ‘Propo’ (NFP) for a proportional context (GUI elements)
  • Pick the plain nerd font (NF) version if you want bigger icons

Since each character in a monospace font must take exactly the same witdth, icons have to scaled to fit in that space. Most of them will appear too small.

Put it simply, if you want icons to be pretty instead of weirdly small, and your environment supports non-monospace fonts, use the second or the third options. I use NF in alacritty and NFP in waybar stylesheets.

XWayland: Transition from Xorg to Wayland

Put these in your hyprland config

1
2
3
4
5
6
xwayland {
  force_zero_scaling = true
}

env = GDK_SCALE,2
env = QT_SCREEN_SCALE_FACTORS,2

Basically, this does two things: turnoff xwayland scaling, control xorg application scaling by toolkits: GTK/Qt apps, respectively.

If Telegram is installed, you may need to manually adjust back the scale settings inside Telegram (e.g. 200%), after setting the variables.

I personally don’t find this way (suggested by Hyprland Wiki) helpful. Managing scaling of every toolkit by hand is too daunting a task. Currently there is a near perfect way to handle XWayland backend. Just prefer wayland native apps and use xwayland only if you have no choice.

Package Managers

The most important feature of any Linux distribution is its package manager. In a sense, a “distribution” is probably just a package manager. The package manager provides the users an ecosystem of softwares, which is central to the experience of using the system.

Arch Linux presents its followers pacman, the package manager. It’s very well designed and easy to use, top of the spectrum, I think. pacman lets you install the “official” packages from packages with just one command, much like the apt package manager on Debian-based distros.

Common pacman administration commands are

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
pacman -S <package>
pacman -Ss <regexp>
pacman -Sy
pacman -Syu

pacman -Q <package>
pacman -Qi <package>
pacman -Qo <package>
pacman -Qu
pacman -Qe
pacman -Qm
pacman -Qn

pacman -R <package>
pacman -Rs <package>

Cleaning the package cache:

After a few pacman -Syus, you would have downloaded a ton of compressed package binaries. Cache is stored under /var/cache/pacman/pkg. You have to clean up the cache directory so it won’t grow infinitely in size.

paccache is a script included in the pacman-contrib package. It is not a dependency of pacman, you have to install manually. pacman has its built-in way to clean up cache as well, which is too aggressive and not as flexible as paccache.

1
2
3
paccache -r
paccache -rk1
paccache -ruk0

By default, paccache removes all cached versions for all installed and uninstalled packages, except for the most recent three. (Command 1)

You can override the number of versions to keep by option -k. (Command 2)

You can limit the target packages to uninstalled. (Command 3)

Having pacman is good engough, better, there is the AUR (Arch User Repository), a community-driven repository that hosts a diverse range of packages upgrading at a much faster pace than the official database. You are able to install AUR packages without any additional tools apart from the standard Arch installation, but an AUR helper like yay will make your life easier.

Power Management

If you are using a laptop Arch, you are probably gonna need to concern about power management at some point. After all, you won’t want to have a CPU-intensive program running on your laptop while the laptop is in your backpack with lid closed.

In such case, you could make the computer “suspend” and “hibernate”. The two terms are subtly different, but in current context we will pretend they are equivalent.

Suspend and hibernate both put the computer to “sleep” mode. Suspend keeps RAM still powered, while hibernate writes the RAM to disk and loads it back when the compute resumes. Thus, suspend generally offers faster resuming than hibernate.

The simplest way to suspend the computer is by typing

1
systemctl suspend

That puts the computer to suspend mode, with screen(s) off, sound off, video paused, peripherals disconnected, etc.

Manually execute a command to suspend is dumb though. Most people would want actions like closing the lid to put the computer to suspend. That can be delegated to service systemd-logind. Edit file /etc/systemd/logind.conf to control what actions to take on ACPI events. These events have reasonable default actions to take, like “suspend” is by default the action on lid close.

ACPI stands for “Advanced Configuration and Power Interface”, which is a standard to perform power management, i.e. putting unused hardware components to sleep.

Some devices can trigger ACPI events to terminate suspension, such as keyboard presses and mouse moves. To find out those devices, execute

1
grep "enabled" /proc/acpi/wakeup

which shows

1
2
PEG0      S4    *enabled   pci:0000:00:06.0
TXHC      S4    *enabled   pci:0000:00:0d.0

Refer to wiki page [Power Management/Wakeup triggers] (https://wiki.archlinux.org/title/Power_management/Wakeup_triggers#/proc/acpi/wakeup) for what /proc/acpi/wakeup is for. The things in Device column are hardware devices such as your bluetooth controller, WiFi and USB controllers.

One device is called XHCI, Extensible Host Controller Interface. In human language, it basically refers to USB 3.0 controller. However, XHCI devices (USB controllers) could wake computer up unexpectedly through peripherals.

For example, the LogiTech mouse I use needs to have a USB receiver plugged into the computer. It turns out the mouse in power on mode sends something periodically to the receiver, and the receiver can wake computer up. This is normal and as expected of course, as you might want to move your mouse to bring the computer up from suspension. But the mouse is not powered off immediately after I suspend the machine (there is a timeout for inactivity), so it wakes the computer up in a few seconds, which is obviously undesirable.

Thus I decided to disable the XHCI interface so I can truely get a suspended computer. The Wiki page above metions how to do that. Basically, writing a device name string to that wakeup file, toggles its state. This is quite classic Liunx philosophy: everything is a file. You interact with very low level kernel settings by writing the file

echo "XHCI" | sudo tee -a /proc/acpi/wakeup

The pipe and use of tee here is to write the file with enough permissions, without having to elevate to the root user.

There is a downside of such approach: you can’t wake up from suspension by moving mouse, but pressing keyboard still does. Any change to /proc/acpi/wakup does not last across reboots. The XHCI trigger is set back to “enabled” as soon as you reboot.

If you want to persist the changes to /proc/acpi/wakeup, you have a few options:

  1. Create a systemd service to automatically modify the trigger file upon system boot.
  2. Use modprobe to disable XHCI kernel module upon suspend request, and load it back on wakeup.

For systemd approach, the service unit has to be installed under the system service manager. The user service units cannot depend on system targets like sleep.target or suspend.target.