On a HP ProDesk 400 G3 mini (Linux, dual monitor), HDMI in times starts in low resolution + HDMI and / or DP black out after sleep / moving cables

Question

I have a problem with the HDMI port on a HP ProDesk 400 G3 Desktop Mini Business PC with intel graphics i5 7th gen on Linux when using dual monitor mode, meaning in normal English: I use two screens, one at the HDMI slot and the other one at the DualMode DisplayPort(DP++).

Machine

Details of the model from the link above:

(6.) Dual-state power button

(6.) Dual-Mode DisplayPort™ (DP++)

(8.) Choice of port (DisplayPort™, HDMI, VGA or Serial), in my case, a HDMI port the standard picture is wrong showing a DP instead

(12.) Power connector

List of problems

It can happen that the monitor that uses the HDMI port blacks out:

• after some time in sleep mode (not just shortly after clicking 'Suspend', but some minutes afterwards)
• or after moving the hardware around a bit / moving the cables at the slot, which is about the same as:
• if you plug in and out cables in random variations.
• Usually, the HDMI connected monitor already blacks out as soon as you lift the machine for a moment and move it around a bit. Thus, a change in cables is just the even stronger change but means the same process. You will often not get the blacked out monitor back.

These problems happen mostly with the HDMI port, rarely also with the DP port. From experience, if you further lift and move the machine for a while, you might be lucky to get the two monitors back, but more often you cannot get a blacked out monitor back anymore and you will rather lose even the DP monitor as well.

The monitor ports are programmed to shortly black out if you move their cables, this is normal and just the expected automatic detection, and I guess it happens in around 1 second, perhaps linked to the 100 ms detection time (see patch below). Therefore, the short black out is not the problem, but it seems that if the computer expects the monitor to be "back" earlier than it actually needs to settle, and if the graphics driver comes back before the monitor there, it crashes and remains black (my guess from research below).

I saw an error message at Linux boot time (made a video of the screen at boot time, I did not look into the logs):

ERROR LSPCON mode change timed out

which seems to show that the adapter cannot settle in the given time, quote from the patch paragraph below:

100 ms is not enough time for the LSPCON adapter on Intel NUC devices to settle.

On forced restart, the monitors are both found again, the only problem that sometimes happens directly at start is that:

• one of the two monitors cannot offer a high screen resolution but instead a very low one (1024x768 and 800x600), and this happens only on the HDMI port (at least in the last 20 test cases, anything before is too long ago to be sure).

This latter error would be no problem for now since it is gone after restart, rarely as it happens.

Research on similar bugs and models

Now comes the probably more convincing part of this question, research has brought up quite similar bug descriptions for similar models.

HDMI monitor that is not detected at all

HDMI monitor not detected Ubuntu 20.04.2

Solution there was:

• sudo ubuntu-drivers autoinstall
  

• shutdown
• power on

Taken from: ubuntu 20.04, second monitor on hdmi port not detected

When I run sudo ubuntu-drivers autoinstall, I do not update anything:

No drivers found for installation.

And though I hoped that this still changed something, I ran into the same problems again.

Bug: Displayer cannot wake up from sleeping

[Bug 1916573] Re: displayer cannot wake up from sleeping.

This bug which seems very similar was fixed by replacing DP cable with HDMI cable, thus, it did not use two monitors. Also, I checked different cables often enough (HDMI-adapter to DVI to DVI to HDMI-adapter, HDMI to DVI, HDMI to HDMI, and DP/DisplayPort to HDMI), the main problem seems to be the HDMI port, the DP usually loses less often the screen. After moving around cables or the machine for longer, you usually lose even both monitors. Therefore, it cannot be just an HDMI or DP problem, it is much more likely that the bug is about a too early stopped automatic detection which leads to a crash.

LSPCON patch

The almost same bug can be found at Native screen resolution not working correctly over HDMI LSPCON (i915).

It goes through the debug steps and hands out a patch in the end that is fairly the type that should also solve the problem for the intel graphics on a i5 7th gen.

I likely need somehow a similar patch that works on the model in question. Here is the latest patch for the other model, called [v2] drm/i915: Increase LSPCON timeout. I tried running it with source v2-drm-i915-Increase-LSPCON-timeout.patch but it does not apply to my settings.

I am searching for a solution that solves what is core of that other patch:

100 ms is not enough time for the LSPCON adapter on Intel NUC devices to settle. This causes dropped display modes at boot or screen reconfiguration. Empirical testing can reproduce the error up to a timeout of 190 ms. Basic boot and stress testing at 200 ms has not (yet) failed.

Increase timeout to 400 ms to get some margin of error.

The patch code:

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c b/drivers/gpu/drm/i915/intel_lspcon.c
index 8ae8f42f430a..6b6758419fb3 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -74,7 +74,7 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct intel_lspcon *lspcon,
    DRM_DEBUG_KMS("Waiting for LSPCON mode %s to settle\n",
              lspcon_mode_name(mode));
 
