No display output with KVM switch

[Brian Cully]

[Preface: this is the first bare-metal FreeBSD installation I've done in Quite Some Time (since FreeBSD 4, if memory serves), things have changed a lot since then, and I've not kept up in the intervening decades.]

I've got my FreeBSD-11 box hooked up to a KVM switch via DisplayPort (I have another switch that exhibited the same issue which used HDMI), and while I can use it to boot, when I toggle the switch to one of my other computers, and some time later toggle back, I cannot get console output on my monitor (I'm only using the text console on this box). If I never toggle the KVM away from FreeBSD I have no issues, but obviously that's less than ideal.

The box itself has an HDMI and DisplayPort output (but just the built-in graphics chipset of whatever variety Intel's put into Skylake), which I'm assuming causes FreeBSD some confusion when the display goes away, as it no longer knows where to send it's display but I'll admit I'm now out of my depth and don't even know how to diagnose if that's the issue somehow. The system's got AMI firmware that allows both UEFI and BIOS booting, of which I use the former, although I've tried the latter and still have the same issue (in addition to an 80x25 console).

And before anyone asks: yes, I've banged on the keyboard to see if it's just normal screen blanking; it isn't.

Help would be much appreciated, as the few times I've wanted to use the console I've also desperately wanted to see what was there.

 

[Snurg]

I think the problem is the KVM box.
You can verify that by connecting the FreeBSD computer directly to the monitor.
Plug, unplug, wait some time, plug, unplug.
I'd expect the monitor always to show picture (at least when no blanking).

If that's the case, the KVM box is the culprit.
Do you have the possibility to use maybe the VGA or DVI connector?
The HDMI transfer is digital serial data iirc, and maybe the KVM gets out of sync, thinking that there is no input.
With VGA and DVI there is no protocol, it's just serial datastream, no negotiations etc.
Might be best to even cut/short the VESA wires in the VGA connector to make the box think the cable is always connected.

 

[SirDice]

The HDMI transfer is digital serial data iirc, and maybe the KVM gets out of sync, thinking that there is no input.
With VGA and DVI there is no protocol, it's just serial datastream, no negotiations etc.

HDMI and DVI are actually the same (digital) signals, just a different type of connector (plus HDMI has some 'extra' signals, like ethernet channel, too). DVI-D is at least. DVI-A has the same (analog) signals as VGA. Which is why DVI-D -> HDMI and DVI-A -> VGA 'converters' are quite simple, as there's nothing to convert (electrically speaking), just a different connector.

With VGA and DVI there is no protocol, it's just serial datastream, no negotiations etc.

"Serial datastream" implies it's a digital signal, VGA uses analog signals. Because it's analog it's severely limited by both the resolution and refresh rate. It's also the reason why it never looks as sharp as DVI/HDMI on the same resolution and refresh rate.

 

[Snurg]

HDMI has some 'extra' signals, like ethernet channel, too)

And exactly these things seem to get "out of sync" (probably in the KVM boxes) some way when connection is interrupted by switching. This is why I suggested the monitor direct connect test to find out what part is problematic.
In this article is some background about the hotplug issue, mentioning also differences between DP and HDMI. (Here some info about HDMI)

"Serial datastream" implies it's a digital signal.

Not necessarily. You can encode things analog, producing an analog data stream. LCD VGA and DVI-A monitors digitalize it back then.
And analog modes do not know hotplug.

Anyway, if the monitor direct connect test shows that the culprit is not the KVM boxes, then it would indeed be a video driver issue not handling hotplugs correctly, if tests with different monitors show that it is not the monitor handling hotplugs incorrectly.