The websites in question are actually on GitHub Pages and my servers are just acting as reverse proxy to resolve domain and TLS, and a look into the web server’s error.log showed that the issue in serving was that the server could no longer reach its upstream at github.io when Tailscale was active. It wasn’t a general loss of external connectivity though - IPv4 addresses still worked great, the webserver however was trying to connect to the upstream via IPv6 and this is where things failed.

I did some quick tests, pinging Google’s DNS on both IPv4 (8.8.8.8) and IPv6 (2001:4860:4860::8888) with Tailscale running, and that showed that while Tailscale was running, IPv6 connectivity just broke down completely while IPv4 continued to work:

$ sudo tailscale up && ping -c 3 8.8.8.8 && sudo tailscale down
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=3.98 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=3.69 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=3.63 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 3.631/3.771/3.986/0.162 ms

$ sudo tailscale up && ping -c 3 2001:4860:4860::8888 && sudo tailscale down
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes

--- 2001:4860:4860::8888 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2051ms

As a next step, I checked the route that would be taken for resolving 2001:4860:4860::8888 with and without Tailscale:

$ ip route get 2001:4860:4860::8888
2001:4860:4860::8888 from :: via fe80::1 dev eth0 src aaaa:bbbb:cccc:dddd::1 metric 1024 pref medium

$ sudo tailscale up && ip route get 2001:4860:4860::8888 && sudo tailscale down
2001:4860:4860::8888 from :: via fe80::1 dev eth0 src fd7a:115c:a1e0::aaaa:bbbb metric 1024 pref medium

So, the issue was that for some reason, while Tailscale was running the system decided to use Tailscale’s internal IPv6 fd7a:115c:a1e0::aaaa:bbbb set on tailscale0 as the source IP but send the packet through the default route and eth0, and that didn’t work. It basically hijacked the IPv6 traffic, even when the Tailnet wasn’t even involved.

The routes looked fine to me and some buddies I asked also didn’t spot anything amiss:

$ ip -6 rule show
0:      from all lookup local
5210:   from all fwmark 0x80000/0xff0000 lookup main
5230:   from all fwmark 0x80000/0xff0000 lookup default
5250:   from all fwmark 0x80000/0xff0000 unreachable
5270:   from all lookup 52
32766:  from all lookup main

$ ip -6 route show table local
local ::1 dev lo proto kernel metric 0 pref medium
local aaaa:bbbb:cccc:dddd::1 dev eth0 proto kernel metric 0 pref medium
local fd7a:115c:a1e0::aaaa:bbbb dev tailscale0 proto kernel metric 0 pref medium
local fe80::5fdc:58a7:1a93:da5a dev tailscale0 proto kernel metric 0 pref medium
local fe80::9400:ff:fe0d:61a1 dev eth0 proto kernel metric 0 pref medium
multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium
multicast ff00::/8 dev tailscale0 proto kernel metric 256 pref medium

$ ip -6 route show table 52
fd7a:115c:a1e0::53 dev tailscale0 metric 1024 pref medium
fd7a:115c:a1e0::/48 dev tailscale0 metric 1024 pref medium

$ ip -6 route show table main
aaaa:bbbb:cccc:dddd::/64 dev eth0 proto kernel metric 256 pref medium
fd7a:115c:a1e0::aaaa:bbbb dev tailscale0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 pref medium

From what I could see, firing up Tailscale would add the following new rules to the routing table:

$ ip route show table all > ts-off.txt
$ sudo tailscale up && ip route show table all > ts-on.txt && sudo tailscale down
$ diff ts-off.txt ts-on.txt
0a1,2
> 100.a.b.c dev tailscale0 table 52
> 100.100.100.100 dev tailscale0 table 52
3a6
> local 100.x.y.z dev tailscale0 table local proto kernel scope host src 100.x.y.z
12a16,17
> fd7a:115c:a1e0::53 dev tailscale0 table 52 metric 1024 pref medium
> fd7a:115c:a1e0::/48 dev tailscale0 table 52 metric 1024 pref medium
13a19
> fd7a:115c:a1e0::aaaa:bbbb dev tailscale0 proto kernel metric 256 pref medium
17a24
> local fd7a:115c:a1e0::aaaa:bbbb dev tailscale0 table local proto kernel metric 0 pref medium

