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:
#!/usr/bin/sh # # Execute Xorg.wrap if it exists otherwise execute Xorg directly. # This allows distros to put the suid wrapper in a separate package. basedir=/usr/libexec if [ -x "$basedir"/Xorg.wrap ]; then exec "$basedir"/Xorg.wrap "[email protected]" else exec "$basedir"/Xorg "[email protected]" fi
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:
#!/bin/sh # # Execute Xorg.wrap if it exists otherwise execute Xorg directly. # This allows distros to put the suid wrapper in a separate package. basedir=/usr/libexec USER=$(whoami) EXTRA="" if [ "$USER" != "gdm" ]; then EXTRA="-extension RANDR +xinerama" fi if [ -x "$basedir"/Xorg.wrap ]; then exec "$basedir"/Xorg.wrap $EXTRA "[email protected]" else exec "$basedir"/Xorg $EXTRA "[email protected]" fi
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" EndSection 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 EndSubSection EndSection
Obviously these options require an Nvidia GPU driver. For AMD GPUs you will have to apply a different workaround.