Bug 1012325

Which system is this about? Power buttons differ.

Leap 42.2 does not use ACPI on ARM, it uses Device Tree.

How does devicetree deliver button events?

Last time I looked they were delivered as input events just like the ACPI button events which the ACPI daemon knows how to listen for.

(In reply to Michal Suchanek from comment #2)
> How does devicetree deliver button events?
> 
> Last time I looked they were delivered as input events just like the ACPI
> button events which the ACPI daemon knows how to listen for.

Device trees can configure things in multiple ways. One way is gpio-keys, which translates GPIO inputs to key codes.

In order to find out, we would need to know which system you tested this on (my question), so that we can review the .dts file.

Referring to your post referencing this bug:
https://lists.opensuse.org/opensuse-arm/2016-11/msg00089.html

I was not aware of any power button on my headless Cubietruck, and I don't spot any key definition in the Factory .dts (so unlikely in 42.2 either):

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun7i-a20-cubietruck.dts?h=v4.8

Are you saying it works on Tumbleweed but fails on Leap 42.2, or did you only test Leap 42.2?

ok, so I installed acpid and it does not log any events when pressing power button on Cubietruck so the driver is broken there.

Anyway, there is no valid reason to not include it. My keybaord has a power key as well and I can connect it to any system with USB.

(In reply to Andreas Färber from comment #3)

> I was not aware of any power button on my headless Cubietruck, and I don't
> spot any key definition in the Factory .dts (so unlikely in 42.2 either):

It's the microswitch next to IR sensor. It's inherent part of the AXP209 PMIC. Since there is no sane way to use the PMIC without wiring a power key it is always wired and does need a DT property I guess.

> 
> Are you saying it works on Tumbleweed but fails on Leap 42.2, or did you
> only test Leap 42.2?

I only tested Leap.

This is an autogenerated message for OBS integration:
This bug (1012325) was mentioned in
https://build.opensuse.org/request/show/442509 Factory / acpid

This is an autogenerated message for OBS integration:
This bug (1012325) was mentioned in
https://build.opensuse.org/request/show/443048 42.2 / acpid

If I'm not totally mistaken, power- (and other system-) button events are nowadays handled by systemd-logind.
Acpid is no longer in charge of shutting down the system upon acpi events.

What is acpid in charge of then?

The AXP209 driver does not have battery events on the supported platforms AFAIK, unfortunately.

acpid can run custom scripts on acpi events.
In the good old times™, there was a config file for the power button:

----
event=button/power
action=shutdown -h now
----
(or similar), but nowadays, all acpi events are fed into the input layer, like every other keypress, and systemd-logind listens for the power/sleep/lid-button events and acts upon them. Once a desktop session is started, a service can request to take over the button handling from logind.

acpid still can run the scripts on ACPI events. I run it to still use my old thinkpad script which acts upon Fn-F1 (switch bluetooth on and off):
----
susi:~ # cat /etc/acpi/events/thinkpad_seife
# forward acpi events to the thinkpad handler (bluetooth etc.)
event=button/fnf.*
action=/usr/lib/acpid/thinkpad_handler_seife "%e"
----
thinkpad_handler_seife is like this:
----
#!/bin/bash
HOTKEY=$1
set $HOTKEY
EVENT=$1   # "ibm/hotkey"
ACPI=$2    # "HOTK"
WHAT=$3    # "00000080"
SERIAL=$4  # "0000100c" Fn+F12
if [ "$WHAT" = "00000080" -a "$SERIAL" = "00001001" ] || \
   [ "$EVENT" = "button/fnf1" ]; then
    toggle bluetooth
fi
----
(the drivers changed somewhen, the script can handle both versions).

But that's the only thing acpid is doing on this machine. Shutdown etc. is not handled by acpid, as you can see from the non-existence of config files in /etc/acpid/events

Even on x86, acpid is pretty obsolete nowadays.
So whatever problem you are trying to solve, acpid is probably not part of the solution.
The only reason acpid could help would be if on ARM, acpi events were not fed into the input layer, but then the drivers certainly should be fixed.

ok, the acpid has only one rule which is in a file called thinkpad.

It logs the power button event with the recent kernel update that hes the PEK driver, does nothing with it, and the desktop handles it.

In any case the daemon is not particularly platform specific.

.

hm, acpid can actually handle volume keys as well. Unfortunately, it cannot handle "Home" key making it useless as general purpose special button handler.

openSUSE-RU-2016:3125-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 1012325
CVE References: 
Sources used:
openSUSE Leap 42.2 (src):    acpid-2.0.25-4.1