ACPI lid events failure (after dist-upgrade, version 0.37)

Bug #22684 reported by Gnurou
6
Affects Status Importance Assigned to Milestone
kdebase (Ubuntu)
Fix Released
Medium
Jonathan Riddell

Bug Description

I'm happily using breezy using the kubuntu preview CD on my DELL X1 laptop. It's
wonderful how many things were working out of the box.

This afternoon, I've decided to dist-upgrade in order to stay in sync with the
latest developments. I've noticed that since the upgrade, the LID ACPI event
failed, while it was working perfectly before. For information, this event is
supposed to shut the screensaver down and perform a "xset dpms force off" when
the lid is closed, and to restore dpms and screensaver when the lid is open.

The logs from /var/log/acpid revealed that I needed to install some more packages:

LID closed:
Tue Sep 27 21:00:07 2005] received event "button/lid LID 00000080 00000003"
[Tue Sep 27 21:00:07 2005] notifying client 5989[112:112]
[Tue Sep 27 21:00:07 2005] executing action "/etc/acpi/lid.sh"
[Tue Sep 27 21:00:07 2005] BEGIN HANDLER MESSAGES
/usr/share/acpi-support/power-funcs: line 7: finger: command not found
xset: unable to open display ""
[Tue Sep 27 21:00:07 2005] END HANDLER MESSAGES
[Tue Sep 27 21:00:07 2005] action exited with status 1
[Tue Sep 27 21:00:07 2005] completed event "button/lid LID 00000080 00000003"
bash: xscreensaver-command: command not found

LID opened:
[Tue Sep 27 21:00:13 2005] received event "video VID 00000080 00000000"
[Tue Sep 27 21:00:13 2005] notifying client 5989[112:112]
[Tue Sep 27 21:00:13 2005] completed event "video VID 00000080 00000000"
[Tue Sep 27 21:00:13 2005] received event "button/lid LID 00000080 00000004"
[Tue Sep 27 21:00:13 2005] notifying client 5989[112:112]
[Tue Sep 27 21:00:13 2005] executing action "/etc/acpi/lid.sh"
[Tue Sep 27 21:00:13 2005] BEGIN HANDLER MESSAGES
/usr/share/acpi-support/power-funcs: line 7: finger: command not found
bash: xscreensaver-command: command not found
bash: xscreensaver-command: command not found
xset: unable to open display ""
[Tue Sep 27 21:00:13 2005] END HANDLER MESSAGES
[Tue Sep 27 21:00:13 2005] action exited with status 1
[Tue Sep 27 21:00:13 2005] completed event "button/lid LID 00000080

So I've installed the finger and xscreensaver packages. After that xset still
refuses to work. It seems that finger is not used correctly to guess which user
is using X in /usr/share/acpi-support/power-funcs. It expects finger to return a
line with the user that logged from KDM, but it doesn't. Setting the user
manually and adding an "export DISPLAY=:0" in /etc/acpi/lid.sh did fix the problem.

So I suspect two problems with the acpi-support package (version 0.37):
* It should include finger and xscreensaver in its dependencies (or at least
check whether xscreensaver is used),
* It seems not to be able to guess the X user, at least if the latest logged in
from KDM.

Anyway, thanks for your great work. I've been able to workaround this, and the
scripts are really well-shaped otherwise.

Revision history for this message
Matthew Garrett (mjg59) wrote :

Should be fixed in the latest upload.

Revision history for this message
Gnurou (gnurou) wrote :

Unfortunately, it seems not to be fixed (version 0.40). Here is what I get in
/var/log/acpid:

LID closed:
[Mon Oct 3 17:16:43 2005] received event "button/lid LID 00000080 00000008"
[Mon Oct 3 17:16:43 2005] notifying client 6526[112:112]
[Mon Oct 3 17:16:43 2005] executing action "/etc/acpi/lid.sh"
[Mon Oct 3 17:16:43 2005] BEGIN HANDLER MESSAGES
xset: unable to open display ""
[Mon Oct 3 17:16:43 2005] END HANDLER MESSAGES
[Mon Oct 3 17:16:43 2005] action exited with status 1
[Mon Oct 3 17:16:43 2005] completed event "button/lid LID 00000080 00000008"
xscreensaver-command: warning: $DISPLAY is not set: defaulting to ":0.0".
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

xscreensaver-command: can't open display :0.0

LID opened:
[Mon Oct 3 17:16:49 2005] received event "video VID 00000080 00000000"
[Mon Oct 3 17:16:49 2005] notifying client 6526[112:112]
[Mon Oct 3 17:16:49 2005] completed event "video VID 00000080 00000000"
[Mon Oct 3 17:16:49 2005] received event "button/lid LID 00000080 00000009"
[Mon Oct 3 17:16:49 2005] notifying client 6526[112:112]
[Mon Oct 3 17:16:49 2005] executing action "/etc/acpi/lid.sh"
[Mon Oct 3 17:16:49 2005] BEGIN HANDLER MESSAGES
[Mon Oct 3 17:16:49 2005] END HANDLER MESSAGES
[Mon Oct 3 17:16:49 2005] action exited with status 1
[Mon Oct 3 17:16:49 2005] completed event "button/lid LID 00000080 00000009"

After opening the LID, I must manually issue a "xset dpms force on" in order to
get my screen back.

Revision history for this message
Gnurou (gnurou) wrote :

Some additional information: finger (used in power-funcs to guess the right
user) seems to be unable to see my user logged in from KDM. Typing 'finger' in a
console just returns "No one logged on."

Revision history for this message
Matthew Garrett (mjg59) wrote :

Ah. If kdm isn't registering you, then it's a bit difficult for us to figure out
what displays are running :)

Revision history for this message
Gnurou (gnurou) wrote :

Indeed. :) The problem probably comes from here. Sorry, I should have seen that
and changed the package myself.

Revision history for this message
Rich Johnson (nixternal) wrote :

Is this bug still present in the latest Dapper packages?

If it is not, or if someone knows that this bug has been fixed by a subsequent upload, please let us know so we can close this. The last activity on this bug was over 8 months ago.

Thank you for reporting this bug.

Revision history for this message
Gnurou (gnurou) wrote :

After my last update, I've noticed that the scripts were indeed working out of the box. Thanks for fixing that bug!

Revision history for this message
Sarah Kowalik (hobbsee-deactivatedaccount) wrote :

marking as fix released, as the reporter says it's fixed.

Changed in kdebase:
status: Unconfirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.