Linux with UP2715K (or T221 or any other composite monitor), Xorg, Xinera, XRandR

It is most unfortunate that the best monitors of any era are always a little quirky. I used an IBM T221 for over a decade as my main work and play monitor with it’s, for the time (they came out in 2003!), staggering 3840×2400 (4K+) resolution. But the fact that it had to pretend to be two separate monitors to shift enough pixels to achieve such high resolutions at a decent refresh rate always caused problems, especially on Linux.

The much younger Dell UP2715K also requires two separate DisplayPort inputs to achieve the full 5K (5120×2880) resolution.

The problem is that this kind of a setup is very unusual. I am aware of only the two mentioned monitors that use this kind of input arrangement. Consequently, most developers of desktop environments and GPU drivers seemingly couldn’t care less about supporting it. I covered how to deal with this with a T221 monitor in the past using both Nvidia drivers (which have built in option to lie to the desktop environment about the monitor geometry) and AMD drivers (which require use of the fakexinerama LD_PRELOAD library).

The problem is that both of these workarounds require Xinerama support, and this is mostly being deprecated and removed. Modern Xorg, for example, by default has Xinerama disabled and XRandR (as a more modern replacement) enabled. Unfortunately, Nvidia drivers don’t seem to have the option to fake the RandR geometry data.

So, to make this work, we need to pass Xorg options that are not passable purely via xorg.conf. The trick we used years ago with T221 on Linux no longer work. How do we do this? Modern EL7/EL8/EL9 ship with a shell script for /usr/bin/Xorg:

# Execute Xorg.wrap if it exists otherwise execute Xorg directly.
# This allows distros to put the suid wrapper in a separate package.

if [ -x "$basedir"/Xorg.wrap ]; then
	exec "$basedir"/Xorg.wrap "$@"
	exec "$basedir"/Xorg "$@"

We can modify this to additionally pass additional parameters: -extension RANDR +xinerama

But it turns out that as of EL9, this breaks gdm login. So we have to run gdm without these extra Xorg options, but for the real user session we have to add those options in so that both gdm and KDE plasma work. Thankfully, there is an easy way to detect whether Xorg is running for gdm login or a real user because gdm login runs as the gdm user, but a user session runs as that user. So to make it all work, we modify the Xorg shell script wrapper as follows:

# Execute Xorg.wrap if it exists otherwise execute Xorg directly.
# This allows distros to put the suid wrapper in a separate package.



if [ "$USER" != "gdm" ]; then
	EXTRA="-extension RANDR +xinerama"

if [ -x "$basedir"/Xorg.wrap ]; then
	exec "$basedir"/Xorg.wrap $EXTRA "$@"
	exec "$basedir"/Xorg $EXTRA "$@"

Combine that with a xorg.conf fragment similar to what we used before with the T221, and we have a fully working GDM login with KDE plasma desktop. All the benefits of fantastic image quality, and none of the compromises.

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1080Ti"
    Option         "NoLogo" "1"
    Option         "TripleBuffer" "True"

Section "Screen"
	Identifier     "Screen0"
	Device         "Device0"
	Monitor        "Monitor0"
	DefaultDepth    24
	Option	"Coolbits" "28"
	Option	"UseEdidDpi" "False"
	Option	"DPI" "96 x 96"
	Option	"TwinView" "True"
	Option	"ConnectedMonitor" "DP-0, DP-2"
	Option	"NoTwinViewXineramaInfo" "True"
	Option	"nvidiaXineramaInfo" "False"
	Option	"MetaModes" "DP-2:2560x2880 +0+0, DP-0:2560x2880 +2560+0"
	SubSection     "Display"
		Depth	24

Obviously these options require an Nvidia GPU driver. For AMD GPUs you will have to apply a different workaround.

Slack Notifications Hang KDE – The Workaround

This has been annoying me for a while on EL8 (CentOS / Rocky / Alma / RedHat). It actually affects more than just Slack – it can affect most things that send desktop notifications, but Slack is where I first noticed it. I haven’t been able to find a proper fix for it, but here is a workaround:

sudo rm /usr/share/dbus-1/services/org.kde.plasma.Notifications.service

Notifications that used to hang the app for minutes will now not go off at all and everything will continue smoothly.

Virtualized Windows 10 – i440FX vs Q35

QEMU supports two x86 chipsets it can emulate. The very ancient (1996) i440FX chipset and the more recent (2007) Q35 chipset. For a long time, Q35 was advised against for GPU passthrough because some parts weren’t quite fully addressed. On the other hand, the advantage of Q35 is that it supports PCIe natively. i440FX only supports PCI and all passed through hardware had to pretend to be PCI rather than PCIe. In theory, this means that Q35 should lead to a slightly lower emulation overhead, so I decided to test it between different workstation seats on my virtualized workstation server.

Initial results are quite interesting. I left both VMs idle after booting with as close to identical setup as there can be (other than Q35 vs i440FX). After around 3 hours, I measured the total CPU time spent while idling. These are two otherwise identical VMs sitting at their login screens after booting:

15:24.01 i440fx
11:53.29 q35

So it looks like the VM based on Q35 emulated chipset used about 23% less CPU while idling. I haven’t noticed any performance difference by the seat of my pants after conversion to Q35. I haven’t actually run any other benchmarks yet, but a 23% CPU saving with Q35 when idling seems significant. Especially if you have a lot of Windows VMs running that are sitting idle most of the time.