I still have not figured out what is actually going on there, and a reproduction on a fresh server so far also wasn’t successful. The problem is that packets are being sent with the wrong source IPv6, but that’s just a symptom of the underlying cause.

Thankfully, my buddy Jub came up with the workaround to change the default route to use a fixed IPv6 source address - the correct one - and that solved the issue (by fixing the symptom):

ip -6 route replace default via fe80::1 dev eth0 src aaaa:bbbb:cccc:dddd::1

I put that on a new post-up line into the network setup in /etc/network/interface.d/50-cloud-init.cfg

auto eth0:0
iface eth0:0 inet6 static
    address aaaa:bbbb:cccc:dddd::/64
    gateway fe80::1
    post-up route add -net :: netmask 0 gw fe80::1%eth0 || true
    post-up ip -6 route replace default via fe80::1 dev eth0 src aaaa:bbbb:cccc:dddd::1 || true
    pre-down route del -net :: netmask 0 gw fe80::1%eth0 || true

A reboot confirmed that this works as a workaround.

But as I mentioned, I still can’t make any sense of the underlying issue. I found one open bug report in Tailscale’s bug tracker that sounded familiar, but it didn’t fully match my situation. I also have to admit that my administration skills kinda get a bit fuzzy when it comes to full blown route analysis & debugging - so should you have any ideas at all what is actually causing this behaviour here, please get in touch on Mastodon - I’d love to see this mystery solved, but am out of my depth here 😅

You might remember from a previous TIL that I had my Steamdeck configured to push my screenshots into a custom album on Google Photos. Obviously I had to change that now as well, but sadly couldn’t use the existing rclone-based setup for it.

My first idea was to utilize immich-go, as I have just successfully used that for the three day long import of over 50000 pictures from my Google Photos takeout into immich. But that turned out to not be the right tool here: in order to not even try to upload already existing files it will fetch an asset list from immich first, and while that really improves performance for large batch imports, it takes way too long for uploading a single new screenshot.

So instead I went with something self-built which utilizes immich’s API.

A custom upload script

The first part is this little bash script that will take a file as input, upload it to a pre-configured immich instance and also add it to a pre-defined album (which already has to exist). This lives in ~/.local/bin/immich-upload.sh:

#!/bin/bash
set -e

IMMICH_SERVER="https://immich.example.com"
IMMICH_KEY="your api key goes here"
IMMICH_ALBUM="your album id goes here"

INPUT="$1"
if [ "$INPUT" == "" ]; then
    echo "immich-upload.sh <file>"
    exit 0
fi

file_modified=$(stat -c %Y "$INPUT" | date --iso-8601=seconds)
name=$(basename "$INPUT")

# ---

echo "Uploading $INPUT to immich..."

upload=$(curl -sL --request POST "$IMMICH_SERVER/api/assets" \
    -H "Content-Type: multipart/form-data" \
    -H "Accept: application/json" \
    -H "X-API-Key: $IMMICH_KEY" \
    -F "deviceId=\"curl/steamdeck\"" \
    -F "deviceAssetId=\"$name-$file_modified\"" \
    -F "fileCreatedAt=\"$file_modified\"" \
    -F "fileModifiedAt=\"$file_modified\"" \
    -F "assetData=@\"$INPUT\"")

id=$(echo "$upload" | jq -r .id)

echo "Uploaded file, asset id is $id"

# ---

echo "Adding file to album $IMMICH_ALBUM..."

payload=$(jq -n --arg id $id '{ids:[$ARGS.named.id]}')
album=$(curl -sL --request PUT "$IMMICH_SERVER/api/albums/$IMMICH_ALBUM/assets" \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "X-API-Key: $IMMICH_KEY" \
    -d "$payload")

echo "... done"

Reacting to new screenshots

I use watchexec to listen for changes in my custom screenshot folder (see this TIL post on how to set that up) and calling the upload script with the correct file name. I downloaded a release build of watchexec and threw it into ~/.local/bin, then created another script ~/.local/bin/sync-screenshots that takes care of setting all of the correct parameters¹:

#!/usr/bin/env bash

WATCHEXEC="${HOME}/.local/bin/watchexec"
FOLDER="${HOME}/.steam_screenshots"

${WATCHEXEC} --exts jpg,png,mp4 --fs-events create --emit-events-to environment -w $FOLDER -o queue -p -v -- '/home/deck/.local/bin/immich-upload.sh "$WATCHEXEC_COMMON_PATH/$WATCHEXEC_CREATED_PATH"'

