Skip to content

Instantly share code, notes, and snippets.

@lbrame
Last active November 25, 2024 16:09
Show Gist options
  • Save lbrame/1678c00213c2bd069c0a59f8733e0ee6 to your computer and use it in GitHub Desktop.
Save lbrame/1678c00213c2bd069c0a59f8733e0ee6 to your computer and use it in GitHub Desktop.
Tweaks I've made to my Arch Linux installation

Arch Linux tweaks

This is a collection of the tweaks and modification I've made to my Arch Linux installation over the months. These may be applicable to other distros, but please check first before doing anything. I also included Arch Wiki references for all the procedures I mentioned. My recommendation is not to blindly follow this gist but to always check with the Arch Linux wiki first. Things move fast and by the time you're reading this my gist may be out of date. Lastly, the golden rule: never execute a command you don't understand.

Installing the KDE Plasma desktop

My current DE of choice is KDE's Plasma. I find it just about perfect.

There are various ways to install it on Arch. The most popular one is to install plasma and plasma-applications, but I don't like doing that because it comes with too many programs I'll never use. I, instead, install the base plasma group, remove the few extra packages that come with it, then I finish off by installing a few KDE apps that don't come with the plasma group, plus packages needed to use some of their features. I'm aware it's possible to get an even more minimal install by foregoing the plasma group and just installing plasma-desktop and a few other packages, but there are nice features, such as the browser integration, that I actually use.

# pacman -S plasma
# pacman -Rnsc discover oxygen plasma-vault
# pacman -S xdg-desktop-portal ark unrar kdeconnect sshfs dolphin okular konsole kate gwenview

I then export the export GTK_USE_PORTAL=1 environment variable so that programs that read it might load KDE-specific APIs, which can influence some programs to present the Qt file picker over the GTK one - it's way better integrated with Plasma and it's, frankly, superior.

Even though Plasma was built with customization in mind, I mostly use it with its default settings: I just change the action key to META, import my keyboard shortcuts and set the double-click, not the single-click, to open a file or folder.

Yay!

I use yay as my AUR helper. You can install it from the AUR:

git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

If you don't want Golang dependencies, yay-bin is the package you're looking for.

Fonts!

Installing missing fonts

DEs often don't include common fonts that some programs require:

# pacman -S noto-fonts noto-fonts-cjk ttf-dejavu ttf-liberation ttf-opensans

Enabling ClearType rendering

Microsoft no longer holds their patents on the ClearType font rendering, but at the time of writing only a few select distros (including Ubuntu, Fedora and Void Linux) make use of it by default. However, it can be enabled in Arch by replacing the freetype2 package with a patched version from the AUR:

# yay -S freetype2-cleartype

This already improves the situation, but many fonts are still rendered as bitmap, which makes them look horrible. This can, however, be fixed. Let's begin with some symbolic linking:

# ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d
# ln -s /etc/fonts/conf.avail/10-sub-pixel-rgb.conf /etc/fonts/conf.d
# ln -s /etc/fonts/conf.avail/11-lcdfilter-default.conf /etc/fonts/conf.d

Let's then add the following line to /etc/profile.d/freetype2.sh:

export FREETYPE_PROPERTIES="truetype:interpreter-version=40"

Please note that the way I did this is not endorsed by the Arch Wiki and it's a way I found to make the change permament. Unless you know how to revert all of this, you should just stick to what the Arch Wiki does, which I did too anyway.

Create the file ~/.config/fontconfig/conf.d/20-no-embedded.conf and make it look like the following:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <match target="font">
    <edit name="embeddedbitmap" mode="assign">
      <bool>false</bool>
    </edit>
  </match>
</fontconfig>

Finally, log in again. This is an user setting and it will be reverted if you ever delete this file and it won't work on other users.

I'm using the Plasma desktop. I use the SF Mono Display Medium font everywhere (SF Mono Medium as a monospace font) and I enabled RGB antialiasing with Slight hinting and no forced font DPI. San Francisco fonts can be installed from the AUR:

# yay -S otf-san-francisco-pro

Installing Windows fonts

I finally added Microsoft fonts as they're handy to keep around and tend to be necessary to display web pages and Office documents correctly.

To install them system wide, copy the C:\Windows\Fonts folder from a Windows installation to /usr/share/fonts:

# mkdir /usr/share/fonts/WindowsFonts
# cp /windows/Windows/Fonts/* /usr/share/fonts/WindowsFonts/
# chmod 644 /usr/share/fonts/WindowsFonts/*

These commands assume your Windows partition is mounted at /windows as they've been copied verbatim from the Arch Wiki. If you don't dual boot or don't mount your Windows partition to /windows, just replace /windows/Windows/Fonts/* with wherever location you copied that folder to.

Misc packages

I also install some packages that are generally needed in order to make things work well but don't really fall under any category here:

# in repos
pacman -S \
    libappindicator-gtk3 `#Fixes blurry icons in Electron programs` \
    appmenu-gtk-module  `#Fixes for GTK3 menus` \
    xdg-desktop-portal \
    xdg-desktop-portal `#These two instruct programs to show KDE's file picker whenever possible` \
    

Improving I/O performance

Using the BFQ scheduler

Arch Wiki reference: https://wiki.archlinux.org/index.php/Improving_performance#Changing_I/O_scheduler

Linux notoriously gets very slow with I/O intensive operations such as moving a lot of files at once and swapping. If you have a spinning hard drive or a not-so-fast SSD, the BFQ scheduler can help improve system responsiveness during I/O intensive operations. I still use a SATA SSD for lack of a faster connector on my laptop and I have perceived significantly better overall performance by using the BFQ I/O scheduler. If your boot disk is a fast NVme SSD it's generally not the best idea to use the bfq scheduler for it, but since the I/O scheduler is set per-disk, it might be a good idea to use it for any spinning hard disk permanently connected to the computer (e.g. a secondary disk to store games and movies).

To set the BFQ scheduler, you need to specify some udev rules to tell Linux what scheduler to use on what kind of disks. For example, you could use the mq-deadline scheduler on your NVme drives and the bfq scheduler on your SSDs. I decided to set my rules in such a way that no scheduler is used for NVme SSDs, but bfq is used for everything else. To do this, create the file /etc/udev/rules.d/60-ioschedulers.rules and fill it in as below:

# set scheduler for NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
# set scheduler for SSD and eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="bfq"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

Reboot and you're done.

Setting ext4 commit frequency to 60

Arch Wiki reference: https://wiki.archlinux.org/index.php/Ext4#Improving_performance

Another way to improve performance on not-so-fast SSDs is increasing the ext4 commit frequency from every 5 seconds up to 60. Just add commit=60 to the mount options for the boot partition in /etc/fstab:

/dev/sda5    /    ext4    rw,relatime,commit=60    0    1

Reboot and you're done.

Improving laptop battery life with TLP and powertop

Arch Wiki reference: https://wiki.archlinux.org/index.php/TLP https://wiki.archlinux.org/index.php/Powertop

Linux distros tend to deplete laptops' batteries quite quickly, which can be detrimental to some. tlp is a set-and-forget, auto-tuning option for laptops that I have found to work very well (albeit it comes with drawbacks, such as a perceived decrease in performance). Setting it up on Arch Linux is pretty straightforward:

# pacman -S tlp
# systemctl enable tlp.service --now

powertop is a powerful commandline program to keep track of battery consumption. It also allows the user to quickly alter some system settings that have an impact on battery life. You can use it to make a quick tuning:

# powertop --auto-tune

However, don't enable powertop's service if you already use TLP.

Systemd configuration

Arch Wiki reference: https://wiki.archlinux.org/index.php/Systemd/

Taming the journal's size

Systemd's system journal's size can go out of control. There are some things you can do to keep it in control:

# journalctl --vacuum-size=100M
# journalctl --vacuum-time=2weeks

Forwarding the journal to /dev/tty12

This is very simple. Just create the file /etc/systemd/journald.conf.d/fw-tty12.conf and fill it like this:

[Journal]
ForwardToConsole=yes
TTYPath=/dev/tty12
MaxLevelConsole=info

Then, restart the service:

# systemctl restart systemd-journald.service

Improving performance on Intel + Intel graphics

