Your message dated Sat, 9 Aug 2014 12:11:36 +0200 with message-id <[email protected]> and subject line Closing has caused the Debian Bug report #714620, regarding acpi-support: Laptop's display won't wake from DPMS off state on lid open event with xrandr method to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 714620: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714620 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: acpi-support Version: 0.140-5 Severity: normal Tags: patch Dear Maintainer, There is a problem with waking from DPMS off state then my laptop's lid is open while using xrandr. Usage scenario: 1. Set "DISPLAY_DPMS=xrandr" and "XRANDR_OUTPUT=LVDS1" options in /etc/default/acpi-support files. 2. Close the lid, Laptop panel go dark. 3. Open the lid and nothing happens, screen remain dark, keyboard and mouse movements does not help. I have discovered that the problem lies in /etc/acpi/lid.sh on line 35: xrandr invoked with hardcoded output 'LVDS', but my Intel KMS driver assign 'LVDS1' name. I suggest to use variable with default value, for example: xrandr --output ${XRANDR_OUTPUT:-LVDS} --auto Same can be applied in /usr/share/acpi-support/screenblank: xrandr --output ${XRANDR_OUTPUT:-LVDS} --off This worked just fine until I have uncommented "LID_SLEEP=true" option. I think that some race condition is happening in such case: then lid was closed, screenblank script invokes xrandr with --off and laptop immediately goes to sleep. It seems display does not have time to actually turn off by xrandr, it was turned off by pm-suspend. And then laptop awake, lid open event occurs and display is enabling by lid.sh. But it is turning off in next moment, that brings me to the original problem described above. I added 'sleep' after xrandr and it works, but it's not clean solution I suppose. Maybe we really don't need to do DPMS off while going to sleep? Here are my patches: --- debian/patches/lid.sh.diff 2013-07-01 11:45:34.000000000 +0300 +++ debian/patches/lid.sh.diff 2013-07-01 13:56:39.298838245 +0300 @@ -57,7 +57,7 @@ + su $XUSER -s /bin/sh -c "xset dpms force on" + ;; + xrandr) -+ su $XUSER -s /bin/sh -c "xrandr --output LVDS --auto" ++ su $XUSER -s /bin/sh -c "xrandr --output ${XRANDR_OUTPUT:-LVDS} --auto" + ;; + vbetool) + /usr/sbin/vbetool dpms on --- debian/patches/screenblank.diff~ 2013-07-01 11:45:34.000000000 +0300 +++ debian/patches/screenblank.diff 2013-07-01 14:20:11.775168681 +0300 @@ -33,31 +33,33 @@ + su $XUSER -s /bin/sh -c "/usr/bin/xlock -mode blank &" + elif [ -x /usr/bin/xtrlock ]; then + su $XUSER -s /bin/sh -c "/usr/bin/xtrlock &" -+ fi ++ fi + fi + -+ case "$DISPLAY_DPMS" in -+ xset) -+ su $XUSER -s /bin/sh -c "xset dpms force off &" -+ ;; -+ xrandr) -+ su $XUSER -s /bin/sh -c "xrandr --output $XRANDR_OUTPUT --off" -+ ;; -+ vbetool) -+ /usr/sbin/vbetool dpms off -+ ;; -+ esac ++ if [ x$LID_SLEEP != xtrue ]; then ++ case "$DISPLAY_DPMS" in ++ xset) ++ su $XUSER -s /bin/sh -c "xset dpms force off &" ++ ;; ++ xrandr) ++ su $XUSER -s /bin/sh -c "xrandr --output ${XRANDR_OUTPUT:-LVDS} --off" ++ ;; ++ vbetool) ++ /usr/sbin/vbetool dpms off ++ ;; ++ esac -xset dpms force off -if [ x$RADEON_LIGHT = xtrue ]; then - [ -x /usr/sbin/radeontool ] && radeontool light off -fi -+ if [ x$RADEON_LIGHT = xtrue ]; then -+ [ -x /usr/sbin/radeontool ] && radeontool light off ++ if [ x$RADEON_LIGHT = xtrue ]; then ++ [ -x /usr/sbin/radeontool ] && radeontool light off ++ fi + fi + else -+ if [ -x$DISPLAY_DPMS_NO_USER = xtrue ]; then ++ if [ x$DISPLAY_DPMS_NO_USER = xtrue -a x$LID_SLEEP != xtrue ]; then + [ -x /usr/sbin/vbetool ] && /usr/sbin/vbetool dpms off -+ fi ++ fi + fi +done -- System Information: Debian Release: wheezy APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---This bug is waiting for more info for more than 6 weeks now. I assume this means you do not see the probem anymore with the latest version of acpi-support installed and therefore close it. If you still see it, feel free to re-open and tell us what happens with the latest version. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--- End Message ---