Putting it all together

Finally, a new systemd unit in ~/.config/systemd/user/sync-screenshots.service takes care of starting this bash script and keeping it running:

[Unit]
Description=Sync Steam Screenshots

[Service]
ExecStart=%h/.local/bin/sync-screenshots
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

I enabled and started that:

systemctl --user enable sync-screenshots
systemctl --user start sync-screenshots

Then I took a screenshot and confirmed that the script had run:

Mar 25 15:17:03 steamdeck sync_screenshots[77135]: [Running: /home/deck/.local/bin/immich-upload.sh "$WATCHEXEC_COMMON_PATH/$WATCHEXEC_CREATED_PATH"]
Mar 25 15:17:03 steamdeck sync_screenshots[77188]: Uploading /home/deck/.steam_screenshots/7_20250325151703_1.png to immich...
Mar 25 15:17:04 steamdeck sync_screenshots[77188]: Uploaded file, asset id is 141dc605-edef-48f1-83b5-00bd9d72b13e
Mar 25 15:17:04 steamdeck sync_screenshots[77188]: Adding file to album 0ce35e68-a564-4e26-921e-c486cd9e4725...
Mar 25 15:17:05 steamdeck sync_screenshots[77188]: ... done
Mar 25 15:17:05 steamdeck sync_screenshots[77135]: [Command was successful]

And indeed, upon checking my immich instance, I was also looking at the freshly uploaded screenshot. Mission accomplished!

VirtualBox can’t operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_VMX_IN_VMX_ROOT_MODE).

A quick web search for “fedora update virtualbox vboxisomaker” gave me this forum post and consequently this bug report, in which I found the solution: I just had to add the kernel parameter kvm.enable_virt_at_load=0 to disable KVM - which comes enabled by default since Kernel 6.12. I accomplished that with grubby:

sudo grubby --update-kernel=ALL --args="kvm.enable_virt_at_load=0"

After a reboot, VirtualBox started again.

Given how often VirtualBox breaks for me on updates, long term I think I really need to find a different solution… And yes, I also really need to upgrade to Fedora 41, I know 😉

I recently acquired a Brother QL-820NWB label printer to be able to quickly create labels for boxes and such, and ideally also print out Deutsche Post’s “print yourself” stamps with it. The Deutsche Post stamp shop allows me to download PDFs targeting the 62mm wide endless labels for that printer, for the two types of stamps I’m interested in (stamp, and address label with stamp). But my attempts in printing those directly to the printer through Gnome’s printer integration weren’t successful, things were too small, the cutter didn’t work etc.

I knew that printing to the printer via my local instance of brother_ql_web works flawlessly, and that the library this is based on, brother_ql, has a command line interface. So I thought, why not just convert the PDFs to individual PNGs, and then print those?

Through the magic of some shell scripting, I’m now able to do just that, right from the command line.

I installed the brother_ql Python package via pip:

pip install --user brother_ql

I had to do a little manual patch to make it work with the latest versions of the required Pillow dependency, by editing brother_ql/conversion.py and changing Image.ANTIALIAS to Image.LANCZOS.

I also made sure my .bash_profile contains the address and model of my printer:

export BROTHER_QL_PRINTER=tcp://192.168.x.x
export BROTHER_QL_MODEL=QL-820NWB

Then I created two shell scripts, one for printing stamps and one for printing labels.

The first one, porto_print, takes care of printing the stamps. It resizes, trims, adds a new border and then extends to the native width for the selected label size (50mm by default, or 62mm if requested) while keeping a right alignment:

#!/bin/bash

# Usage:
#
#   porto_print <pdf> [50|62]

#!/bin/bash

tmpdir=$(mktemp -d)

cleanup() {
  rm -rf "$tmpdir"
}
trap cleanup EXIT

PDF=$1
LABEL=${2:-50}
PNG=$(basename "${PDF%.*}")

case $LABEL in
  "50")
    WIDTH="554"
    ;;
  "62")
    WIDTH="696"
    ;;
  *)
    echo "Unsupported label size: $LABEL"
    exit -1
    ;;
esac

echo "Converting PDF to individual PNGs..."
pdftoppm "$PDF" "$tmpdir/$PNG" -png -r 600

