New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
julienw opened this Issue Jul 1, 2015 · 11 comments

Comments

4 participants
@julienw

julienw commented Jul 1, 2015

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

This comment has been minimized.

julienw commented Jul 1, 2015

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

This comment has been minimized.

Contributor

mbiebl commented Jul 1, 2015

@mbiebl

This comment has been minimized.

Contributor

mbiebl commented Jul 1, 2015

@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.

@mbiebl mbiebl added the login label Jul 1, 2015

@dvdhrm dvdhrm self-assigned this Jul 2, 2015

@dvdhrm

This comment has been minimized.

Member

dvdhrm commented Jul 2, 2015

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

This comment has been minimized.

Member

poettering commented Jul 3, 2015

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.

@poettering poettering closed this Jul 3, 2015

@julienw

This comment has been minimized.

julienw commented Jul 3, 2015

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

@mbiebl

This comment has been minimized.

Contributor

mbiebl commented Jul 3, 2015

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

@mbiebl

This comment has been minimized.

Contributor

mbiebl commented Jul 3, 2015

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

This comment has been minimized.

julienw commented Jul 3, 2015

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

This comment has been minimized.

Member

poettering commented Jul 3, 2015

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

This comment has been minimized.

julienw commented Jul 3, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment