Debian Bug report logs - #467374
acpi-support: acpi_fakekey does not reach sleep.sh

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: db001@sanevision.com

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: acpi-support: acpi_fakekey does not reach sleep.sh

Date: Mon, 25 Feb 2008 02:10:52 +0200

Package: acpi-support
Version: 0.103-5
Severity: normal

I believe I could kludge this locally, but since I've wasted a whole
day trying to figure out what might be at fault, let me enter a bug.

I use my own kernels, not Debian's. With 2.6.22.5 my "Sleep" button on
ThinkPad T60 worked fine (Fn-F4). Stopped working with 2.6.23.x, still
didn't work with 2.6.24.2. Nothing in the kernel configs seemed to be
at fault, even borrowing the old config for the new kernel didn't help.

Running suspend-to-ram manually (s2ram, /etc/acpi/sleep.sh,
pm-suspend, etc.) works fine, though. Thus, only the link from the
button to the action is broken.

I do see that unless I have pressed this button too recently, the
following ACPI event gets generated:

[Mon Feb 25 01:36:57 2008] received event "ibm/hotkey HKEY 00000080 00001004"
[Mon Feb 25 01:36:57 2008] notifying client 3685[105:108]
[Mon Feb 25 01:36:57 2008] notifying client 3811[0:0]
[Mon Feb 25 01:36:57 2008] executing action "/etc/acpi/sleepbtn.sh"
[Mon Feb 25 01:36:57 2008] BEGIN HANDLER MESSAGES
[Mon Feb 25 01:36:57 2008] END HANDLER MESSAGES
[Mon Feb 25 01:36:57 2008] action exited with status 0
[Mon Feb 25 01:36:57 2008] completed event "ibm/hotkey HKEY 00000080 00001004"

So far it's alright. So we're running the /etc/acpi/sleepbtn.sh 
script, when a lot of people on the net seem to be wishing to run 
/etc/acpi/sleep.sh at this point. We're even generating a key-press, 
passing it onto the xserver:

KeyPress event, serial 32, synthetic NO, window 0x2200001,
    root 0x67, subw 0x0, time 1305715904, (168,-8), root:(172,566),
    state 0x0, keycode 223 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x2200001,
    root 0x67, subw 0x0, time 1305715904, (168,-8), root:(172,566),
    state 0x0, keycode 223 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

(I don't see how we get keycode 223 from KEY_SLEEP=142 but that's OK.)