for file in $(ls $tmpdir/*.png); do
  echo "Printing $file..."
  mogrify -background white -bordercolor white -resize 696x -trim -border 25x25 -gravity east -extent ${WIDTH}x284 "$file"
  brother_ql print -l $LABEL "$file" 
done

The second one, porto_address_print, does basically the same, just with slightly different parameters and left alignment:

#!/bin/bash

# Usage:
#
#   porto_address_print <pdf>

tmpdir=$(mktemp -d)

cleanup() {
  rm -rf "$tmpdir"
}
trap cleanup EXIT

PDF=$1
LABEL=${2:-50}
PNG=$(basename "${PDF%.*}")

case $LABEL in
  "50")
    WIDTH="554"
    ;;
  "62")
    WIDTH="696"
    ;;
  *)
    echo "Unsupported label size: $LABEL"
    exit -1
    ;;
esac

echo "Converting PDF to individual PNGs..."
pdftoppm "$PDF" "$tmpdir/$PNG" -png -r 600

for file in $(ls $tmpdir/*.png); do
  echo "Printing $file..."
  mogrify -bordercolor white -background white -resize 696x -trim -border 25x25 -gravity West -extent ${WIDTH}x839 "$file" 
  brother_ql print -l $LABEL "$file" 
done

Both of these were placed under ~/.local/bin and made executable. I can now call them both from anywhere on the command line, just passing the path to the PDF to print.

The result is one or more nicely printed stamps or address labels, ready to be stuck to an envelope:

Now, this should hopefully make it easier for me to print all those address labels for OctoPrint sticker shipments in the future ;) Next step: Automated QR code labels for the various boxes on my shelves ^^

He has a dual boot setup running using rEFInd, and while that survived the OS update just fine, when he wanted to return to SteamOS after a quick stint in Windows today, he was greeted by a GRUB boot menu.

Detective foosel to the rescue.

Attempting to boot the SteamOS entry in grub resulted in an error like this (with another device UUID):

error: no such device: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
error: file `/boot/vmlinuz-linux-neptune` not found.
error: you need to load the kernel first.

Press any key to continue...

So it couldn’t find it’s boot device and due to that also not the kernel stored thereon.

Entering the Deck’s boot manager and manually booting \efi\steamos\steamoscl.efi also led to the same situation.

I was able to still boot into SteamOS via the fallback entry however (which also had a different boot device UUID).

And it took me way too long¹ to simply just get the idea to let Linux update its GRUB entries:

sudo update-grub

That fixed it.

No idea if the dual boot setup played a roll in this mess or if it was just some random hiccup, my Deck’s update went without a hitch 🤷‍♀️ But if it happens again I now have this entry to check 😁

$ sudo /sbin/vboxconfig 
[sudo] password for gina: 
vboxdrv.sh: Stopping VirtualBox services.
depmod: WARNING: could not open modules.order at /lib/modules/6.3.8-200.fc38.x86_64: No such file or directory
depmod: WARNING: could not open modules.builtin at /lib/modules/6.3.8-200.fc38.x86_64: No such file or directory
depmod: WARNING: could not open modules.builtin.modinfo at /lib/modules/6.3.8-200.fc38.x86_64: No such file or directory
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.
egrep: warning: egrep is obsolescent; using grep -E
vboxdrv.sh: failed: Look at /var/log/vbox-setup.log to find out what went wrong.

There were problems setting up VirtualBox.  To re-start the set-up process, run
  /sbin/vboxconfig
as root.  If your system is using EFI Secure Boot you may need to sign the
kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) before you can load
them. Please see your Linux system's documentation for more information.

A look into /var/log/vbox-setup.log revealed an error along the lines of this one¹:

/tmp/akmodsbuild.bPlgZsDR/BUILD/VirtualBox-kmod-7.0.10/_kmod_build_6.4.10-200.fc38.x86_64/vboxnetflt/linux/VBoxNetFlt-linux.c: In function 'vboxNetFltLinuxForwardToIntNetInner':
/tmp/akmodsbuild.bPlgZsDR/BUILD/VirtualBox-kmod-7.0.10/_kmod_build_6.4.10-200.fc38.x86_64/vboxnetflt/linux/VBoxNetFlt-linux.c:1570:40: error: implicit declaration of function 'skb_gso_segment'; did you mean 'skb_gso_reset'? [-Werror=implicit-function-declaration]
 1570 |             struct sk_buff *pSegment = skb_gso_segment(pBuf, 0 /*supported features*/);
      |                                        ^~~~~~~~~~~~~~~
      |                                        skb_gso_reset