I'm using a Intel i5 7200-U CPU with Intel HD 620 integrated graphics. It's not a particularly powerful chip by any means, but with some tuning I got it to run very respectably and even allow me to play some lightweight games on the side without framerate drops or having to set low graphics (notably osu, the Portal series, Don't Starve, Starbound, Minecraft and others).

Needed packages

Install necessary packages:

# pacman -S libva-intel-driver libvdpau-va-gl lib32-vulkan-intel vulkan-intel intel-ucode

Intel microcode

Arch Wiki reference: https://wiki.archlinux.org/index.php/Microcode https://en.wikipedia.org/wiki/Intel_Microcode

The first thing you should do on Arch Linux if you have an Intel CPU is setting up intel-ucode.

The first thing to do to set up the microcode on my Intel laptop was to install the intel-ucode package:

# pacman -S intel-ucode

The second thing was to configure my bootloader, GRUB, with microcode early-loading. I just let grub-mkconfig handle this:

# grub-mkconfig -o /boot/grub/grub.cfg

Reboot and you're done.

Using the modesetting driver

Arch Wiki reference: https://wiki.archlinux.org/index.php/Kernel_mode_setting#Early_KMS_start

I use the kernel modesetting driver for my Intel processor. To use it, it's sufficient to make sure the xf86-video-intel package is not installed. This is important because how I set up HuC / GuC depends on the kernel modesetting being used.

Enabling Early KMS

Arch Wiki reference: https://wiki.archlinux.org/index.php/Kernel_mode_setting#Early_KMS_start https://wiki.archlinux.org/index.php/Mkinitcpio#Image_creation_and_activation

I decided to start kernel modesetting during the initramfs stage. To do this, you can just add the i915 module to /etc/mkinitcpio.conf like this:

MODULES=(i915)

And then

# mkinitcpio -p linux

Finally, reboot.

Enabling HuC / GuC firmware loading

Arch Wiki reference: https://wiki.archlinux.org/index.php/Intel_graphics#Enable_GuC_/_HuC_firmware_loading

Since I have a Kaby Lake processor, some video features require updated GPU firmware that is not provided by default because it doesn't play nicely with all hardware. I'm happy to report no problems on Dell Inspron 5567.

Since I have set up early KMS, it's sufficient to create a file called /etc/modprobe.d/i915.conf the contents of which should be:

options i915 enable_guc=2

Reboot, then, make sure both are enabled:

# cat /sys/kernel/debug/dri/0/i915_huc_load_status
# cat /sys/kernel/debug/dri/0/i915_guc_load_status

Using Alternative Iris OpenGL driver

Arch Wiki reference: https://wiki.archlinux.org/index.php/Intel_graphics#Alternative_OpenGL_Driver_(Iris) https://wiki.archlinux.org/index.php/Mpv#Hardware_video_acceleration

I use the experimental Intel Iris driver to start games or other graphically demanding applications. It's sufficient to export MESA_LOADER_DRIVER_OVERRIDE=iris before starting the application itself, but I suggest doing this in shells you open after starting up your DE or adding it to the desktop entries of the interested programs, since not every single program plays nicely with it and it would be foolish to export this environment variable globally.

Setting up VA-API

Arch Wiki reference: https://wiki.archlinux.org/index.php/Hardware_video_acceleration https://wiki.archlinux.org/index.php/Chromium#Hardware_video_acceleration

Something that's really annoying in the Linux desktop is that video acceleration is disabled by default. If you have modest hardware, you'll probably notice watching a YouTube video is enough to bring your CPU near to the maximum usage. This can, of course, be worked around in some ways.

If you use Intel Graphics, you have to find out if your Intel chip requires the intel-media-driver or the libva-intel-driver. My processor supports the latter. It's not installed by default, so you should do it yourself:

# pacman -S libva-intel-driver libva-utils

After doing this, look at the output of vainfo, provided by the package libva-utils we have installed earlier, to make sure everything is fine. Lines terminating in VAEntrypointVLD or VAEntrypointEncSlice indicate success.

I use the mpv media player mostly. It's sufficient to start it with arguments mpv --hwdec=auto to enable hardware acceleration for Xorg and mpv --gpu-context=wayland on Wayland. I'm currently using the Plasma desktop which doesn't have very good Wayland support yet at the time of writing, so I'm using a Xorg session. mpv can also be used to play YouTube videos, as long as the youtube-dl package is also installed. The best command for this use case is mpv --hwdec=auto --profile=a4k --ytdl-format="bestvideo[ext=mp4]+bestaudio[ext=m4a]/mp4" [link to the youtube video]

Although my primary browser is Firefox, I also want to have a GPU-accelerated browser around to browse intensive websites with and, realistically, to play online videos on - it gets tedious to use mpv all the time. Neither Firefox nor Chromium support VA-API by default, so I use the chromium-vaapi-bin package from the AUR:

# yay -S chromium-vaapi-bin

Arch Forums reference: https://bbs.archlinux.org/viewtopic.php?id=244031

However, the work is not over. You should create a ~/.config/chromium-flags.conf that looks like the following:

--force-device-scale-factor=1.25 --ignore-gpu-blacklist --enable-gpu-rasterization --enable-native-gpu-memory-buffers --enable-zero-copy --enable-accelerated-mjpeg-decode --enable-accelerated-video --use-gl=egl --disable-gpu-driver-bug-workarounds

Note: --force-device-scale-factor=1.25 is not a necessary argument to enable GPU acceleration, as all it will do is to scale the Chromium window by 125%. My laptop has a 1080p monitor and I don't find Chromium to scale well by default, and I find the interface much more readable at 125% scale. This value changes depending on your dpi and eyesight.

To make sure this works well, start a YouTube video and then check for the following things:

  • In chrome://media-internals/ > your video stream, a table should show up. The value associated to video_decoder should either be MojoVideoDecoder or GpuVideoDecoder. If it reads anything else but one of these two strings, then you're still using software acceleration.
  • In chrome://gpu "Video Decode" should read "Hardware Accelerated".

Installing the h264ify extension might help in case CPU usage is still too high, but it's a workaround, rather than a solution.

Solaar

My mouse is a Logitech MX Master 2S. It's fantastic, but Logitech does not provide any Linux software to control some of its settings. Fortunately, FOSS project Solaar helps with this:

# pacman -S solaar

I hide its system tray icon because KDE Plasma already tells me my mouse's remaining battery life.

Setting up touchpad gestures

Arch Wiki reference: https://wiki.archlinux.org/index.php/Libinput

libinput-gestures README: https://github.com/bulletmark/libinput-gestures/blob/master/README.md

My laptop comes with an excellent touchpad. Unfortunately, Linux distros don't ship an equally excellent touchpad driver / implementation. The only real fix would be to contribute to the Libinput project and improve it, but for now we can use libinput-gestures as a workaround.

The first thing you should do is to make sure you're using the libinput driver. If you are not, remove the xf86-input-synaptics, xf86-input-evdev packages and reboot. Finally, I'm using Xorg for this and I don't recommend using this hack in Wayland since desktop environments in Wayland typically have better touchpad gestures already.

Once that's cleared, it's time to install AUR package libinput-gestures as well as other packages from the repos we will need.

# pacman -S xdotool wmctrl
# yay -S libinput-gestures

libinput-gestures will detect touchpad gestures and run a command when any set gesture is detected. xdotool will react to this by simulating keyboard events. To allow xdotool to work, the user you're using should be added to the input group:

# gpasswd -a $USER input

My dotfiles already contain a valid ~/.config/libinput-gestures.conf file that works well with a Plasma session set up with my own keybindings. Finally, let's finish the setup:

libinput-gestures-setup autostart
libinput-gestures-setup start
@sr-machado
Copy link

Pretty good tips. For touchpad gestures i'd like to suggest Fusuma.

@iTrooz
Copy link

iTrooz commented Nov 5, 2021

Hey, I don't really have anything to say, I just wanted to thank you for this gist !

@2legit2git
Copy link

This has been enlightening and helpful. Thank you!

@juangiordana
Copy link

juangiordana commented Apr 22, 2022

intel-ucode is being installed twice.

PS: Learning a lot from this gist. Thanks!

@OpAmlee
Copy link

OpAmlee commented Jun 14, 2022

thanks for the work!!

@LucyHimelson
Copy link

thx yo

@rvizx
Copy link

rvizx commented Apr 6, 2024

thanks ^^

@sametaor
Copy link

sametaor commented Jun 7, 2024

Thanks for the tips! As a matter of fact, even I am running Arch with a win10 dualboot on a Dell Inspiron 5567 with the exact same processor, albeit a different DE than Plasma.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment