9

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
istepaniuk
  • 213
  • 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 03 '19 at 09:53
  • @JohnForkosh thanks, I will try but I have little hope that xrandr will have any effect under Wayland. – istepaniuk Apr 03 '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 04 '19 at 06:21
  • @JohnForkosh it did not reveal anything unexpected. For xrandr, after resume, an XWAYLAND output with the old resolution is still "plugged in". After unplugging and plugging the HDMI back, it correctly shows the new resolution.

    I suspect it's a kernel issue (udev, drm, kms, i915...) or given that swapping monitors while suspended might not be that common, it could even be a BIOS issue. As you suggest, I will keep going down the rabbit hole. I was expecting that this was a common issue.

     – istepaniuk Apr 05 '19 at 11:33
  • 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
  • have you ever figured out how to fix this? I have the same problem: at home 2 dell screens on a thunderbolt dock with 1920x1200, at work 2 samsung screens on a thunderbolt dock with 1920x1080. wayland/gdm does not pick up that the monitors changed and uses the wrong resolution after resuming from suspend. restarting gdm "fixes" it, but then I could as well just shutdown instead of suspend/resume... – alternize Feb 20 '20 at 10:45
  • 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 '20 at 13:11
  • I have not pinpointed the version, but this seems to be solved in Linux 5.5.0. – istepaniuk Aug 07 '20 at 10:52
  • any news on this issue? – Johan May 17 '23 at 10:54
  • @Johan not really on my side. I no longer switch monitors that often. I plan to answer my own question if there is no better authoritative source after I verify that this is indeed solved since 5.5.0. – istepaniuk May 22 '23 at 11:57
  • aight, thanks for heads up. I figured out I experienced the problem regardless of the lid position. I may try to see if USB autosuspend options in tlp fixes it. Looking forward to seeing your post though. – Johan May 22 '23 at 12:10

3 Answers3

2

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.

binarym
  • 2,649
  • 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 09: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 09:27
-1

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.

Community
  • 1
Devidas
  • 507
  • 1
    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 04 '19 at 06: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 04 '19 at 11:18
  • 1
    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 04 '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 04 '19 at 13:16
  • I will enable debug in the drm module (0x100 & 0x04 & 0x1) to see if there is anything about a KMS hotplug event happening or some other clue. – istepaniuk Nov 04 '19 at 13:30
-1

One needs to install laptop-mode-tools and enable video-out module.

If you are using something other than Ubuntu try to find similar tools in your OS.

Refereed from here: 1 & 2

nilsocket
  • 99