# vt/efifb drops video signal – how to restore?



## Incnis Mrsi (Mar 16, 2021)

Hello.
My “FreeBSD 12.1-RELEASE r354233” box sometimes shuts down its output VGA signal after I disconnect (physically) a monitor from the cable. Everything else works: keyboard, X server, even virtual console switching succeeds (as indicated with `vidcontrol -i active </dev/ttyv1`) and may be logged to Xorg.0.log, just no signal detectable by any monitor. It’s very annoying for me – the box is not purely a server, and some tasks are intended to be controlled via the console.

No remedy short of reboot was able to restore the signal during past occasions. Let bypass at first the problem _when and why_ the things behave in such way. Can anybody suggest _what can I do_ to the video subsystem during this condition?
The system runs vt(4) over efifb, GPU is UHD Graphics 610 (built into Intel® Pentium® Gold G5400; the controller proper reports device id 3E90 not exactly found in id databases), motherboard is Gigabyte H310M (having a DE-15 socket).


----------



## Crivens (Mar 16, 2021)

Maybe xrandr does something of value?


----------



## Snurg (Mar 16, 2021)

ID 3E90 is CoffeeLake Server GT2 according to the freedesktop nomenclature.

I use a HP monitor and what I find interesting is that sometimes the monitor stays dark, stating it doesn't have signal, when I wake up the computer from suspend (sleep) mode about exactly when I turn on the monitor.
The first time this happened I actually thought that the computer would have failed to resume, but in its current configuration I have not yet experienced this.
So I turned off the monitor, and on again a few seconds, and bingo! Now I could see the display.
When this happened again, I knew what to do.

I have no idea what went wrong "behind the curtains", but I guess some monitors don't handle well when the video input starts while they are still initializing.


----------



## Incnis Mrsi (Mar 16, 2021)

Crivens said:


> Maybe xrandr does something of value?


Good call – `xrandr --output default --mode 640x480` and then back to 1280x1024 made the job. Namely _changing_ the mode worked at the end, while “(II) VESA(0): Setting up VESA Mode 0x11B (1280x1024)” showed up (in the log file) on every Ctrl-Alt-F7 to no avail.



Snurg said:


> So I turned off the monitor, and on again a few seconds, and bingo! Now I could see the display.
> When this happened again, I knew what to do.


Of course I turned the monitor on multiple times, if only to check for signal after various switches (see above). I even connected another monitor once. The signal was certainly extinguished (although I didn’t go as far as checking it with voltmeters, electric speakers or an oscilloscope).


----------



## Incnis Mrsi (Aug 6, 2021)

Note: the `xrandr` hack has effect only when the X server is active (that is, respective vt is switched on).


----------

