5

When my Dell XPS 15 9570 laptop is on, the monitor plugged in the HDMI port is correctly detected. Unplugging the monitor also works as expected.

However, when waking up from suspend by briefly lifting the lid open, the HDMI port is not reconfigured. Whatever was plugged at the time it was suspended is still considered connected after resuming.

That means that the resolution of the previously plugged monitor is kept, causing "not supported resolution" on the new monitor if the monitors expect different resolutions. Re-connecting the new monitor fixes the issue in this case.

I have not figured out exactly how, but leaving the lid open when suspended or after resuming seems to change this behavior.

How can I force the HDMI ports to be scanned again on resume? or otherwise work around this annoying issue.

Some more context:

  • Dual GPU, integrated Intel UHD 630 in use (i915)
  • Discrete nvidia GPU disabled, no proprietary drivers loaded
  • Debian 10 (buster)
  • Linux 4.19.0-2: nouveau.runpm=0 acpi_rev_override=1 acpi_osi=Linux nouveau.modeset=0 scsi_mod.use_blk_mq=1 mem_sleep_default=deep
  • Wayland 1.16, Gnome 3.30
  • /sys/power/mem_sleep: s2idle [deep]

UPDATE

This keeps happening with newer BIOS and Kernel:

  • Debian 11 (bullseye)
  • Linux 5.2.0-3
  • Wayland client 1.17, Gnome 3.30
  • newest Dell XPS BIOS: 1.13.0
  • I don't have any specific idea to solve the problem, but have you tried running xrandr (no args) just to see whether the port's connected/disconnected/or_what, and maybe get some other useful diagnostic info? – John Forkosh Apr 3 '19 at 9:53
  • @JohnForkosh thanks, I will try but I have little hope that xrandr will have any effect under Wayland. – istepaniuk Apr 3 '19 at 13:29
  • Yeah, I agree "little hope", but maybe just a little >0. The point was that I think when/if you find the answer, it'll turn out that the info you gave us wouldn't have been adequate to find (or even guess) that answer. Oh..., so maybe try running dmesg as root right after "lifting the lid". Maybe there'll be some unexpected diagnostic near the end of the file, or something. That's just another shot in the dark, but I think you'll just have to keep shooting until you hit something useful. – John Forkosh Apr 4 '19 at 6:21
  • 1
    I think the best option now is to open a bug report on official linux kernel bugtracker – mattia.b89 Oct 26 '19 at 16:47
  • 1
    @alternize no. I still have the same problem. Like I said in another comment, poking the /sys/class/drm/ stuff re-reads the monitor EDID, but does not generate the proper events the rest of the stack does not know. I have no workaround (other than re-plugging). – istepaniuk Feb 20 at 13:11
0

It looks like some hardware/ACPI/power resume problem.

Linux has always been a bit buggy regarding power suspend. I have a similar problem on my work laptop (both HDMI and internal display remains blank after waking up).

I solved it by manually disabling the external monitor before the power suspend. You can probably script: both systemd and acpid software allow you to install hooks for suspend and resume operation.

What i would do is:

  1. On Suspend: backup the current mode of the external display in a state file somewhere in /var/run (xrandr |grep <the external display>|sed -e <magic here>) may be enought

  2. On Resume: revert the previous mode.

The main difficulties is to setup X authorization to be able to modify the current display from a non-X (aka systemd ou acpid scripts) context.

You could also use that small script i wrote to setup the screen manually with 2 clicks.

| improve this answer | |
  • There is no '/etc/acpi', I guess you mean installing acpid (that would be possible also with the systemd hooks) but even then, how do you force the re-detection? What would this script execute? – istepaniuk Oct 21 '19 at 9:49
  • Yes, i edited my answer. There's no "easy" way to manage this if it's really a hardware bug... but you can probably hack some stuff to make this work better. – binarym Oct 21 '19 at 13:41
  • xrandr (through XWAYLAND) is unaware of the monitor changes, it does already keep the old mode so there is no need to restore it. The new monitor might have a bigger or just different native resolution so an EDID res-scan is necessary, the mode cannot be guessed. A script would work if there was a drm/kms command line tool or /sys entry to tell the kernel to re-scan the connected monitors, which I am unaware off. – istepaniuk Oct 21 '19 at 14:37
  • Then maybe using the disable/enable workaround with --auto for the external output may solve your issue. Anyway, how would Linux detect a change that occurs while it was in suspend mode ? – binarym Oct 21 '19 at 15:06
  • That seems like a good idea. However, xrandr depends on what wayland says, and wayland says there is something (incorrect) connected to the emulated XWAYLANDXX output. xrandr --auto fails with xrandr: Configure crtc 0 failed. – istepaniuk Oct 28 '19 at 9:27
0

I have two step workaround solution.

step 1:

use aptitude install arandr this is front-end for xrandr written in python. using GUI select appropriate config.

save this configuration using file-> save.

it will save it as bash script. bind some key combo for this. or run manually.

step 2:

  1. install acpid
  2. systemctl enable acpid.service enable on boot acpid
  3. systemctl start acpid.service start acpid now
  4. use acpi_listen to listen acpi events

add a script in /etc/acpi/handler.sh

or

add a script under /etc/acpi/events

from here call your script based on lid open and lid close event.

need for this work around is because these events are not handled as they are supposed to in debian.

parallel to this you can log a bug in debian for this.

hope this solves your problem temporary.

I am using this workaround for dock connection and disconnection not being handled properly.

| improve this answer | |
  • Like I stated in other comments, applying a saved configuration does not solve the problem, it actually makes it worse. What needs to happen on those "hooks" is re-detection. Xrandr can happily apply any configuration, but I have no way to tell, at resume time, what is connected as Xrandr connector state is stale. – istepaniuk Oct 27 '19 at 14:32
  • yeah I totally get your point, I mentioned this looks like a bug. to scan display port can be done by parsing xrandr i.e. xrandr | grep " connected" | awk '{print $1}' will give you all connected display list. may be using this you can decide what to be done. I hope this is what you meant when you said re-scanning. – Devidas Nov 4 '19 at 6:24
  • xrandr | grep " connected" returns an incorrect list of plugged monitors. By re-scaning I mean really forcing the KMS driver to probe/query the hardware for connected ports. Xrandr state is stale, probably because it just exposes state from the 45 lasagna layers between it and the video adapter. I now know that restarting gdm solves the issue, so this seems to rule out a pure hardware/firmware/BIOS bug. – istepaniuk Nov 4 '19 at 11:18
  • can you clarify what do you mean I now know that restarting gdm solves the issue ? maybe this can help rescanning for i in `ls /sys/class/drm/*/status`; do echo detect > $i; done can you confirm if this refreshes device list or not ? – Devidas Nov 4 '19 at 12:47
  • You are onto something! While stale, the EDID information on /sys/class/drm/card-0-DP-3/edid is also stale. Writing detect to status updates the EDID information, so that is a step in the right direction. This, however, does not seem to produce the correct event so the rest of the stack seems unaware of the new information. Even the previously connected/stale monitor name shows in gnome-control-center. Regarding gdm: a brutal gdm restart has the same effect as unplugging+plugging back the monitor that was connected while suspended. Everything gets updated. – istepaniuk Nov 4 '19 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.