strange/buggy behavior of x.org on multi-monitor setup

olocin · 2019-05-02 02:10:11

I'm using xplugd to detect laptop docking or undocking, in combination with dwm.

If I start from laptop docked, then suspend, undock, recover from suspend, it will correctly change screens.
After this, if I suspend one more time (remaining undocked), then recover from suspend: the screen is not turned on.
(If I change TTY from 1->2 then back 2->1, while staying undocked, the screen starts to work back to normal.)
The issue does not happen the other way around: if start from undocked, then dock, I can suspend as many times as I want. Similarly, if I start X/dwm from undocked, then I can suspend as many times as I want, while staying undocked.

xplugd is launched from .xinitrc and my .xplugrc is

#!/bin/sh

type=$1
device=$2
status=$3
laptop=eDP-1
monitor=DP-2-1

case "$type,$device,$status" in
	display,$monitor,connected)
		xrandr --output $monitor --auto --dpi 163 --output $laptop --off
		nmcli r wifi off
		feh --bg-max ~/Pictures/bkground/*
		;;
	display,$monitor,disconnected)
                xrandr --output $monitor --off --output $laptop --auto --dpi 216
		xinput set-prop 14 305 1
		nmcli r wifi on
		feh --bg-max ~/Pictures/bkground/*
		;;
esac

I do not see any error either in the journal or X.log, so where should I start to debug this?

seth · 2019-05-02 07:00:44

For clarification: this is actually only about the internal display not getting up on subsequent S3 resumes when the laptop was booted on the dock (on the wall plug rather than battery?) but then undocked. Also the display then still comes up reliably on virtual terminal changes?

Take xplugd out of the equation: boot docked, undock, run the relevant disconnect commands by hand, suspend/resume/repeat. At best try w/o even X11 (ie. whether the output activates in a strict console context)
If you can, try to eleminate the dock as well (and use a plain AC adapter)

Is there an external VGA involved? What is the internal one (intel/nvidia/…)?

olocin · 2019-05-02 14:38:42

That's right, it's only the internal display.
Display comes up reliably on VT changes.
It's a thinkpad t460s, with internal graphics only, so I believe intel.
I will try narrowing down the issue as you suggest and report, thanks.

olocin · 2019-05-03 15:43:35

Some experiments:
1. Purely from tty2, the full docking/undocking/suspend works, with

 kernel: [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22

2. xplugd can be excluded, as docking and turning on/off manually with xrandr still has the issue
3. if I just connect the laptop to display using DP cable, no issue; just this error

 kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training

4. notice that (i) when I switch to tty2 and then back to tty1, the output now appears (like I said), but tty2 is also black, and (ii) if after unplugging/suspending/recovering I log out and back in, no issue as well.

olocin · 2019-05-03 15:55:18

Btw, this is an embarrassing/unrelated question, but what is the right way of doing?

monitor=DP-2-1
if $(xrandr | grep -q 'DP-2-1 connected'); then

is it?

monitor=DP-2-1
if $(xrandr | grep -q ' "$monitor" connected'); then

seth · 2019-05-03 16:34:01

kernel: [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22

https://bbs.archlinux.org/viewtopic.php?id=236212

if $(xrandr | grep -q "$monitor connected"); then

Vars are expanded inside double quotes, but not inside single quotes - everything inside single quotes is a string.

You can also "xrandr --listmonitors"

xrandr --listmonitors | grep -q DP-2-1 && …

olocin · 2019-05-03 16:51:57

Thanks.
When I have no screen, I can unlock and issue xrandr >> file.log, which I can read later, and which contains only eDP-1, connected and starred, as expected.
At the same time, if I switch to any tty other than 1, the screen is black, and it comes back only when I switch back to tty1, with no errors.

olocin · 2019-05-03 20:46:12

The same issue arises if I first undock, then suspend: this time already the first time after recovering from suspend, screen is black.
Other data point: when the issue arises, none of the tty's works, and changing back to tty1 only recovers tty1, other tty's stay broken, until I login out and back in.

olocin · 2019-05-03 21:06:47

Somehow, it seems the lenovo ultra dock is responsible, as if I repeat using the same ac power cord and dp plugged directly into the laptop, nothing happens.
In particular, the combination dock+dp.
(If I just dock without any monitor connected to the dock, the issue does not arise.)

Last edited by olocin (2019-05-03 21:27:04)

olocin · 2019-05-06 21:33:10

I missed this before,

seth wrote:

https://bbs.archlinux.org/viewtopic.php?id=236212

in post #4 they describe the same issue as mine, with the same workaround that I found of switching vt's back and forth.
So indeed it seems an issue of i915 and docking.

Arch Linux

#1 2019-05-02 02:10:11

strange/buggy behavior of x.org on multi-monitor setup

#2 2019-05-02 07:00:44

Re: strange/buggy behavior of x.org on multi-monitor setup

#3 2019-05-02 14:38:42

Re: strange/buggy behavior of x.org on multi-monitor setup

#4 2019-05-03 15:43:35

Re: strange/buggy behavior of x.org on multi-monitor setup

#5 2019-05-03 15:55:18

Re: strange/buggy behavior of x.org on multi-monitor setup

#6 2019-05-03 16:34:01

Re: strange/buggy behavior of x.org on multi-monitor setup

#7 2019-05-03 16:51:57

Re: strange/buggy behavior of x.org on multi-monitor setup

#8 2019-05-03 20:46:12

Re: strange/buggy behavior of x.org on multi-monitor setup

#9 2019-05-03 21:06:47

Re: strange/buggy behavior of x.org on multi-monitor setup

#10 2019-05-06 21:33:10

Re: strange/buggy behavior of x.org on multi-monitor setup

Board footer