External monitor not recognised after resuming from suspend

jakob · 2025-01-16 21:55:23

Hey there, it's been a while since my last post

== Hardware specs ==

• Thinkpad X1 Yoga 3rd generation laptop connected to
• Lenovo ThinkPad USB-C Dock 2nd Gen
• Dell monitor connected with an HDMI cable to the dock (however, using a DVI adapter since my monitor is a tad older and doesn't have HDMI yet

In general, everyting works nicely, but when I use suspend (to RAM, invoked by systemd suspend), things get fishy. Suspend itself works fine, but lid open doesn't cause the system to wake up (although I didn't touch wakeup triggers), but I can still get it, as the system also wouldn't suspend from lid close while it is docked, so I have to press power key for ~2 sec to wake up the system.

But what then happens (mostly, but not always), is that my external monitor doesn't show up in xrandr any more, so I can't use it any more and have to use the internal laptop monitor from now on.

I've also tried reconnecting the laptop to the dock: while everything else (mouse, keyboard, printer) is reconnecting fine, the display still wouldn't show up. Doing another susped will not change anything either.

I tried using a different graphics driver (mesa instead of i915), but no change (also seems like a problem deeper down to my understanding).

What else can I try? And where can I have a look? Are there any logs like in dmesg that could help me find the problem?

Thanks for your help!

Jakob

mackin_cheese · 2025-01-16 22:06:17

What research have you done so far regarding this issue?

jakob · 2025-01-16 22:22:59

Hi, thanks for your reply!

Reading throuh and trying to find relevant information in the Arch Wiki, especially
https://wiki.archlinux.org/title/Power_ … _hibernate
https://wiki.archlinux.org/title/Intel_graphics

BBS:
https://bbs.archlinux.org/viewtopic.php?id=294326
https://bbs.archlinux.org/viewtopic.php?id=285079

Reddit:
https://www.reddit.com/r/hyprland/comme … l_monitor/
https://www.reddit.com/r/archlinux/comm … _will_not/

jakob · 2025-01-18 20:10:55

Maybe I was too narrow in my research. Seems plausible it might be a problem with the Lenovo USB-C Dock. Although most of the peope in those forums describe the problem with Windows:

https://forums.lenovo.com/t5/Displays-O … 702?page=1
https://superuser.com/questions/1740337 … 54#1741454
https://forums.developer.nvidia.com/t/e … p/189397/8

However, disconnecting the dock from the laptop (and the dock from power supply) and reconnecting everything while the laptop is on doesn't solve the problem, either.

seth · 2025-01-19 16:37:24

Have you tried to reconnect the output to the dock?
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General *after* losing the output.

jakob · 2025-01-26 17:36:35

seth wrote:

Have you tried to reconnect the output to the dock?
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General *after* losing the output.

Thanks for your message! I forgot to mention that ealier: reconnecting the cable dock/monitor doesn't change anything. I even tried disconnecting it, then disconnecting the USB-C cable from the laptop, switching off the dock, switching it on again and reconnecting the monitor. Still, external monitor not available.

Weirdly, I haven't been able to observe the problematic behaviour in the last few days (it worked as expected for a few suspend sessions), but luckily it happened again, so I'm able to post my Xorg.log. However, there should be at least one or two successful suspends in the log, and only the last one did happen as described in my original post:

Xorg.0.log.old
https://bpa.st/NVHQ

Xorg.0.log
https://bpa.st/LTFA

seth · 2025-01-26 23:48:00

nb. that after reconnecting the dock you'll still have to explicitly enable the output ("good" status is when it shows up in "xrandr -q")

log.old (the server starts only on the internal display, the external monitor shorts up after a 10 minute gap)

[   164.220] (II) intel(0): switch to mode 1680x1050@60.0 on DP1-1 using pipe 1, position (0, 0), rotation normal, reflection none
…
[   741.802] (II) intel(0): resizing framebuffer to 1600x900
[   793.230] (II) event20 - Inateck BR1009 (AVRCP): device removed
[   798.852] (II) config/udev: removing device Inateck BR1009 (AVRCP)
[   798.853] (II) UnloadModule: "libinput"
[   799.097] (II) intel(0): resizing framebuffer to 1920x1200
[   799.103] (II) intel(0): switch to mode 1920x1200@60.0 on DP1-1 using pipe 0, position (0, 0), rotation normal, reflection none

.log (the system boots using the external display, after a 75 minute gap only the internal display is there)

[    38.371] (II) intel(0): resizing framebuffer to 1920x1200
…
[ 22251.093] (II) event9  - Inateck BR1009 (AVRCP): is tagged by udev as: Keyboard
[ 22251.093] (II) event9  - Inateck BR1009 (AVRCP): device is a keyboard
[ 24683.244] (II) event9  - Inateck BR1009 (AVRCP): device removed
[ 24683.271] (II) config/udev: removing device Inateck BR1009 (AVRCP)
[ 24683.276] (II) UnloadModule: "libinput"
[ 24696.890] (II) intel(0): Disabled output DP1-2
[ 24696.890] (II) intel(0): Disabled output DP1-3
…
[ 24742.821] (II) intel(0): resizing framebuffer to 1600x900
[ 24742.829] (II) intel(0): switch to mode 1600x900@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
[ 24759.855] (II) config/udev: Adding input device Inateck BR1009 (AVRCP) (/dev/input/event21)
[ 24759.855] (**) Inateck BR1009 (AVRCP): Applying InputClass "evdev keyboard catchall"
[ 24759.855] (**) Inateck BR1009 (AVRCP): Applying InputClass "libinput keyboard catchall"
[ 24759.855] (**) Inateck BR1009 (AVRCP): Applying InputClass "system-keyboard"
[ 24759.855] (II) Using input driver 'libinput' for 'Inateck BR1009 (AVRCP)'
[ 24759.855] (**) Inateck BR1009 (AVRCP): always reports core events
[ 24759.855] (**) Option "Device" "/dev/input/event21"
[ 24759.856] (II) event21 - Inateck BR1009 (AVRCP): is tagged by udev as: Keyboard
[ 24759.856] (II) event21 - Inateck BR1009 (AVRCP): device is a keyboard
[ 24759.856] (II) event21 - Inateck BR1009 (AVRCP): device removed
[ 24759.887] (**) Option "config_info" "udev:/sys/devices/virtual/input/input39/event21"
[ 24759.887] (II) XINPUT: Adding extended input device "Inateck BR1009 (AVRCP)" (type: KEYBOARD, id 20)

It's a UHD Graphics 620 so the xf86-video-intel driver is about justifiable.

mem_sleep_default=deep

System defaults to s2idle?

[ 163.764] (II) xfree86: Adding drm device (/dev/dri/card1)
[ 163.764] (II) Platform probe for /sys/devices/pci0000:00/0000:00:02.0/drm/card1
[ 163.780] (--) PCI:*(0@0:2:0) 8086:5917:17aa:2259 rev 7, Mem @ 0x2ffe000000/16777216, 0xd0000000/268435456, I/O @ 0x0000e000/64, BIOS @ 0x????????/131072

Wild guess: https://bbs.archlinux.org/viewtopic.php … 1#p2221121

jakob · 2025-01-28 21:11:08

Thanks for your log file analysis and long answer!

seth wrote:

nb. that after reconnecting the dock you'll still have to explicitly enable the output ("good" status is when it shows up in "xrandr -q")

How can I explicitly enable an output other than by reconnecting it physically? The thing I do in order to check whether it's available is issuing the "xrandr" command (which should be equivalent to "xrandr -q").

seth wrote:

.log (the system boots using the external display, after a 75 minute gap only the internal display is there)

[    38.371] (II) intel(0): resizing framebuffer to 1920x1200
…
[ 22251.093] (II) event9  - Inateck BR1009 (AVRCP): is tagged by udev as: Keyboard
[ 22251.093] (II) event9  - Inateck BR1009 (AVRCP): device is a keyboard
[ 24683.244] (II) event9  - Inateck BR1009 (AVRCP): device removed
[ 24683.271] (II) config/udev: removing device Inateck BR1009 (AVRCP)
[ 24683.276] (II) UnloadModule: "libinput"
[ 24696.890] (II) intel(0): Disabled output DP1-2
[ 24696.890] (II) intel(0): Disabled output DP1-3
…

Interesting that the Inateck BR1009 is recognised as keyboard. It's a bluetooth receiver for my speakers…

seth wrote:

It's a UHD Graphics 620 so the xf86-video-intel driver is about justifiable.

"about justifiable" doesn't sound like the best choice?

seth wrote:

mem_sleep_default=deep
System defaults to s2idle?

Weirdly enough, you're right: "cat /sys/power/mem_sleep" outputs "[s2idle] deep" although the kernel line should set deep sleep. I'll have to investigate this.

//edit: "/etc/systemd/sleep.conf.d/mem-deep.conf" had the line “MemorySleepMode=s2idle"…

seth wrote:

Wild guess: https://bbs.archlinux.org/viewtopic.php … 1#p2221121

I'll try putting "initcall_blacklist=simpledrm_platform_driver_init" and "nvidia_drm.modeset=1" (in that order, not simultaneously) in the Kernel line. Thank you so much again!

Last edited by jakob (2025-01-28 21:13:08)

seth · 2025-01-29 08:44:52

1. "xrandr --output FOO-1 --auto" - but if it doesn't show up in "xrandr -q" that's oc. not the problem.

2. many devices (webcams, headphones etc) register up as keyboard devices, eg. to forward little buttons on the device to the OS (ie. they're one-key-keyboards)

3. the performance between the xf86-video-intel and modesetting driver on your system is going to be a coin toss, for newer HW I'd tell you to drio xf86-video-intel, for older to maybe try it.
If this isn't a deliberate choice : try the modesetting driver, but I doubt that it's related to the issue at hand

4. If it's not the simpledrm device, do s2idle and s3 behave differently?
https://wiki.archlinux.org/title/Power_ … end_method

jakob · 2025-01-31 18:55:54

seth wrote:

4. If it's not the simpledrm device, do s2idle and s3 behave differently?
https://wiki.archlinux.org/title/Power_ … end_method

Had a full day yesterday trying to get s3 to work, but the system kept waking up 3 seconds after going into suspend (dmidecode always said "power switch"), but neither journalctl nor dmesg gave conclusive evidence why. I then disabled Windows Fast Startup in the dual boot windows setup (saw that somewhere in another thread in your signater), to no avail. Then I disabled all wakeup triggers in /proc/acpi/wakeup and it still kept happening.

So now I'm back to s2idle. Neither simpledrm nor nvidia cmdline make a difference here, so I'm back to zero. For some reason, the external monitor keeps waking up from suspend slightly more often than before, maybe 50% of the time, so it doesn't feel so bad anymore.

Next try will be modesetting driver.

Last edited by jakob (2025-02-01 08:54:44)

seth · 2025-02-01 12:37:22

I'd not hold my breath for the DDX driver to change anything about the main problem, your best shot is probably to inject the edid to fake the outputs presebce, https://wiki.archlinux.org/title/Kernel … s_and_EDID but that might result in the output showing up, but not receiving any signal.

What's bothersome is that you cannot even detect it with reconnection, otherwise one could just reconnect the USB output.

I assume the dock has an external power supply? Did you try to cycle that?

jakob · 2025-02-03 16:15:10

seth wrote:

I assume the dock has an external power supply? Did you try to cycle that?

Yes, it has its own power supply. What do you mean by “cycling" it? Taking it off the power and putting it back on? With my trials so far, this hasn't made a difference (at least by using the on/off button),
but maybe I'll need to try again pulling the cable and putting it back in…

jakob · 2025-02-03 18:27:22

seth wrote:

I assume the dock has an external power supply? Did you try to cycle that?

Yes, it has its own power supply. What do you mean by “cycling" it? Taking it off the power and putting it back on? With my trials so far, this hasn't made a difference (at least by using the on/off button),
but maybe I'll need to try again …

seth · 2025-02-03 23:57:15

Taking it off the power and putting it back on?

Yes. Reconnecting the hdmi cable should™ initiate a new hadnshake - since that does not seem to happen the likely culprit is the thing inbetween - the dock.
So we're gonna roy it.

Unplug the monitor from the dock, power off the dock, get a coffee, power on the dock, plug the monitor.
Profit?

jakob · 2025-02-10 20:38:15

Hah, that worked! Seems like it wasn't enough to simply power off the dock and power up again but reconnecting the hdmi cable on top of that did it. So that means it's not a Linux problem?

seth · 2025-02-10 20:48:51

It's gonna be between the monitor, the dock, the using a DVI adapter the GPU and the kernel (module)
The hdcp handshake is notoriously and intentionally fragile so you don't steal valuable hollywood content™ and it doesn't help that HDMI wasn't designed for it but it got tacked on last minute.

Your best shot is probably to test another cable/adapter unless there're firmware updates for the dock.

Arch Linux

#1 2025-01-16 21:55:23

External monitor not recognised after resuming from suspend

#2 2025-01-16 22:06:17

Re: External monitor not recognised after resuming from suspend

#3 2025-01-16 22:22:59

Re: External monitor not recognised after resuming from suspend

#4 2025-01-18 20:10:55

Re: External monitor not recognised after resuming from suspend

#5 2025-01-19 16:37:24

Re: External monitor not recognised after resuming from suspend

#6 2025-01-26 17:36:35

Re: External monitor not recognised after resuming from suspend

#7 2025-01-26 23:48:00

Re: External monitor not recognised after resuming from suspend

#8 2025-01-28 21:11:08

Re: External monitor not recognised after resuming from suspend

#9 2025-01-29 08:44:52

Re: External monitor not recognised after resuming from suspend

#10 2025-01-31 18:55:54

Re: External monitor not recognised after resuming from suspend

#11 2025-02-01 12:37:22

Re: External monitor not recognised after resuming from suspend

#12 2025-02-03 16:15:10

Re: External monitor not recognised after resuming from suspend

#13 2025-02-03 18:27:22

Re: External monitor not recognised after resuming from suspend

#14 2025-02-03 23:57:15

Re: External monitor not recognised after resuming from suspend

#15 2025-02-10 20:38:15

Re: External monitor not recognised after resuming from suspend

#16 2025-02-10 20:48:51

Re: External monitor not recognised after resuming from suspend

Board footer