Monitor on HDMI does not detect HDMI signal after disconnect/reconnect

jhg6308 · 12-03-2023, 01:36 PM

I have the following setup:

Zotac CI323 mini-PC---USB/HDMI--> 2-port KVM --> Keyboard/Monitor

The OS is CentOS7 (yes, I know that's ancient; I plan to upgrade to Debian 12 "soon" :-)

The system is running WITHOUT X, i.e. the console is text only.

If I leave the monitor connected to the PC, it remains on indefinitely.

After I switch away to the other box on the KVM, OR power down the monitor without switching away, then later when I switch back or power on the monitor, the monitor does not detect the PC and goes into sleep mode.

It appears the PC has decided the monitor no longer exists and stops providing an HDMI signal.

The keyboard still works, and I can login "blind" and issue commands, but the monitor never detects a signal. I can login via SSH from a different system with no issues; the Zotac is fully operational, the only issue being that it appears to have stopped providing a signal on HDMI.

So far the only solution I've found is to reboot the system.

Some troubleshooting output:

Code:

[jhg@janus ~]$ sudo lshw -c video
  *-display
       description: VGA compatible controller
       product: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       logical name: /dev/fb0
       version: 21
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi vga_controller bus_master cap_list fb
       configuration: depth=32 driver=i915 latency=0 resolution=1920,1080
       resources: irq:123 memory:80000000-80ffffff memory:90000000-9fffffff 

[jhg@janus ~]$ sudo lspci -k -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller (rev 21)
        DeviceName:  Onboard IGD
        Subsystem: ZOTAC International (MCO) Ltd. Device b301
        Kernel driver in use: i915
        Kernel modules: i915
ioport:f000(size=64) memory:c0000-dffff

Also, trying alternate consoles (Alt+Ctrl+F{2,3,4}) caused the system to start agetty on tty{2,3,4} but did not wake up the monitor.

Other things I've tried, with no luck:

- killing the logged in bash process. System relaunches agetty on tty1 but monitor remains off
- killing agetty on tty1; system relaunches agetty (as expected)
- while logged in, echoing text redirected to /dev/tty1, /dev/fb0, /dev/console - no effect

Immediate question: Is there a way to reset the HDMI device without having to reboot?

Other than that, I'd like to understand what's happening. The other device on the KVM is an Intel NUC11 mini-PC, Debian 12, runlevel 3, which does not have this issue.

camorri · 12-03-2023, 04:04 PM

This thread may help. https://askubuntu.com/questions/4056...-from-terminal

The command to use is xrandr. There is an example in the answer on how to turn a monitor on.

Quote:

To re-enable a display that's been turned off, it's usually sufficient to use the --auto e.g. to turn the LVDS1 output device on display :0 back on

xrandr -d :0 --output LVDS1 --auto

Read the description, you need to know the :0 value for the monitor you are trying to enable. :0 is for the first monitor, the second one is probably :1.

Hope this helps.

mrmazda · 12-03-2023, 04:52 PM

Quote:

Originally Posted by camorri

The command to use is xrandr.

Xrandr is an X-related tool, useless in OP's "WITHOUT X" environment.

OP could try appending to his bootloader's linu line consoleblank=0.

jhg6308 · 12-03-2023, 04:57 PM

Quote:

Originally Posted by camorri

This thread may help. https://askubuntu.com/questions/4056...-from-terminal

The command to use is xrandr. [snip]

Hope this helps.

Code:

[jhg@janus ~]$ systemctl get-default
multi-user.target

So, no X and thus no display(s). This is on the system console.

jhg6308 · 12-03-2023, 05:02 PM

Quote:

Originally Posted by mrmazda

Xrandr is an X-related tool, useless in OP's "WITHOUT X" environment.

OP could try appending to his bootloader's linu line consoleblank=0.

Hmm...

Code:

[jhg@janus ~]$ cat /proc/cmdline
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-519.el8.x86_64 root=/dev/mapper/cl-root ro crashkernel=auto resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rhgb quiet

It's not set, but since the display never blanks as long as I don't power down the monitor or switch away on the KVM, it seems to be behaving as if that's the default.

Before I try the consoleblank=0 option, I'd like to find out if there's a way to recover the console without rebooting.

mrmazda · 12-03-2023, 05:15 PM

Quote:

Originally Posted by jhg6308

Before I try the consoleblank=0 option, I'd like to find out if there's a way to recover the console without rebooting.

I think there should be, but nothing comes to mind.

All my non-ancient Grub stanzas (probably at least 600 of them) include nomodeset=0, so I doubt harm is any possibility.

Try switching to a tty which has not on that boot already been logged into, before flipping the KVM switch, so that a getty would remain running on it instead of its login session going to sleep?

Also I wonder if rhgb quiet could have any possible lingering impact to cause this?

RandomTroll · 12-04-2023, 12:20 AM

I have a similar problem. One solution was to run X, which did something to wake up my HDMI display. Then you can quit it.

A better solution is to use a utility to switch screen mode. Perhaps setterm with some argument will work.

Right now my computer boots to a blank screen, blank for the BIOS report, blank until some point in the boot process. I assume that a mode change happens at that point, but I haven't pinpointed what it would be. It starts in an 80x25 mode, what the BIOS wants, switches to a higher column x line, then yet a higher. I assume that if I put the time in I could figure out what did it. Let me know if you do. I use lilo.

jhg6308 · 12-04-2023, 05:14 PM

I think I found something that might help, a packaged named ddccontrol. Unfortunately, the only RPM available for CentOS8 Stream is behind a paywall (is that legal?). Later RPMs from rpmfind are available, but will not install due to dependencies.

The source is available on GitHub, but I haven't been able to track down all of its build dependencies. I think the time needed to do that can be better spent upgrading to a current OS, like Debian 12, to get away from RedHat completely.

jhg6308 · 12-04-2023, 06:25 PM

I gave it one more try, and was able to get ddccontrol built, and then hacked the monitor database enough to get it to issue a DDC query.

The monitor came back to life.

At least now I can cope with the issue and schedule the rebuild for a more opportune time :-)

RandomTroll · 12-04-2023, 10:31 PM

I realized what makes my monitor display: loading the module that puts it into the final mode. In my case that's i915. If I needed to do what you want I'd make a script that unloaded every module that depends on the target module then the target module then reload them. I have such scripts for audio, usb, and network.