I found this behavior consistnent with kernels 3.6.11, 3.8.0, and 3.8.1 With an external monitor plugged into my Lenovo x220 I can turn the LVDS off with: xrandr --output LVDS1 --off And this works as expected, (LVDS display turns off). But when I try to turn it on again with: xrandr --output LVDS1 --auto nothing comes on. This is in spite of the fact that xrandr does report that the LVDS output is on at this point: $ xrandr | grep -A1 LVDS1 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 277mm x 156mm 1366x768 60.0*+ At this point things appear entirely off, (it does not appear to be a case where just the backlight is off, for example). Note that I can cause the LVDS display to turn on by issuing a modeset, such as: xrandr --output LVDS1 --mode 1024x768 At this point my display turns on again, and then finally I can get the mode I want back with: xrandr --output LVDS1 --auto Please let me know if you need any further information, and I'll be happy to supply it. Thanks, -Carl
(In reply to comment #0) > With an external monitor plugged into my Lenovo x220 I can turn the LVDS > off with: Just to confirm, is the external monitor required to reproduce this? (FWIW I can't reproduce this on an x220T with/without an external monitor.) > Please let me know if you need any further information, and I'll be > happy to supply it. It smells a bit like a kernel issue to me. Please provide a dmesg with drm.debug=0xe module parameter, preferably running the 3.8 kernel, exhibiting the xrandr --off, --auto, --mode, --auto sequence.
In the past this has been true to false tracking of the DPMS state on the connector (and its multiple reincarnations like intel_connector->active).
(In reply to comment #1) > Just to confirm, is the external monitor required to reproduce this? (FWIW I > can't reproduce this on an x220T with/without an external monitor.) I hadn't tested this previously, but apparently yes. I just verified that I could not reproduce the bug without the external monitor, but then immediately after adding the monitor (via DisplayPort) the same commands showed the bug. > It smells a bit like a kernel issue to me. Please provide a dmesg with > drm.debug=0xe module parameter, preferably running the 3.8 kernel, > exhibiting the xrandr --off, --auto, --mode, --auto sequence. I'll follow up with that output shortly. Thanks, -Carl
Created attachment 75758 [details] dmesg log of the 4 operations with drm.debug=0xe as requested Here's the dmesg log as requested. I inserted markers into the log of the form: cworth: xrandr --output LVDS1 --off So that you can grep for "cworth" to find the beginning of each command. Good luck. And again, let me know what else you might need from me. -Carl
Actually doesn't seem to be a kernel bug at all: LVDS --off: no setcrtc to disable the LVDS, just backlight is turned off LVDS --auto: setcrtc is called, but is a no-op LVDS --mode 1024x768: reconfiguration detected, modeset performed userspace *should* be disabling the output rather than turning it off, but the second failure looks like userspace is then assuming that it gets turned back on by auto.
*** Bug 64178 has been marked as a duplicate of this bug. ***
FWIW, I see the same behavior on my x220.
Praise be, Daniel is fixing UXA bugs in the kernel.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.