http://bugzilla.opensuse.org/show_bug.cgi?id=1012325 http://bugzilla.opensuse.org/show_bug.cgi?id=1012325#c1 --- Comment #1 from Andreas Färber --- Which system is this about? Power buttons differ. Leap 42.2 does not use ACPI on ARM, it uses Device Tree. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1012325 http://bugzilla.opensuse.org/show_bug.cgi?id=1012325#c3 Andreas Färber changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchanek@suse.com Flags| |needinfo?(msuchanek@suse.co | |m) --- Comment #3 from Andreas Färber --- (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... Are you saying it works on Tumbleweed but fails on Leap 42.2, or did you only test Leap 42.2? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1012325 Michal Suchanek changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.opensuse.o | |rg/show_bug.cgi?id=1012477 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1012325 http://bugzilla.opensuse.org/show_bug.cgi?id=1012325#c8 Stefan Seyfried changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |seife@novell.slipkontur.de --- Comment #8 from Stefan Seyfried --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1012325 http://bugzilla.opensuse.org/show_bug.cgi?id=1012325#c10 --- Comment #10 from Stefan Seyfried --- 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. -- You are receiving this mail because: You are on the CC list for the bug.