When the monitor DRM status is "unknown", systemd thinks it's connected.

[julienw]

Because of a kernel issue (see https://bugzilla.kernel.org/show_bug.cgi?id=100741) my monitor DRM status is set to "unknown" instead of "connected"/"disconnected" after a resume.

Because of this, systemd refuses to suspend once more, because it thinks 4 monitors are connected. It works again if I run "xrandr" which sets the status right.

I'm not sure what is the right behavior here, but for sure this prevents my system from suspending. Of course it would be better if the kernel fixed this issue too.

I'm using systemd 215 on Debian stable (8.1), please close if this is fixed in a newer systemd.

[julienw]

output of journalctl -b -u systemd-logind when it fails suspending:

juil. 01 08:12:22 beitou systemd-logind[22720]: Lid closed.
juil. 01 08:12:22 beitou systemd-logind[22720]: Ignoring lid switch request, 4 displays connected.
juil. 01 08:12:22 beitou systemd-logind[22720]: Ignoring lid switch request, 4 displays connected.
juil. 01 08:12:28 beitou systemd-logind[22720]: Lid opened.

output of /sys DRM status when there is the issue:

$ for i in /sys/class/drm/*/*/status ; do echo $i ; done
/sys/class/drm/card0/card0-DP-1/status
/sys/class/drm/card0/card0-eDP-1/status
/sys/class/drm/card0/card0-HDMI-A-1/status
/sys/class/drm/card0/card0-HDMI-A-2/status

$ cat /sys/class/drm/*/*/status
unknown
unknown
unknown
unknown

output of /sys DRM status when there is no issue (after a clean boot or after running xrandr):

$ cat /sys/class/drm/*/*/status
disconnected
connected
disconnected
disconnected

output of xrandr:

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 276mm x 156mm
   1920x1080     60.04*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)

[mbiebl]

Sounds like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788400#92

[mbiebl]

@julienw Lennart reworked this particular code in 602a41c
which is part of v221. If you can test 221-1 from Debian unstable, that would be great.

[dvdhrm]

Btw., this is also a kernel bug. The kernel should properly reload the EDID information etc., so the "unknown" state should always be temporary.

[poettering]

Yes, v221 should handle this properly. This should still be fixed in the kernel though.

(Also, please do not report issues in such old versions of systemd upstream. We only track bugs that are in recent systemd versions upstream).

Anyway, closing, since this should already be fixed with v221.

[julienw]

Thanks, the whole issue and threads were really informative. Hopefully the kernel devs will finally fix this too.

[mbiebl]

@julienw Can you confirm, that v221 actually fixes your issue?

[mbiebl]

btw, if this is also a kernel issue, "someone" should also file this at https://bugzilla.kernel.org/ I guess.
@julienw are you willing to do that?

[julienw]

I couldn't try v221 yet (I want to have some free time so that I can fix potential issues ;) ).

I already filed https://bugzilla.kernel.org/show_bug.cgi?id=100741 that was duped to an "invalid" bug. That "invalid" bug has a link to a thread started by @poettering, but I see no real consequence of the thread. Some people think the kernel should detect again the monitor status after a resume; some other people think userland should trigger the detect (userland should be either systemd/gnome/X ?). I'm not really qualified to decide who's right here, but for sure the status quo is wrong.

Not sure what the right next step is...

[poettering]

Well, see http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584/focus=62733

Daniel Vetter prepared a patch to fix the situation, but I never tested it, because I am too lazy. If you want the bug to be fixed, please consider testing that. The kernel bugzilla bug should really be reopened as long as that issue is not fixed there.

[julienw]

Thanks for the extra pointer, I'll try this patch in the next days.