Re: FreeBSD/X11: Howto revive DisplayPort?

On Thu, 27 Nov 2025 07:47:47 -0800
Cy Schubert <Cy.Schubert@cschubert.com> wrote:

> One of HP 840 G5's docking station's DPs is connected to a VGA KVM
> switch via a DP to VGA connector. Confirmed, this is an issue.
> 
> The VGA KVM switch is also connected to my employer's HP 840 G9, also
> via a DP to VGA connector. No problems there. Though that machine uses
> the newer Thunderbolt docking station. Given that it's a newer machine
> with a newer docking station I think the comparison only goes so far.

In my specific case, the FreeBSD hosts are using DP, the KVM switch is a kind of hybrid
(2x DP, 1x HDMI fpr usage of 3 monitors simultaneously with the computer) and the monitor
itself is a 4k Lenovo, nothing fancy and/or expensive, just for doing conveniently my
work at home. In my office, the equipment is similar, except the KVM switch, which is a
DP only, more expensive type. In all cases, the host has a discrete nVidia GPU.
> 
> Whether this is a FreeBSD or a UEFI BIOS problem isn't quite understood
> by me. When booting the FreeBSD machine and if the KVM is not switched
> to the FreeBSD machine, the text mode console will have the wrong
> geometry. Even in single user the login prompt is far below the bottom
> of the monitor.
> 
> But once XDM has started it assumes a graphic geometry that fits the
> laptop's screen, not the external monitor. I have a script that
> disables the LVDS when the VGA is connected.

Similar here, but worse when it comes to console only, as initially described. If the
host booting and turning on the output for conosle is not switched to by the KVM - with
monitor in ON state - the monitor stays dark, no chance to get it work without reboot of
the FBSD box.

Different story with X11/xdm running. To get an initial screen without further
interaction, the KVM has to be switched to the host about to start. By the way, same
issue with a LibreELEC/KODI driven host utilizing an Intel iGPU.
But other than the issue with FBSD's console, with X11/xdm running and switching the KVM
afterwards towards this DP output the FBSD box / X11 is running on, some could ssh onto
the box and issue some xrandr command to refresh the output. I did this recently, sorry,
I have the notes not at hand. But it is a kind of a labour and sometimes impossible to
connect via ssh/reset DP output.

As mentioned, Linux seems not to have those problems, at least with a RedHat based
product I have to use for work - but that might be a commercial  addition to the X11
server, I do not know, but I realize it works (at least for two of the scenarios I
described).
> 
> I suspect that this problem will require more tinkering (not by myself)
> to better understand it. There are too many variables to say it's a
> single issue.
> 
> Another issue is, X segfaults on occasion on this machine. The segfault
> always occurs when firefox is active. The screen goes blank as
> drm-66-kmod (I think) is corrupted. (This happens maybe once or twice
> a month, not enough to pull me away from other projects.) Are you
> talking about this or the first issue above?

The boxes at home are AM5 based newer systems utilizing recent Ryzen 9XXX CPUs with
internal GPUs, one is using a recent nVidia GTX5XXX discrete GPU. I once used the
drm-66-kmod framework to apply a high resoltution output from my server to the monitor,
but using the console does not require microscopic small output, but I can state that the
issue is quite the same as described before.

I have not found any solution to revive a stuck DP-KVM-DP(Monitor) connection as
described above with X11/xdm using the DRM-66 kmod output for the console (nor with the
official nvidia kmod - speaking of nvidia, I always refer to the BLOB provided by most
recent x11/nvidia-driver, x11/nvidia-kmod).

I hoped for the lack of knowledge on my side when it comes to such issues, especially
when the efi framebuffer for simple consoles is involved, but I realizie the problem
might be bi-lateral one (both sides, hosts's DP and KVM/monitor's DP).

Thank you very much for sharing.

oh