The Peculiarly Quiet Decline and Fall of the KVM

I bought a USB2.0/VGA switch online for A windows laptop and a linux NUC, 5 USB peripherals shared.

4K and all digital HDMI might spell the death of it but I'd be needing new PC(s) to drive such a display in any case.

Yes, no doubt that rack-based kvm stuff disappeared. It was awful: hard to rig, hard to use with confidence.

(Confidence? "Wait, wait, am I talking to data2 or web4 or what?)

KVM was a just-barely-competent solution to a hair-on-fire (=== must-solve-now) problem.

There are two possibilities:

1. Fake GPU software, which I haven't researched at all but probably exists

2. Forcing your graphics chipset to turn a specific head on and leave it on

Here's a Linux-specific example of how to do #2. Since I'm just talking to graphics hardware here, there should be equivalent operations for all of the following for other operating systems.

I don't connect an external display at any point.

First of all, how things look to begin with:

  $ xrandr   
  Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
  VGA-0 disconnected (normal left inverted right x axis y axis)
  DVI-0 disconnected (normal left inverted right x axis y axis)
  LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
     1024x768      60.00*+
     800x600       59.86  
     848x480       59.66  
     720x480       59.71  
     640x480       59.38  

Now, `xrandr --output VGA-0 --auto` isn't going to do anything because --auto will tell the GPU to pick the best resolution. No screen is attached so there's no list of resolutions to pick from.

So, I'll generate a generic CVT modeline that sets up the VGA output for 1024x768@60Hz.

  $ cvt 1024 768 60
  # 1024x768 59.92 Hz (CVT 0.79M3) hsync: 47.82 kHz; pclk: 63.50 MHz
  Modeline "1024x768_60.00"   63.50  1024 1072 1176 1328  768 771 775 798 -hsync +

Cool. Now I'll tell X11 about the modeline (note the copy-paste):

  $ xrandr --newmode  "1024x768_60.00"   63.50  1024 1072 1176 1328  768 771 775 798 -hsync +

...And now do the XRandR dance to actually tell the output about the right modeline (this is Xorg-bureaucracy-specific):

  $ xrandr --addmode VGA-0 "1024x768_60.00"

Let's review the xrandr output:

  $ xrandr
  Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
  VGA-0 disconnected (normal left inverted right x axis y axis)
     1024x768_60.00  59.92  
  (...)

At this point I can go ahead and

  $ xrandr --output VGA-0 --mode "1024x768_60.00"

and my screen displays garbage for a fraction of a second and then figures itself out.

At this point I know the output is enabled (and the glitch didn't mean nothing) and in mirroring mode. I can prove this without a display attached by running xrandr again:

  $ xrandr
  Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
  VGA-0 disconnected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
     1024x768_60.00  59.92* 
  (...)

Two things: one, the mode has an asterisk next to it, meaning it's active (albeit without a screen attached), and two (the following will make sense in a minute if it doesn't straight away) Screen 0 has a "current" size of 1024x768. (Xorg "screens" represent a collection of video outputs you can move windows between.)

So, let's disable mirroring mode and make this new Schrödinger-pseudo-existent area its own independent surface.

  $ xrandr --output VGA-0 --left-of LVDS

At this point, i3 (my windowmanager) decides to move every single window onto the new offscreen surface area, and I go blind. Isn't minimalist software wonderful? (A new windowmanager is on my todo list; i3 drives me nuts. Anyway.)

Once I sort i3 out and get back to a terminal, xrandr shows something new and interesting:

  $ xrandr
  Screen 0: minimum 320 x 200, current 2048 x 768, maximum 4096 x 4096
  (...)

Oh hey, the Screen size is now 2048x768! Proof that I have two 1024x... outputs configured side-by-side. If I wanted to I could do --above or --below and have a 1024x1536 display.

Here's the technical moral of the story: since approximately the time of the dinosaurs monitors have used EDID to provide autodetection info to graphics chipsets, so forcing manual configuration is pretty deeply buried.

But that's what you need to do; "my screen is weird and needs a custom configuration" and "okay just set these parameters and leave the output head running" are analogous.

If you want to turn your screen off and have the GPU keep the head running, I recommend figuring out how to fish out the modeline your GPU is currently using, and then force the GPU to manually use that modeline. That should disable output autodetection and keep the output permanently active.

Despite the fact that I've demoed Linux output configuration here, you're (ironically) not too likely to have this problem on Linux as Xorg is fairly flexible, and wouldn't normally need these kinds of instructions provided to it under normal circumstances; for Linux it would be more "what's explicitly killing the output and how do I turn it off" as opposed to digging around in driver settings.

Also - I picked VGA for this example, honestly probably for nostalgic reasons. These instructions will work equivalently regardless of output type.

Oh boy, the price! The article is lamenting the expense of 'modern' KVM switches.

For reference, a switch with 'legacy' USB 2.0/VGA connectors that powers my ageing home PCs is this model:

https://www.ebay.com.au/itm/All-in-one-Mini-2-Ports-KVM-Manu...

I replaced them with standalone USB & HDMI switches. I connect 5 PCs on my desk (main PC, Deep Learning rig, NAS, 2x NUC) first to two 4-port USB switches, then have one 2-port switch that switches between these two 4-port switches, and then a large HDMI switch. It works fine; each of those switches was <$5.