[RESPONDED] HDMI screen black after wake from hibernation, only on left front port

Framework 11th Gen Core i7-1165G7, running Manjaro. [edit: BIOS GFW30.03.17]

When the HDMI module sits in the front left port, the HDMI external screen remains black after waking from hibernation, or after boot. This happens irregularly (or I didn’t see the secret correlation to … whatever).

Then, mouse can move there, I can move new app windows that appear there (not visibly) with shortcuts to the internal screen.

Display settings allow a max resolution of 1024x768 (it is capable of 1920x1080).
xrandr does not detect any higher resolution either. The gap between screens may be due to the external display’s smaller size while the internal screen remained at its position.

Going to another TTY (alt-F2) displays the command line only on the internal screen. startx after a loging in there resulted in the icons that are usual on the external screen now being shown on the internal, but the task bar is not moved with them. Desktop and Plasma have different ideas of what is active???

Unplug – replug does not help. HDMI remains black.

After a mainboard reset the external screen temporarily allowed up to 1280x1024, but there was no other change.

Tested with different cables, two external monitors, one HDMI module and on all ports. Only the left front port (or the combination of this port with this module) show that behavior.

Because it’s only one port, I doubt the OS is the culprit.

Now the laptop is about a year old and has not been used in the first half of that time. I’d claim a warranty case, but unfortunately I have applied the 11Gen rework*, so that is gone. I can sorta live with the status quo, but it feels so … unsatisfying.

*problem appeared before

Any suggestions what to do?

I get very similar behavior also on manjaro. Randomly happens after sleeping or unplugging the monitor. HDMI screen reports (via xrandr) incorrect non-standard resolutions that vary between restarts. For me it happens in multiple ports. The only way I can get it working again is randomly putting the expansion card in different slots and restarting. Often it takes 5+ iterations of this and I can’t find any sort of pattern for when it decides to work again. Very frustrating. Owned my laptop for over a year and only started happening in the last few months.

It very likely is as it has been reported by others on Manjaro. That said, if you would prefer to stick with Manjaro vs Fedora, we can try to drill this down. To be clear, we vet distros as outlined here - officially supported distros are vetted on a bi-weekly basis to test updates, community distros are tested occasionally to make sure the basics work only.

  • Verify behavior on Fedora 38 (GNOME) live USB. If it happen there as well, please report back what happened.
  • I prefer to avoid using any creative boot parameters here as the Live USB of Fedora will tell us pretty quickly if we have a module issue or if this is a OS/driver related.

TL;DR: Faint hope a kernel update has helped. Fedora showed no problems, but does not hibernate.

Thanks for the readiness to help solving this. The testing with Fedora showed no issue, so you were right re OS causing it. I am reluctant to hop distro, prefer to resolve Manjaro issue.

Tests with Fedora

  • Fedora 38 live (booted from image via ventoy)
  • Fedora 38 install to external usb ssd (clean, except locale, time zone, keyboard)

Several rounds of suspension or reboot with both – no problems re black screen.
However, Fedora has ditched hibernation a while ago and on Manjaro I am relying on it heavily. Hibernation may be a starting point to look deeper into.
@David_Alexander : have you per chance observed if the black screen appeared only after suspension/sleep, hibernation, cold boot, reboot?

Then I read up (and groped in the dark, I am truly out of my depth here) about drivers:

$ inxi -G | grep driver
Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel
Display: x11 server: X.Org v: 21.1.8 with: Xwayland v: 23.1.1 driver: X:

$ inxi -G | grep i915
Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel
loaded: modesetting dri: iris gpu: i915 resolution: 1: 1920x1080

$ inxi -G | grep X
Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel
Display: x11 server: X.Org v: 21.1.8 with: Xwayland v: 23.1.1 driver: X:
API: OpenGL v: 4.6 Mesa 23.0.3 renderer: Mesa Intel Xe Graphics (TGL GT2)

$ lsmod | grep i915
i915                 3211264  109
drm_buddy              20480  1 i915
ttm                    94208  1 i915
drm_display_helper    184320  1 i915
cec                    81920  2 drm_display_helper,i915
intel_gtt              28672  1 i915
video                  65536  1 i915

$ systool -m i915 -av
Module = "i915"

coresize            = "3211264"
initsize            = "0"
initstate           = "live"
refcnt              = "112"
srcversion          = "A72273723CFFA38D973B02D"
taint               = ""
uevent              = <store method only>



$ modinfo i915
modinfo: ERROR: Module i915 not found.
# # # => ???? # # #

$ mhwd
> 0000:00:02.0 (0300:8086:9a49) Display controller Intel Corporation:
NAME               VERSION          FREEDRIVER           TYPE
video-linux            2018.05.04                true            PCI
video-modesetting            2020.01.13                true            PCI
video-vesa            2017.03.12                true            PCI

$ mhwd -li --pci --usb
> Installed PCI configs:
NAME               VERSION          FREEDRIVER           TYPE
video-linux            2018.05.04                true            PCI

Warning: No installed USB configs!

# mhwd-gpu
:: status
warning: could not find '/etc/X11/xorg.conf.d/90-mhwd.conf'!

Kernel parameter look harmless to me (the “ibt=off” can go, I guess):

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash cryptdevice=UUID=:... root=/dev/mapper/luks-... resume=/dev/mapper/luks-... udev.log_priority=3 ibt=off lsm=landlock,lockdown,yama,safesetid,integrity,apparmor,bpf"

Then I updated to the most recent kernel; from 6.1.26 to 6.1.29. No black screen in the short time so far, but it had happened irregularly – it’s too early for a sigh of relief.
Updating to Kernel 6.1.29 did not help.
@David_Alexander : Could you see if your situation improves with this kernel update?

Fedora is best with suspend Fedora and I both do not support hibernate officially. That said, you can dig into the power handling for HDMI coming out of hibernate.

Using suspend, I have seen success (other computers) with usbcore.autosuspend=-1 as a boot parameter, but that is for suspend to ram. I have not explored this using hibernation (to disk). This of course, for HDMI expansion cards or other USB based docks, etc.

I’ll look into autosuspend. Was not on my radar because the black screen appeared irregularly, and the resolutions available were changed.

Another idea, if power is involved: Maybe other usb power sinks lowered voltage too much?

1 Like

Good plan, it’s something I have used from time to time.

Difficult to say, depends on what is connected perhaps.