HD TFT vs. VGA-KVM Switch – and Linux

Multiple Computers at the same Keyboard, Video and Mouse – no problem when using a KVM Switch. Unfortunately, mine (DLink DKVM-2KU) does not seem to route the IDx-Pins of the VGA connector correctly, my system was not able to get the required EDID data to know which timings and resolutions are supported by the monitor.

This resulted in a max. resolution of 1360×768 pixels – way below the native 1920×1080 (which I could easily set when connecting the display directly via DVI or VGA). Most guides to add additional resolutions suggest asking gtf or cvt to calculate the respective timings (where for TFT-Displays CVT-based timings should be used, see e.g. http://www.uruk.org/~erich/projects/cvt/) and pasting these to xrandr to set the required mode. However, this does not work if xrandr thinks the monitor cannot take the requested frequencies.

A call to cvt may produce this:

X@Y ~ $ cvt 1920 1080
# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
Modeline "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync

The printed “modeline” contains all the timings needed for the card to drive the monitor at the requested resolution, however – in my case – adding the requested resolution resulted in an error, basically telling me that one of the parameters was not in a range supported by some device in the chain (DAC or Monitor for example):

X@Y ~ $ xrandr --newmode "1920x1080_60.00"  172.80  1920 2040 2248 2576  1080 1081 1084 1118  -HSync +Vsync
X@Y ~ $ xrandr --addmode VGA-0 "1920x1080_60.00"
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  18 (RRAddOutputMode)
  Serial number of failed request:  29
  Current serial number in output stream:  30

Most forum-threads, guides and Wiki-entires break at this point and say “Well, your monitor simply cannot do this”. Mine does, however the system doesn’t know. The source of the problem was in the X-Org config-file /usr/share/X11/xorg.conf.d/90-monitor.conf (in this case of Linux Mint 17.1, although I don’t know where this file came from – it doesn’t seem to be part of the standard system packages), which contained:

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       30.0 - 63.0
    VertRefresh     55.0 - 75.0
    Option         "DPMS"
EndSection

When I2C and therefore EDID is working correctly, the file seems to get overruled by the information provided by the monitor – in my case, EDID didn’t get past the KVM switch. The modeline calculated by cvt stated a pixel-clock of 172.80 MHz, together with a total virtual display width of 2576 points. This results in a horizontal refresh-rate of 67 kHz – which is higher than the maximum of 63 kHz given in the file.

Once I fixed this (I set it to 200, which is way to high, but doesn’t matter here…), xrandr accepted the mode. If you want this to be permanent, you might configure your X-Server according to this guide – but don’t forget to add the HorizSync and VertRefresh parameters!

But, for haven’s sake, be careful! Setting really wrong values will at least leave you without a picture (or an “Out of Range” message) for TFT screens, CRTs might get damaged!

Update: There’s annother error that I came accross when reinstalling the machine recently:

X Error of failed request:  BadName (named color or font does not exist)

This time, I simply had to change the name of the mode from “1920x1080_60.00” to “1080p” – problem solved. Possibly my Xsession-script did not fail completely and blocked the name for future use…