Anyway, this is how far I can track it. Next, I believe this key press
just gets dropped. I think this keypress should have led us to
/etc/acpi/sleep.sh somehow, or perhaps it should not have been
generated in the first place. I can't find anything in the docs that
says that I have to hack the /etc/acpi/*.sh scripts, though, only
some reports on the net that that's what people have done. I believe
it would be nicer if it worked "out of the box", hence the bug report.

Would it work out of the box with a different xorg.conf?
This is the relevant section from mine:
Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc104"
        Option          "XkbLayout"     "lv"
        Option          "XkbOptions"    "ctrl:nocaps,altwin:left_meta_win,compos
e:menu"
EndSection

A different keyboard model, perhaps, or a variant? Unfortunately all
the X keyboard model, variant, layout, symbol, etc. information that
used to live in /etc/X11, seems to have evaporated somewhere; all I
have now is one fairly unreadable /etc/X11/xkb/base.xml file. Thus,
I don't even know whether there is a chance to map the keycode 223
to something more meaningful or not. Nor do I know whether mere
mapping would help.

Very interested in answers.






-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages acpi-support depends on:
ii  acpi-support-base             0.103-5    scripts for handling base ACPI eve
ii  acpid                         1.0.4-7.1  Utilities for using ACPI power man
ii  dmidecode                     2.9-1      Dump Desktop Management Interface 
ii  finger                        0.17-11    user information lookup program
ii  hdparm                        7.7-1      tune hard disk parameters for high
ii  laptop-detect                 0.13.5     attempt to detect a laptop
ii  libc6                         2.7-6      GNU C Library: Shared libraries
ii  lsb-base                      3.1-24     Linux Standard Base 3.1 init scrip
ii  nvclock                       0.8b3-1    Allows you to overclock your nVidi
ii  powermgmt-base                1.29       Common utils and configs for power
ii  radeontool                    1.5-5      utility to control ATI Radeon back
ii  vbetool                       1.0-1.1    run real-mode video BIOS code to a
ii  x11-xserver-utils             7.3+2      X server utilities

acpi-support recommends no packages.

-- no debconf information

Message #10 received at 467374@bugs.debian.org (full text, mbox, reply):

From: Bart Samwel <bart@samwel.tk>

To: db001@sanevision.com, 467374@bugs.debian.org

Subject: Re: Bug#467374: acpi-support: acpi_fakekey does not reach sleep.sh

Date: Mon, 25 Feb 2008 09:51:50 +0100

db001@sanevision.com wrote:
> Package: acpi-support
> Version: 0.103-5
> Severity: normal
> 
> I believe I could kludge this locally, but since I've wasted a whole
> day trying to figure out what might be at fault, let me enter a bug.
> 
> I use my own kernels, not Debian's. With 2.6.22.5 my "Sleep" button on
> ThinkPad T60 worked fine (Fn-F4). Stopped working with 2.6.23.x, still
> didn't work with 2.6.24.2. Nothing in the kernel configs seemed to be
> at fault, even borrowing the old config for the new kernel didn't help.
> 
> Running suspend-to-ram manually (s2ram, /etc/acpi/sleep.sh,
> pm-suspend, etc.) works fine, though. Thus, only the link from the
> button to the action is broken.
> 
> I do see that unless I have pressed this button too recently, the
> following ACPI event gets generated:
> 
> [Mon Feb 25 01:36:57 2008] received event "ibm/hotkey HKEY 00000080 00001004"
> [Mon Feb 25 01:36:57 2008] notifying client 3685[105:108]
> [Mon Feb 25 01:36:57 2008] notifying client 3811[0:0]
> [Mon Feb 25 01:36:57 2008] executing action "/etc/acpi/sleepbtn.sh"
> [Mon Feb 25 01:36:57 2008] BEGIN HANDLER MESSAGES
> [Mon Feb 25 01:36:57 2008] END HANDLER MESSAGES
> [Mon Feb 25 01:36:57 2008] action exited with status 0
> [Mon Feb 25 01:36:57 2008] completed event "ibm/hotkey HKEY 00000080 00001004"
> 
> So far it's alright. So we're running the /etc/acpi/sleepbtn.sh 
> script, when a lot of people on the net seem to be wishing to run 
> /etc/acpi/sleep.sh at this point. We're even generating a key-press, 
> passing it onto the xserver:
> 
> KeyPress event, serial 32, synthetic NO, window 0x2200001,
>     root 0x67, subw 0x0, time 1305715904, (168,-8), root:(172,566),
>     state 0x0, keycode 223 (keysym 0x0, NoSymbol), same_screen YES,
>     XLookupString gives 0 bytes: 
>     XmbLookupString gives 0 bytes: 
>     XFilterEvent returns: False
> 
> KeyRelease event, serial 32, synthetic NO, window 0x2200001,
>     root 0x67, subw 0x0, time 1305715904, (168,-8), root:(172,566),
>     state 0x0, keycode 223 (keysym 0x0, NoSymbol), same_screen YES,
>     XLookupString gives 0 bytes: 
>     XFilterEvent returns: False
> 
> (I don't see how we get keycode 223 from KEY_SLEEP=142 but that's OK.)
> 
> Anyway, this is how far I can track it. Next, I believe this key press
> just gets dropped. I think this keypress should have led us to
> /etc/acpi/sleep.sh somehow, or perhaps it should not have been
> generated in the first place. I can't find anything in the docs that
> says that I have to hack the /etc/acpi/*.sh scripts, though, only
> some reports on the net that that's what people have done. I believe
> it would be nicer if it worked "out of the box", hence the bug report.
> 
> Would it work out of the box with a different xorg.conf?
> This is the relevant section from mine:
> Section "InputDevice"
>         Identifier      "Generic Keyboard"
>         Driver          "kbd"
>         Option          "CoreKeyboard"
>         Option          "XkbRules"      "xorg"
>         Option          "XkbModel"      "pc104"
>         Option          "XkbLayout"     "lv"
>         Option          "XkbOptions"    "ctrl:nocaps,altwin:left_meta_win,compos
> e:menu"
> EndSection
> 
> A different keyboard model, perhaps, or a variant? Unfortunately all
> the X keyboard model, variant, layout, symbol, etc. information that
> used to live in /etc/X11, seems to have evaporated somewhere; all I
> have now is one fairly unreadable /etc/X11/xkb/base.xml file. Thus,
> I don't even know whether there is a chance to map the keycode 223
> to something more meaningful or not. Nor do I know whether mere
> mapping would help.
> 
> Very interested in answers.

OK, here's a question instead: are you running something like 
gnome-power-manager or kpowersaved? I could check in detail later (I'm 
not behind my own computer right now), but IIRC acpi-support lets these 
tools handle suspending if they're running. And (again IIRC) it does 
that by sending the proper key on to X, which should then be handled by 
these tools. So, are you running any of these tools? Does it start 
working again if you log out of X and press the sleep button from the 
command line?

Cheers,
Bart

Message #15 received at 467374@bugs.debian.org (full text, mbox, reply):

From: "Martins Krikis" <db001@sanevision.com>

To: "Bart Samwel" <bart@samwel.tk>

Cc: 467374@bugs.debian.org

Subject: Re: Bug#467374: acpi-support: acpi_fakekey does not reach sleep.sh

Date: Mon, 25 Feb 2008 12:33:32 +0200

Hmm. Some good points there.

No, I wasn't running any of those, in fact kpowersave (which turns out to be
a tray applet) wasn't even installed and Gnome still isn't. When logging out
of X and pressing the button while logged on the VT, nothing happened.

Then I logged back on to X, installed this kpowersave and launched.
I already had some other KDE battery monitor tray applet running,
so this was now a second one. But it did indeed start handling the
keypress generated by acpi_fakekey. So the laptop suspends again.
(It's a pity the battery charge amount that this applet shows and the
number of batteries installed seems to mismatch reality but that's a
different bug and story.)

So is Debian's acpi-support design for suspend-to-ram such that it _only_
works in X and only if the user has installed some particular
utilities to grab the
generated fakekey? Now I'm really getting interested in how could it have worked
with the 2.6.22.5 kernel. And what is the purpose of
/etc/acpi/sleep.sh, since it
didn't seem to get involved in the suspend-to-ram orchestrated by kpowersave.

Thanks,

  Martins

Message #20 received at 467374@bugs.debian.org (full text, mbox, reply):

From: Bart Samwel <bart@samwel.tk>

To: Martins Krikis <db001@sanevision.com>

Cc: 467374@bugs.debian.org

Subject: Re: Bug#467374: acpi-support: acpi_fakekey does not reach sleep.sh

Date: Mon, 25 Feb 2008 11:35:46 +0100

Martins Krikis wrote:
> Hmm. Some good points there.
> 
> No, I wasn't running any of those, in fact kpowersave (which turns out to be
> a tray applet) wasn't even installed and Gnome still isn't. When logging out
> of X and pressing the button while logged on the VT, nothing happened.
> 
> Then I logged back on to X, installed this kpowersave and launched.
> I already had some other KDE battery monitor tray applet running,
> so this was now a second one. But it did indeed start handling the
> keypress generated by acpi_fakekey. So the laptop suspends again.
> (It's a pity the battery charge amount that this applet shows and the
> number of batteries installed seems to mismatch reality but that's a
> different bug and story.)
> 
> So is Debian's acpi-support design for suspend-to-ram such that it _only_
> works in X and only if the user has installed some particular
> utilities to grab the
> generated fakekey? Now I'm really getting interested in how could it have worked
> with the 2.6.22.5 kernel. And what is the purpose of
> /etc/acpi/sleep.sh, since it
> didn't seem to get involved in the suspend-to-ram orchestrated by kpowersave.

The role is to handle the key if nobody else does. Apparently this goes 
wrong in newer kernels. I've heard some things about a recent rewiring 
of certain event chains, we'll simply have to figure out how the wiring 
currently works. Once I get to my own computer I'll try to figure it out!

Cheers,
Bart

Message #25 received at 467374@bugs.debian.org (full text, mbox, reply):

From: "Bart Samwel" <bart@samwel.tk>

To: "Martins Krikis" <db001@sanevision.com>

Cc: 467374@bugs.debian.org

Subject: Re: Bug#467374: acpi-support: acpi_fakekey does not reach sleep.sh

Date: Sun, 9 Mar 2008 20:36:21 +0100 (CET)

On Mon, February 25, 2008 11:35, Bart Samwel wrote:
> Martins Krikis wrote:
>> Hmm. Some good points there.
>>
>> No, I wasn't running any of those, in fact kpowersave (which turns out
>> to be
>> a tray applet) wasn't even installed and Gnome still isn't. When logging
>> out
>> of X and pressing the button while logged on the VT, nothing happened.
>>
>> Then I logged back on to X, installed this kpowersave and launched.
>> I already had some other KDE battery monitor tray applet running,
>> so this was now a second one. But it did indeed start handling the
>> keypress generated by acpi_fakekey. So the laptop suspends again.
>> (It's a pity the battery charge amount that this applet shows and the
>> number of batteries installed seems to mismatch reality but that's a
>> different bug and story.)
>>
>> So is Debian's acpi-support design for suspend-to-ram such that it
>> _only_
>> works in X and only if the user has installed some particular
>> utilities to grab the
>> generated fakekey? Now I'm really getting interested in how could it
>> have worked
>> with the 2.6.22.5 kernel. And what is the purpose of
>> /etc/acpi/sleep.sh, since it
>> didn't seem to get involved in the suspend-to-ram orchestrated by
>> kpowersave.
>
> The role is to handle the key if nobody else does. Apparently this goes
> wrong in newer kernels. I've heard some things about a recent rewiring
> of certain event chains, we'll simply have to figure out how the wiring
> currently works. Once I get to my own computer I'll try to figure it out!

OK, that took a bit longer than expected. I've checked it out. The
sleep.sh script is called when the ACPI sleep button is pushed, i.e., we
get a "button/sleep" event. Many laptops have such an ACPI button, and for
those laptops, acpi-support's sleep.sh handles the key only if
klaptopdaemon or gnome-power-manager are not running, otherwise it leaves
the work to those daemons. Apparently this type of laptop doesn't have an
ACPI sleep button, so we'll have to do something else. I'll do the
following, which I hope will fix it:

- We check if klaptopdaemon or gnome-power-manager are running.
- If so, we generate the keypress with acpi_fakekey, which will be picked
up by the power daemons.
- If not, we call sleep.sh.

You can expect this fix in the next upload. If it doesn't turn out to work
without klaptopdaemon installed, please reopen the bug after that.

Cheers,
Bart

Message #34 received at 467374@bugs.debian.org (full text, mbox, reply):

From: Chris Burkhardt <chris@mretc.net>

To: 467374@bugs.debian.org

Subject: Re: Bug#467374: acpi-support: acpi_fakekey does not reach sleep.sh

Date: Thu, 20 Mar 2008 15:33:59 -0600

Hello Bart and all. I know you have a solution pending which will fix 
this, but I wanted to add some additional information for frustrated 
users like myself who find this bug report from google.

> The sleep.sh script is called when the ACPI sleep button is pushed, 
> i.e., we
> get a "button/sleep" event. Many laptops have such an ACPI button, and 
> for
> those laptops, acpi-support's sleep.sh handles the key only if
> klaptopdaemon or gnome-power-manager are not running, otherwise it 
> leaves
> the work to those daemons. Apparently this type of laptop doesn't have 
> an
> ACPI sleep button, so we'll have to do something else.

Actually, ThinkPads, with the normal 'button' kernel module, DO have an 
ACPI sleep button (fn-f4) which generates a "button/sleep" event (on 
the T60 and X60, at least, it is "button/sleep SLPB 00000080 
00000001"). The confusion happens because the ibm-acpi (which is called 
thinkpad-acpi in kernels after 2.6.18) kernel module, can override that 
with it's own ACPI event ("ibm/hotkey HKEY 00000080 00001004").

The ibm-acpi/thinkpad-acpi module doesn't always override the 
"button/sleep" event, however. It is possible, at least on some 
machines with some versions of ibm-acpi/thinkpad-acpi to mask some keys 
so that it does not generate it's own events for them. The 
documentation for determining which mask to set to exclude which keys 
is not clear. On my version of ibm-acpi (kernel 2.6.18) it is not 
possible to mask out the fn-f4 key. It should be possible on later 
versions (thinkpad-acpi). Searching the thinkpad-acpi mailing list 
archives turns up some useful information.

I suspect the reason db001@sanevision.com had success with some kernel 
versions and not with others is that the default thinkpad-acpi mask for 
the kernels that worked excluded fn-f4 so the normal "button/sleep" 
event was generated instead of thinkpad-acpi's "HKEY ..." event.

acpi-support includes scripts to handle both events: the standard 
"button/sleep" event and ibm-acpi/thinkpad-acpi's "ibm/hotkey ..." 
event:

/etc/acpi/events/sleepbtn - handle's "button/sleep" and calls 'sleep.sh'
/etc/acpi/events/ibm-sleepbtn - handle's "ibm/hotkey ..." and calls 
'sleepbtn.sh' which generates a key press with acpi_fakekey

That's what had me confused. Why does one call sleep.sh and work as 
expected, while the other just generates a key press that does nothing? 
They can both be triggered by fn-f4 (depending on if/how ibm-acpi is 
enabled) and should both do the same thing. The reason is that acpid is 
not the only thing listening to acpi events. Daemons like 
HAL/gnome-power-manager also act on "button/sleep" events. That's why 
'sleepbtn.sh' simulates the key press, so gnome-power-manager et al can 
pickup on the event even though it was not the standard "button/sleep" 
event.

So, with ibm-acpi/thinkpad-acpi not loaded (or loaded with a mask which 
excludes the sleep button), ThinkPads will generate the "button/sleep" 
event that is matched by 'sleepbtn' which calls 'sleep.sh' which puts 
the computer to sleep as expected. All good.

With ibm-acpi/thinkpad-acpi loaded with a mask that overrides fn-f4, 
and with something like gnome-power-manager running, then ThinkPads 
will generate the "ibm/hotkey HKEY ..." event that is matched by 
'ibm-sleepbtn' which calls acpi fakekey which generates an input key 
event that is picked up by the power management daemon which puts the 
computer to sleep as expected. All good here too.

However, with ibm-acpi/think-acpi loaded and with a mask to catch the 
fn-f4 key, but without a power-management daemon, there is nothing to 
act on the key press simulated by 'sleepbtn.sh' (with acpi_fakekey) so 
nothing happens. That's the bug here.

> - We check if klaptopdaemon or gnome-power-manager are running.
> - If so, we generate the keypress with acpi_fakekey, which will be 
> picked
> up by the power daemons.
> - If not, we call sleep.sh.

You mean do all of that in /etc/acpi/sleepbtn.sh? That sounds like a 
good solution.

> You can expect this fix in the next upload.

Cool. Can you explain to me which release that will get uploaded to? 
I'm brand new to Debian, but it seems like Stable (etch) doesn't change 
much at all, so I assume any uploads will only be available on the 
Testing (lenny) repositories. Is that right? If so, what is the correct 
thing for us etch users to do? Just fix it however we see fit locally?

For now I've fixed it on my machine by modifying events/ibm-sleepbtn to 
call sleep.sh directly (which works because I don't use 
gnome-power-manager or friends).

As a curious aside, on my X60t (2.6.18-6-686), with ibm-acpi loaded 
with nothing masked out (echo 0xFFFFFFFF > /proc/acpi/ibm/hotkey), when 
I close the laptop, acpid receives events from both the button module 
("button/lid LID 00000080 00000001") AND ibm-acpi ("ibm/hotkey HKEY 
00000080 00005001"). So the normal 'events/lidbtn' does not suffer the 
problems that 'sleepbtn' does.

I hope that was clear enough and helps people understand why their 
fn-f4 key does not work with some versions of ibm-acpi/thinkpad-acpi 
and acpi-support.

Thank for all your work.

- Chris Burkhardt

Message #39 received at 467374-close@bugs.debian.org (full text, mbox, reply):

From: Bart Samwel <bart@samwel.tk>

To: 467374-close@bugs.debian.org

Subject: Bug#467374: fixed in acpi-support 0.109-1

Date: Tue, 13 May 2008 07:32:03 +0000

Source: acpi-support
Source-Version: 0.109-1

We believe that the bug you reported is fixed in the latest version of
acpi-support, which is due to be installed in the Debian FTP archive:

acpi-support-base_0.109-1_all.deb
  to pool/main/a/acpi-support/acpi-support-base_0.109-1_all.deb
acpi-support_0.109-1.dsc
  to pool/main/a/acpi-support/acpi-support_0.109-1.dsc
acpi-support_0.109-1.tar.gz
  to pool/main/a/acpi-support/acpi-support_0.109-1.tar.gz
acpi-support_0.109-1_i386.deb
  to pool/main/a/acpi-support/acpi-support_0.109-1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 467374@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bart Samwel <bart@samwel.tk> (supplier of updated acpi-support package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 12 May 2008 17:10:00 +0200
Source: acpi-support
Binary: acpi-support acpi-support-base
Architecture: source i386 all
Version: 0.109-1
Distribution: unstable
Urgency: low
Maintainer: Bart Samwel <bart@samwel.tk>
Changed-By: Bart Samwel <bart@samwel.tk>
Description: 
 acpi-support - scripts for handling many ACPI events
 acpi-support-base - scripts for handling base ACPI events such as the power button
Closes: 373660 405563 410478 426934 447742 450531 453706 453856 453861 455012 458437 458787 459326 459328 461311 461441 462954 463719 467347 467374 469556 471510 473184 475002 477917 480033
Changes: 
 acpi-support (0.109-1) unstable; urgency=low
 .
   * New upstream release 0.109 (Ubuntu Hardy) [no relevant changes].
   * New upstream release 0.108 (Ubuntu Hardy) [no relevant changes].
   * New upstream release 0.107 (Ubuntu Hardy):
     * "lib/FUJITSU SIEMENS.config": Fix typo, which caused failures on Fujitsu
       notebooks (LP: #203452)
   * New upstream release 0.106 (Ubuntu Hardy):
     * Add events/asus-video to support asus switch video hotkey; patch from
       Nicolò Chieffo (LP: #138228)
     * Fix the value range in sonybright.sh (0-7 instead of 1-8); patch from
       unggnu (LP: #136380)
     * "lib/FUJITSU SIEMENS.config":
       - Enable suspend for Fujitsu-Siemens C1110 (LP: #52970)
       - Enable STR for Fujitsu-Siemens Lifebook S7020, S7110
     * events/asus-*: Fix event key names for ASUS (HOTK); patch from
       Jeroen van der Vegt (LP: #25784)
     * Fix names in comments for events/panasonic-{mute,volume-down,volume-up}
     * Drop thinkpad_acpi.modprobe: the workarounds therein are not needed for
       thinkpad_acpi in Hardy anymore; investigations by Jerone Young
       (LP: #194679) [ Note from Bart Samwel: Therefore probably not needed in
       current Debian kernels either. ]
   * New upstream version 0.105 (from Ubuntu Hardy):
     * Fix screenblank for KDE by using a dcop call
   * Add HOTK key names in events/asus-* for more keys than provided by the
     upstream.
   * Remove extra non-owned files on purge. Closes: #455012
   * Call old acpid power button handler /etc/acpi/powerbtn.sh if present.
     Closes: #461311
   * Support "operstate" power state file for madwifi drivers. Closes: #453706.
   * Support operstate, rf_kill and power/state to determine if wireless is
     powered on. Closes: #463719.
   * Support asus-laptop module as well as asus-acpi module for setting the
     wireless LED. Closes: #453856.
   * As a fallback, detect X instances that were not started on a vt.
     Closes: #462954.
   * Add missing checks that acpi-support is installed to some of the config
     scripts. Closes: #469556.
   * Remove Default-Stop entries from vbesave init script, since the script
     doesn't do anything when it's stopped. Closes: #461441.
   * Check that a drive supports APM before using hdparm -B on it.
     Closes: #458787.
   * Divert sleep button to sleep.sh if power management daemons are not
     running, for thinkpad, panasonic, sony and toshiba laptops.
     Closes: #467374, 373660.
   * Stop laptop mode early in the suspend/hibernate process, and start it late
     at resume time. This fixes suspend/resume problems on at least one machine.
     Closes: #458437.
   * Config option USE_HIBERNATE_PACKAGE=true will now instruct acpi-support to
     delegate sleeping and hibernation to the "hibernate" package.
     Closes: #426934, #405563.
   * Check if we can actually open event device in acpi_fakekey. Closes: #410478.
   * Support Asus R1F tablet screen rotation. Kudos to Antonio Trueba.
     Closes: #450531.
   * Remove /etc/acpi/resume.d/49-915-resolution-set.sh. It will be moved to
     the 915resolution package. Closes: #447742, #467347.
   * Don't misinterpret Asus Eee PC hotkeys as brightness keys. Closes: #459328.
   * Support Asus Eee PC volume up/down and mute keys. Closes: #459326.
   * Get rid of extra quotes in asus-wireless.sh.
   * Fix handling of ${shlibs:Depends} in control file (it wasn't generated in
     the rules file).
   * Move radeontool to Recommends. (This is possible because radeontool is in
     task "laptop" now.)
   * Once again got rid of some bash dependencies. Closes: #453861.
   * Be able to detect X user when X has been started using startx. Thanks to
     Csaba Halasz for the patch. Closes: #471510.
   * Call wpa_action stop for wpasupplicant-controlled interfaces before suspend.
     Closes: #473184.
   * Correctly bring up logical interfaces on resume. Closes: #475002.
   * Instead of restarting Network Manager on suspend, call its sleep and wakeup
     events. Closes: #477917.
   * Add console-tools to depends of acpi-support-base, since we use fgconsole in
     power-funcs.
   * Fix dcop call in CheckPolicy to pass the X user. Closes: #480033.
   * Let acpi-support depend on exact version of acpi-support-base.
Checksums-Sha1: 
 f30e27f072247b64732ea39ca34fba7244e8300e 1061 acpi-support_0.109-1.dsc
 9275c9c34e10024394454f3fda4e4b8181d25bbb 54341 acpi-support_0.109-1.tar.gz
 0fe62bddb301c7f779293fbcaaa6ec8308d89ca0 48412 acpi-support_0.109-1_i386.deb
 3a19cf9cb8f4a926e4f1879e885eb7bf468e544a 20646 acpi-support-base_0.109-1_all.deb
Checksums-Sha256: 
 45360ab8748ea38c3c9faddbcd4ddaedc6012086eef10d2cd9045edf3f8b7fd3 1061 acpi-support_0.109-1.dsc
 4c5e56387d13fa6490e5cdc3f7fb42339e83898d49fc06f0bb33b2f67a5137bb 54341 acpi-support_0.109-1.tar.gz
 1e9163ae4f546fa7e76429b872d25ff375c020efc9e908c5358f0039cd888012 48412 acpi-support_0.109-1_i386.deb
 1bfb36b1a2641f5c5cfb05a7fb85f4a69a4c0969d0ff7f065251693ac3f93daa 20646 acpi-support-base_0.109-1_all.deb
Files: 
 0c1b965e1af4bba1167fac0c38dad28c 1061 admin optional acpi-support_0.109-1.dsc
 855e77e41dbcc2aae528596439e767cf 54341 admin optional acpi-support_0.109-1.tar.gz
 b95f0fe94c84086bbafc5f4669b6f754 48412 admin optional acpi-support_0.109-1_i386.deb
 a5ca7fc538c446dc4747accd98a5ed5a 20646 admin optional acpi-support-base_0.109-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Signed by Raphael Hertzog

iD8DBQFIKT1avPbGD26BadIRAoFQAJ96QT+gaj6G+U7SkEcpG5MmsRwsKACff08L
bSIX9eo26aK6AcQSFViw+bg=
=uFKt
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.