/tmp/akmodsbuild.bPlgZsDR/BUILD/VirtualBox-kmod-7.0.10/_kmod_build_6.4.10-200.fc38.x86_64/vboxnetflt/linux/VBoxNetFlt-linux.c:1570:40: warning: initialization of 'struct sk_buff *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
cc1: some warnings being treated as errors

I did some web searching and came across this post on the Fedora forums with someone having the exact same issue, and found a solution in the comments courtesy of Peter Francis:

Adding

#include <net/gso.h>

below the line

#include <linux/inetdevice.h>

in /usr/share/virtualbox/src/vboxhost/vboxnetflt/linux/VBoxNetFlt-linux.c fixed it for me.

Hopefully when the file gets overwritten on next VirtualBox update the fix will be already added by VirtualBox’s programmers.

And what can I say, it also fixed it for me! And should this not get fixed in the next update, now I’ll know where to find the solution again - my own TIL post 😉

PS: Something tells me this won’t be the last VirtualBox related TIL post I’ll write…

ssh admin@192.168.1.1 'sudo tcpdump -f -i eth1 -w - src 192.168.1.12' | wireshark -k -i - 

I could confirm that this works and created a small script to make it easier to use by throwing this into ~/.local/bin/gatedump²:

#!/bin/bash

ARGS="$@"
TCPDUMP="sudo tcpdump -f -w - $ARGS"

ssh usg "$TCPDUMP" | wireshark -k -i -

This now allows me to easily run tcpdump remotely with custom arguments, e.g. gatedump -i eth1 host 192.168.1.123, and have it fire up Wireshark automatically. Wish me luck I’ll now be able to figure out what’s going on on my network, because it’s driving me up the wall.

Update from 2023-12-06: In case you are wondering how this story ended, the issue resolved itself with the next OS update of my partner’s iPhone. So whatever caused it, it’s gone now, and I hope for good.

Jun 13 10:23:50 draper kernel: traps: Missing ENDBR: 0xffff9b688c308f30

After some searching I came across this thread on the VirtualBox forums which explained the issue and also includes the solution. Apparently the VirtualBox kernel driver triggers Intel’s IBT (indirect branch tracking). The solution is to disable that¹ by passing ibt=off as a kernel parameter:

sudo grubby --update-kernel=ALL --args="ibt=off"

After a reboot I could rebuild the vbox kernel driver via /sbin/vboxconfig, which ran through without issues, and after that the VM started up just fine.

Battle.net is currently having a spring sale and I’ve been eyeing Diablo II: Resurrected for a while now, so I jumped on the chance (and while at it also got StarCraft Remastered). But given that these days I primarily game on the Steamdeck, I needed to find a way to install Battle.net on my deck and also install individual launchers for the games.

Battle.net

I first made the mistake of trying my luck with installing the Battle.net launcher directly via Steam Proton. Trust me: Don’t. Lots of work, doesn’t end up well. Instead, I went with Lutris. Lutris has been installed for a while, but if that’s not yet on your deck, install that first via the Discover app. Then:

1. Enter desktop mode
2. Navigate to https://lutris.net/games/battlenet/ and click on “Install”. That will fire up an install script in your Lutris setup. Follow the steps shown to you by the app.
3. Once the installer has run its course, log into Battle.net. You should now be able to download stuff.
4. Right click on Battle.net in Lutris, select “Add steam shortcut” (if that’s not available, but “Delete steam shortcut” is - nothing to do, the shortcut has already been added). This will become available after Steam has been restarted, don’t worry about it now.

Diablo II: Resurrected

This will create a Lutris app that uses the same Wine prefix as your Battle.net install. This is important! In desktop mode:

1. Navigate to https://lutris.net/games/diablo-2-ressurected/ (not a typo, there is a typo in that slug indeed), click “Install”. Follow the steps.
2. If not yet done, launch Battle.net and install Diablo II: Resurrected.
3. Launch Diablo once via Battle.net, exit as soon as you can.
4. In Lutris, right click on the Diablo entry, select “Configure” and go to “Game options”
5. Click “Browse” next to “Executable”. Change it to to /home/deck/Games/battlenet/drive_c/Program Files (x86)/Diablo II Resurrected/D2R.exe (so, one folder up, into the Diablo folder and there select D2R.exe)
6. Under Arguments add -launch
7. Save

Make sure the Steam shortcut for the app is added.

StarCraft

Just as with Diablo II, it is important that the StarCraft entry uses the same Wine prefix as Battle.net. Either duplicate the existing “Diablo II: Resurrected” entry or alternatively follow steps 1 and 2 above. Then do the following with your game entry:

1. Launch Battle.net, install Starcraft Remastered.
2. Right click on the designated game entry (either your duplicate of Diablo II, or the Diablo II entry you don’t intend to use), select “Configure”
3. Under “Game info”, change the name to “Starcraft Remastered” and the identifier to “starcraft-remastered”
4. Under “Game options”, change the executable to /home/deck/Games/battlenet/drive_c/Program Files (x86)/StarCraft/x86_64/StarCraft.exe and add -launch to the Arguments
5. Save

The art in Lutris should update automatically. Make sure the Steam shortcut for the app is added.

Once all of that is done, head back into game mode. Feel free to change the art for the newly created entries, e.g. through something like the SteamGridDB plugin for Decky. I also set up a dedicated “Battle.net” collection and added Battle.net itself plus both games to it.

You should now be able to launch your games through their individual Steam shortcuts. Note that the way we have set up things, Battle.net will not be fully available, so if you need that (for multiplayer or for unlocking DLCs) you’ll need to launch through the Battle.net shortcut instead. In the case of the Cartoon skin for StarCraft Remastered, launching Starcraft once through Battle.net sufficed however ^^

My secondary monitor is a 24" DELL with a resolution of 1920x1200, so 16:10, instead of the more common 1080p and 16:9. In order to be able to connect all my three monitors to my laptop, I make use of both the laptop’s HDMI port as well as a USB-C dock that has 2 HDMI ports. The 4k main display is connected directly to the laptop’s HDMI port, secondary and tertiary display are connected to the dock.

The problem now was that as long as I had both secondary and tertiary connected, I could only select up to 1080p for the secondary. That would not have been that big of an issue if that wouldn’t have caused the monitor to try to scale the 16:9 output to 16:10, stretching it. With only the secondary display attached however, it would detect the 16:10 resolution just fine.

On Windows, with the same hardware setup (albeit a different laptop), this was quickly solved with a third party tool and ran just fine for months. On Linux I was stumped for the past few weeks since switching. Adding video= lines to the kernel parameters - as suggested by various guides - didn’t seem to do the trick, and that appears to be the only option these days with Wayland in the mix to do something like this.

Today however I fell over this helpful section on the ArchLinux wiki, and that gave me an idea. Apparently the EDID information of the secondary is correct when it is connected alone, or I wouldn’t be able to select 1920x1200 then. So I should be able to just grab the EDID data from it when working and force that to be used all the time via a kernel parameter.

I disconnected my tertiary display and verified the secondary was now again being detected as supporting 1920x1200. Then I first figured out its port by checking which of the available devices showed as connected (and wasn’t the internal laptop screen or the 4k primary):

$ for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done
DP-1: disconnected
DP-2: connected
DP-3: disconnected
DP-4: disconnected
DP-5: disconnected
DP-6: connected
DP-7: disconnected
eDP-1: connected

In my case that turned out to be DP-6¹. Next I quickly dumped the EDID information to a new file /usr/lib/firmware/edid/dell-24-1200p.bin:

sudo mkdir -p /usr/lib/firmware/edid
sudo cp /sys/class/drm/card1-DP-6/edid /usr/lib/firmware/edid/dell-24-1200p.bin

Then I used grubby to add a drm.edid_firmware kernel mode setting to all kernel entries for DP-6 that tells the kernel to use this EDID file:

sudo grubby --update-kernel=ALL --args="drm.edid_firmware=DP-6:edid/dell-24-1200p.bin"

And one reboot later I could finally select 1920x1200 for my display! 🥳

Addendum from 2023-05-24*: Recently the display’s identifier’s started switching between DP-6 and DP-8, sometimes even when waking up from sleep. I’m not sure why, and I so far did not have time to investigate, but just so I or anyone else stumbling over this knows how to do this in the future, it’s easy to set custom edid data on multiple devices as well, in my case:

sudo grubby --update-kernel=ALL --args="drm.edid_firmware=DP-6:edid/dell-24-1200p.bin,DP-8:edid/dell-24-1200p.bin"