-   wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 100);
+   wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 400);
    if (current_mode != mode)
        DRM_ERROR("LSPCON mode hasn't settled\n");

Switching off sleep mode does not change it

Since the sleep mode seemed to lose the monitor I switched it off using How do I disable my system from going to sleep?:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

But even then, logging in again after longer time, not just a few minutes, you seem to lose the HDMI monitor. Therefore, just logging off seems to be enough to trigger this bug.

Answer 1

You seem to be focusing on a SW solution at the end whereas this SEEMS like a complex HW issue. Are you sure all cables are securely connected, undamaged, & power is grounded. Furthermore a cheap cable COULD cause this. One rogue/bent pin on PC or either monitor video ports could cause this. I'd try to reproduce the issue WITHIN the BIOS/UEFI/built-in-diagnostics which will confirm if its a HW issue. Lack of grounding, cheap, loose, or bad cables/ports could act up with static electricity even see this SU question/answer

Answer 2

UPDATE (helpful)

Trick to avoid losing the monitor most of the time

This should be the last update as it 95% solves the problem.

If you put your machine on a pile of Paper, like a paper block, or a book, and mind that the cables do not touch the ground, it will not get statically loaded from the ground anymore. This is what the accepted answer said from the start. It works. With this, the monitor got lost perhaps once every two weeks after this change, tested it for a month or two. If it happens, see the UPDATE below. But it rarely happens.

UPDATE (helpful)

Workaround to get the monitor back

1. Take out the data cable of the monitor with the problem.
2. Touch the computer case to ground it. You might get a small electric shock, which is good, since that brings the electric voltage below the thresholds of the cable connection again. These electric shocks never happened again after putting the case on a non-static underlay. I used a common 100 pages writing pad, or use anything else like books. This alone leads to much less monitor problems.
3. Power off the system in "Suspend" mode.
4. Wake up from "Suspend" mode.
5. Plug-in the monitor cable.

Repeat until you have the normal monitor back. It can well happen that your monitor stays black or has low resolution in the first tries, then just repeat 1.-5. That should still normally cost less time and nerves than a system restart, which could have the same problems anyway.

The reason why this works is that the computer is statically loaded, as the other answer says. I get a small electric shock each time I touch the computer case when I take out the monitor cable. You can even clearly hear this in the room.

(update: after putting the machine on a pile of paper, as said in the update above this one, I never got an electric shock again).

If you then suspend and restart, it is like a full refresh of that monitor connection. The monitor driver is less distorted and might give that monitor a new chance. It seems to work better than power off+on.

20220712 update It came back after months, perhaps since cables were on the ground, since after putting all cables up (anything, even the monitor power adapter that lay on the ground) after 20m of trying the "Suspend" trick, the "suspend" trick (see above) worked again. I often could not even see both of the monitors anymore. You might then try logging in and pressing Ctrl+Alt+T for a terminal and enter systemctl suspend instead of clicking on "Suspend". If you are not sure whether you have reached the "Suspend" mode, plug in your mobile. Whenever it loads, the computer still runs, and then the "Suspend trick" would not work.

OLD (everything below):

If you keep the monitor black and blinking and just go on working. It may happen that the screen returns. I did not want to restart, and it came back after a day or two, in two of three times in the bad resolution 1024x768 mentioned below.

Workaround as a very first try

The first workaround is to change the monitor blank out time to Never. This should already change a bit, at least in my case, the problem disappeared for a week.

Settings --> Power --> Blank Screen --> Drop down: Never

Yet, after this week, the same problem came up again, even with monitor blank out time to Never.

More promising workaround perhaps

Therefore, the update which worked out up to now.

Add to a new file called ~/.xinitrc:

setterm -blank 0 -powersave off -powerdown 0
xset s off

Taken from:

Linux disable screen blanking i.e. preventing screen going blank

Found by searching the net for "linux never blank screen command line"

Now after weeks of testing with the two workarounds above, it has appeared about just once every week, two times just after the night suspend mode, one time also when I drew the keyboard nearer and its cable touched some power cables (so that the other answer is clearly paving the way to the real reason here). Two times right after a blanking out, I got an electric impulse (one time strong enough that you could hear it) when touching the small desktop (not just the cables). This should be enough to say that this electric impulse is directly linked to the blanking out - which is what the other answer is saying (keep the cables separate) and why I accept it.

Use both answers to get further. It is not nice not to have the blanking out monitors anymore, you always need to put them off when you leave the desk, but it seems to help as well. Anyone with other experiences and ideas welcome.

Emergency plan for each time it happens

Since even with the workaround it happens roughly once a week, here is what you can do to save open files from a black monitor. Taking out the cable only is not enough, then you would have to take it out from the display settings as well which you often might not be able to see. Instead, you can:

• either press Super key (= Windows key) to choose an open window - or use Super+Shift+arror left/right (perhaps also with Alt+Tab before) to switch the open windows to the other screen.

Full fix perhaps not possible

I also got the information that this problem had popped up before when another machine of the same model was still in guarantee time and a service company came and replaced the motherboard.