Ubuntu 20.04: Power Button Problem

stschulze · 10. Mai 2020

hi,

ich verwende Ubuntu 20.04 auf einem Intel NUC NUC8i3BEH2.

Auf dem System läuft eine Installation des VDR.

Der VDR wird per Fernbedienung über LIRC gesteuert.

Bis zu Ubuntu v18.04.4 wurde der Power Button der Fernbedienung durch Ubuntu nicht ausgewertet. D.h. bei Druck auf den Power Button der FB hat der LIRC dem VDR ein Signal gesendet und der VDR-Prozess hat dann das Herunterfahren des NUC entsprechend vorhandener Regeln (z.B. Aufnahme läuft -> es wird später heruntergefahren) initiiert.

Seit 20.04 wird das System beim Drücken des Power Button in einen Sleep State geschickt, d.h. Ubuntu wertet jetzt diesen Tastendruck aus und initiiert den Schlafzustand.

Wie kann ich Ubuntu 20.04 das abgewöhnen?

Was nicht ausreicht, ist:

{{{#!code bash

systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

}}}

Grund: Durch das maskieren der Targets wird zwar verhindert, dass der NUC in den Sleep State gesetzt wird, jedoch fährt der Rechner dann initiiert durch Ubuntu runter und die vorhandenen Regeln des VDR ("Aufnahme läuft -> später herunterfahren") werden nicht beachtet.....

M-Reimer · 10. Mai 2020

Sowas wie "vdrpbd" installieren und starten.

"vdrpbd" blockiert die Behandlung des Power-Buttons durch systemd und sendet das Signal stattdessen an den VDR.

stschulze · 10. Mai 2020

Ich habe vdrpbd auf Ubuntu 20.04 installiert:

Code

/etc/vdrpbd.conf


# Numer of keypresses and ...
ER_COUNT=4

# ... time range in seconds to trigger emergency reboot
ER_TIME=3

# Set this to "dbus" to send power button event via dbus2vdr plugin
# Set this to "kodi" to send power button event to Kodi via TCP
TARGET=svdrp

Alles anzeigen

Code

root@BM2LTSR66Nuc64native:/home/vdrpbd-2.0.1# make install
pod2man vdrpbd vdrpbd.1
pod2man vdrpbd.conf.pod vdrpbd.conf.5
mkdir -p /usr/local/share/man/man1
gzip -c vdrpbd.1 > /usr/local/share/man/man1/vdrpbd.1.gz
mkdir -p /usr/local/share/man/man5
gzip -c vdrpbd.conf.5 > /usr/local/share/man/man5/vdrpbd.conf.5.gz
mkdir -p /etc
cp -pn vdrpbd.conf /etc
install -D -m 755 vdrpbd /usr/local/sbin/vdrpbd
install -D -m 644 vdrpbd.service /lib/systemd/system/vdrpbd.service
sed -i "s#/usr/sbin/vdrpbd#/usr/local/sbin/vdrpbd#" /lib/systemd/system/vdrpbd.service
root@BM2LTSR66Nuc64native:/home/vdrpbd-2.0.1#

Alles anzeigen

Code

root@BM2LTSR66Nuc64native:/home/vdrpbd-2.0.1# systemctl start vdrpbd.service 
root@BM2LTSR66Nuc64native:/home/vdrpbd-2.0.1# systemctl enable vdrpbd.service 
Created symlink /etc/systemd/system/multi-user.target.wants/vdrpbd.service → /etc/systemd/system/vdrpbd.service.
root@BM2LTSR66Nuc64native:/home/vdrpbd-2.0.1#

Code

root@BM2LTSR66Nuc64native:/home/vdrpbd-2.0.1# systemctl status vdrpbd.service 
● vdrpbd.service - VDR ACPI power button handling daemon
     Loaded: loaded (/etc/systemd/system/vdrpbd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2020-05-10 13:54:11 CEST; 13s ago
   Main PID: 3810 (vdrpbd)
      Tasks: 2 (limit: 38280)
     Memory: 29.6M
     CGroup: /system.slice/vdrpbd.service
             └─3810 /usr/bin/perl /usr/sbin/vdrpbd -f

Mai 10 13:54:11 BM2LTSR66Nuc64native systemd[1]: Started VDR ACPI power button handling daemon.
Mai 10 13:54:12 BM2LTSR66Nuc64native vdrpbd[3810]: Failed to get exclusive access!
root@BM2LTSR66Nuc64native:/home/vdrpbd-2.0.1#

Alles anzeigen

nach einem Neustart des NUC:

Code

root@BM2LTSR66Nuc64native:~# systemctl status vdrpbd.service 
● vdrpbd.service - VDR ACPI power button handling daemon
     Loaded: loaded (/etc/systemd/system/vdrpbd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2020-05-10 14:02:47 CEST; 20s ago
   Main PID: 525 (vdrpbd)
      Tasks: 2 (limit: 38280)
     Memory: 37.9M
     CGroup: /system.slice/vdrpbd.service
             └─525 /usr/bin/perl /usr/sbin/vdrpbd -f

Mai 10 14:02:47 BM2LTSR66Nuc64native systemd[1]: Started VDR ACPI power button handling daemon.

Alles anzeigen

sieht also ganz gut aus, der vdrpbd.service läuft.

ABER:

Bei Druck auf die Power-Taste der Fernbedienung wird der NUC dennoch in den Sleep gesetzt!

seahawk1986 · 10. Mai 2020

Schau mal mit fuser nach, wer da auf das Device zugreift: fuser -v /dev/input/event0 - vermutlich ist es der X-Server, dann hilft es vdrpbd vor dem X-Server starten lassen oder dem X-Server zu sagen, dass er das Gerät nicht einbinden soll.

stschulze · 10. Mai 2020

Code

root@BM2LTSR66Nuc64native:~# fuser -v /dev/input/event0
                     BEN.        PID ZUGR.  BEFEHL
/dev/input/event0:   root        470 f.... acpid
                     root        522 F.... systemd-logind
                     root        962 F.... Xorg

der vdrpbd greif auf event2 zu .....

Code

root@BM2LTSR66Nuc64native:~# fuser -v /dev/input/event2
                     BEN.        PID ZUGR.  BEFEHL
/dev/input/event2:   root        503 F.... systemd-logind
                     root        506 f.... vdrpbd
                     root        507 f.... acpid
                     root       1155 F.... Xorg

wie sage ich dem X-Server, dass er das Device nicht einbinden soll?

stschulze · 10. Mai 2020

ich komme der Sache näher ....

wenn ich den Power-Button am NUC drücke reagiert der vdrpbd :

Code

May 10 15:01:58 BM2LTSR66Nuc64native vdrpbd[518]: Power key pressed. May 10 15:01:58 BM2LTSR66Nuc64native vdrpbd[518]: ConnectTCP: Connection refused at /usr/sbin/vdrpbd line 235.

allerdings sieht es wohl so aus, dass der NUC über den eingebauten IR-Empfänger ein weiteres Device hat, welches bei Druck auf die Power Taste der FB (das läuft über LIRC) den NUC in den Schlafzustand versetzt ......

M-Reimer · 10. Mai 2020

vdrpbd versucht bereits exklusiven Zugriff auf das Device zu bekommen. Und es wird ja auch geloggt das eben das schiefgeht:

Zitat

Mai 10 13:54:12 BM2LTSR66Nuc64native vdrpbd[3810]: Failed to get exclusive access!

Was mich eigentlich wundert...

Aber Moment...

Mach mal

Code

# systemctl stop acpid
# systemctl disable acpid

stschulze · 10. Mai 2020

das hat nichts gebracht .....

wie bereits beschrieben ..... es gibt scheinbar zweites device (CIR ....powerbutton), welches reagiert und vom vdrpbd.service nicht kontrolliert wird .....

M-Reimer · 10. Mai 2020

Ja, das ist prinzipiell denkbar. Und ohne genaue Kennung des Devices auch schwer zu erkennen.

Mach mal:

Code

ls -l /sys/devices/LNXSYSTM:00/LNXPWRBN:00

Eigentlich braucht man den Pfad über /sys/devices der zu deinem "/dev/input0" geht. Und um dann beide zu locken müsste man wohl oder übel zwei Threads starten um auf beiden Devices zu lauschen.

Das Problem, gerade mit dem VDR, ist eben das man dem X-Server gleichzeitig den Zugriff nehmen muss weil sonst genutzte Window-Manager ggf. die Taste auf "unerwünschte Art und Weise" auswerten. Was prinzipiell auch ausschließt einfach wahllos Devices zu binden.

Wo wir wieder bei dem Thema sind das die Ausgabe beim VDR besch...eiden gemacht ist

Wenn ich Kodi starte, dann wertet der den Power-Button ganz alleine aus. Kein Bedarf da irgend etwas zu machen.

seahawk1986 · 10. Mai 2020

Zitat von M-Reimer

Das Problem, gerade mit dem VDR, ist eben das man dem X-Server gleichzeitig den Zugriff nehmen muss weil sonst genutzte Window-Manager ggf. die Taste auf "unerwünschte Art und Weise" auswerten.

Das lässt sich relativ einfach umsetzen - man setzt per udev-Regel z.B. sowas ENV{ID_INPUT.tags}="ignore-me" für die Input-Devices, die vom X-Server ignoriert werden sollen und fügt dann noch ein Snippet für die Xorg-Konfiguration ein:

Code

Section "InputClass"
    Identifier "exclude input devices"
    MatchTag   "ignore-me"
    Option     "Ignore"    "True"
EndSection

fnu · 10. Mai 2020

Power Button oder Power Management Probleme sind m.E. zwei Paar unterschiedliche Schuhe ... ?

Titel mal der Thematik angepasst ... ?

M-Reimer · 10. Mai 2020

Das Ignorieren ist, wenn ich das Device mal finde, ja das kleinste Problem. Wenn ich die entsprechenden Infos bekomme kann ich das in vdrpbd einbauen.

stschulze · 10. Mai 2020

evtl. hilf das hier weiter -> Input16 müsste es sein:

Code

root@BM2LTSR66Nuc64native:~# for i in /sys/class/input/input* ; do echo -n "$(basename "$i"): "; cat "$i/name"; done
input0: Sleep Button
input1: Power Button
input15: Logitech K400
input16: ITE8708 CIR transceiver
input17: lircd-uinput
input18: HDA Intel PCH Mic
input19: HDA Intel PCH Front Headphone
input2: Power Button
input20: HDA Intel PCH HDMI/DP,pcm=3
input21: HDA Intel PCH HDMI/DP,pcm=7
input22: HDA Intel PCH HDMI/DP,pcm=8
input23: HDA Intel PCH HDMI/DP,pcm=9
input24: HDA Intel PCH HDMI/DP,pcm=10
input8: Video Bus

Alles anzeigen

Code

root@BM2LTSR66Nuc64native:~# cat /proc/bus/input/devices
I: Bus=0019 Vendor=0000 Product=0003 Version=0000
N: Name="Sleep Button"
P: Phys=PNP0C0E/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0
U: Uniq=
H: Handlers=kbd event0 
B: PROP=0
B: EV=3
B: KEY=4000 0 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
U: Uniq=
H: Handlers=kbd event1 
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
U: Uniq=
H: Handlers=kbd event2 
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0019 Vendor=0000 Product=0006 Version=0000
N: Name="Video Bus"
P: Phys=LNXVIDEO/video/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8
U: Uniq=
H: Handlers=kbd event3 
B: PROP=0
B: EV=3
B: KEY=3e000b00000000 0 0 0

I: Bus=0003 Vendor=046d Product=4024 Version=0111
N: Name="Logitech K400"
P: Phys=usb-0000:00:14.0-4/input2:1
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.2/0003:046D:C52B.0003/0003:046D:4024.0004/input/input15
U: Uniq=4024-b1-2f-1c-ce
H: Handlers=sysrq kbd mouse0 event4 leds 
B: PROP=0
B: EV=12001f
B: KEY=3f000301ff 0 0 483ffff17aff32d bfd4444600000000 ffff0001 130ff38b17c007 ffff7bfad9415fff ffbeffdfffefffff fffffffffffffffe
B: REL=1943
B: ABS=100000000
B: MSC=10
B: LED=1f

I: Bus=0019 Vendor=1283 Product=0000 Version=0000
N: Name="ITE8708 CIR transceiver"
P: Phys=
S: Sysfs=/devices/virtual/rc/rc0/input16
U: Uniq=
H: Handlers=kbd event5 
B: PROP=20
B: EV=100017
B: KEY=c00 0 2000003c30a 233001000000000 0 300158000 1ba00004000 eb78000000000 201200811944ffe
B: REL=3
B: MSC=10

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="lircd-uinput"
P: Phys=
S: Sysfs=/devices/virtual/input/input17
U: Uniq=
H: Handlers=sysrq rfkill kbd event6 
B: PROP=0
B: EV=100003
B: KEY=ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff fffffffffffffffe

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH Mic"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input18
U: Uniq=
H: Handlers=event7 
B: PROP=0
B: EV=21
B: SW=10

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH Front Headphone"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input19
U: Uniq=
H: Handlers=event8 
B: PROP=0
B: EV=21
B: SW=4

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=3"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input20
U: Uniq=
H: Handlers=event9 
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=7"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input21
U: Uniq=
H: Handlers=event10 
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=8"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input22
U: Uniq=
H: Handlers=event11 
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=9"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input23
U: Uniq=
H: Handlers=event12 
B: PROP=0
B: EV=21
B: SW=140

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA Intel PCH HDMI/DP,pcm=10"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:1f.3/sound/card0/input24
U: Uniq=
H: Handlers=event13 
B: PROP=0
B: EV=21
B: SW=140

Alles anzeigen

Code

root@BM2LTSR66Nuc64native:~# fuser -v /dev/input/*
                     BEN.        PID ZUGR.  BEFEHL
/dev/input/event0:   root        512 F.... systemd-logind
                     root        521 f.... acpid
                     root       1036 F.... Xorg
/dev/input/event1:   root        512 F.... systemd-logind
                     root        521 f.... acpid
                     root       1036 F.... Xorg
/dev/input/event10:  root        521 f.... acpid
/dev/input/event11:  root        521 f.... acpid
/dev/input/event12:  root        521 f.... acpid
/dev/input/event13:  root        521 f.... acpid
/dev/input/event2:   root        512 F.... systemd-logind
                     root        516 f.... vdrpbd
                     root        521 f.... acpid
                     root       1036 F.... Xorg
/dev/input/event3:   root        521 f.... acpid
                     root       1036 F.... Xorg
/dev/input/event4:   root        512 F.... systemd-logind
                     root        521 f.... acpid
                     root       1036 F.... Xorg
/dev/input/event5:   root        512 F.... systemd-logind
                     root        521 f.... acpid
                     root       1036 F.... Xorg
/dev/input/event6:   root        512 F.... systemd-logind
                     root        521 f.... acpid
                     root       1036 F.... Xorg
/dev/input/event7:   root        521 f.... acpid
/dev/input/event8:   root        521 f.... acpid
/dev/input/event9:   root        521 f.... acpid

Alles anzeigen

stschulze · 10. Mai 2020

Code

input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0
ACPI: Sleep Button [SLPB]
input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
ACPI: Power Button [PWRB]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
ACPI: Power Button [PWRF]

stschulze · 10. Mai 2020

habe auf der FB den Power-Button gedrückt und folgendes über ACPI_listen bekommen:

Code

root@BM2LTSR66Nuc64native:~# acpi_listen 
button/sleep SBTN 00000080 00000000 K

dann legt sich der NUC schlafen .....erneuter Tastendruck auf Powertaste der FB:

Code

button/power PBTN 00000080 00000000

jetzt ist die Box wieder da.....

stschulze · 10. Mai 2020

Bei Drücken des Powerbutton am NUC:

Code

root@BM2LTSR66Nuc64native:~# acpi_listen 
button/power PBTN 00000080 00000000
button/power LNXPWRBN:00 00000080 00000001

stschulze · 11. Mai 2020

Lösung:

ACPI-Events für den Intel NUC NUC8i3BEH2 benutzen

Umsetzung unter Ubuntu 20.04:

1. "Ausschalten der Sleep-State Targets"

Code

systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

2. ACPI-Daemon Konfigurieren

/etc/default/acpid

Code

# Options to pass to acpid
#
# OPTIONS are appended to the acpid command-line
OPTIONS="-l -d "

# Linux kernel modules to load before starting acpid
#
# MODULES is a space separated list of modules to load, or "all" to load all
# acpi drivers, or commented out to load no module
#MODULES="battery ac processor button fan thermal video"
MODULES="all"

Alles anzeigen

/etc/default/acpi-support

Code

#
# Configuration file for the acpi-support package
#
#
# The acpi-support package is intended as "glue" to make special functions of
# laptops work. Specifically, it translates special function keys for some
# laptop models into actions or generic function key presses.
#


#
# Suspend/hibernate method
# ------------------------
#
# When gnome-power-manager or klaptopdaemon are running, acpi-support will
# translate the suspend and hibernate keys of laptops into special "suspend"
# and "hibernate" keys that these daemons handle.
#
# Only in situations where there is no gnome-power-manager or klaptopdaemon
# running, acpi-support needs to perform suspend/hibernate in some other way.
# There are several options for this. The options are:
#
# dbus-pm:
#    Perform suspend and hibernate actions via a DBUS request to the power
#    management daemon. This works for power management daemons that we don't
#    know of. (For gnome-power-manager and klaptopdaemon this will do nothing,
#    since those will be detected when they are running, and triggered using
#    a virtual keypress.)
#
# dbus-hal:
#    Perform suspend and hibernate actions via a DBUS request directly to HAL,
#    bypassing any running power management daemons.
#
# pm-utils:
#    Use pm-suspend and pm-hibernate to suspend and hibernate. (The dbus method
#    normally results in this as well, but calls through dbus. Use this option
#    only if you don't have dbus installed.)
#
# hibernate:
#    Use the hibernate package to suspend and hibernate.
#
# acpi-support:
#    Use the legacy built-in suspend/hibernate support. (DEPRECATED)
# 
# none:
#    Do not attempt to suspend/hibernate. Set SUSPEND_METHODS="none" to
#    disable suspend/hibernate handling in acpi-support.
#
# If you specify dbus or pm-utils, the result will normally be the same as when
# you suspend from your desktop environment. If you specify "hibernate" or
# "acpi-support", be aware that this probably does not match what your desktop
# environment would do (unless you have managed to configure something so that
# the DBUS power management interfaces call the hibernate package).
#
#
# Please specify a space separated list of options. The recommended value is
# "dbus pm-utils"
#
SUSPEND_METHODS="dbus-pm dbus-hal pm-utils"



#
# LEGACY BUILT IN SUSPEND SUPPORT (DEPRECATED)
# --------------------------------------------
#
# These options only work for the "acpi-support" suspend method. This is NOT
# recommended, but is retained for backward compatibility reasons.
#

# Comment the next line to disable ACPI suspend to RAM
ACPI_SLEEP=true

# Comment the next line to disable suspend to disk
ACPI_HIBERNATE=true

# Change the following to "standby" to use ACPI S1 sleep, rather than S3.
# This will save less power, but may work on more machines
ACPI_SLEEP_MODE=mem

# Add modules to this list to have them removed before suspend and reloaded
# on resume. An example would be MODULES="em8300 yenta_socket"
#
# Note that network cards and USB controllers will automatically be unloaded 
# unless they're listed in MODULES_WHITELIST
MODULES=""

# Add modules to this list to leave them in the kernel over suspend/resume
MODULES_WHITELIST=""

# Should we save and restore state using the VESA BIOS Extensions?
SAVE_VBE_STATE=true

# The file that we use to save the vbestate
VBESTATE=/var/lib/acpi-support/vbestate

# Should we attempt to warm-boot the video hardware on resume?
POST_VIDEO=true

# Save and restore video state?
# SAVE_VIDEO_PCI_STATE=true

# Should we switch the screen off with DPMS on suspend?
USE_DPMS=true

# Use Radeontool to switch the screen off? Seems to be needed on some machines
# RADEON_LIGHT=true

# Uncomment the next line to switch away from X and back again after resume.
# This is needed for some hardware, but should be unnecessary on most.
# DOUBLE_CONSOLE_SWITCH=true

# Set the following to "platform" if you want to use ACPI to shut down
# your machine on hibernation
HIBERNATE_MODE=shutdown

# Comment this out to disable screen locking on resume
LOCK_SCREEN=true

# Uncomment this line to have DMA disabled before suspend and reenabled
# afterwards
# DISABLE_DMA=true

# Uncomment this line to attempt to reset the drive on resume. This seems
# to be needed for some Sonys
# RESET_DRIVE=true

# Add services to this list to stop them before suspend and restart them in 
# the resume process.
STOP_SERVICES=""

# Restart Infra Red services on resume - off by default as it crashes some
# machines
RESTART_IRDA=false

# Add to this list network interfaces that you don't want to be stopped
# during suspend (in fact any network interface whose name starts with
# a prefix given in this list is skipped)
SKIP_INTERFACES="dummy qemu"

# Note: to enable "laptop mode" (to spin down your hard drive for longer
# periods of time), install the laptop-mode-tools package and configure
# it in /etc/laptop-mode/laptop-mode.conf.

Alles anzeigen

3. ACPI-Event's erstellen

Event ermitteln durch Tastendruck auf jeweilige Powertaste

Code

acpi_listen

/etc/acpi/events/nuc-powerbutton

Code

event=button/power LNXPWRBN:00 00000080
action=/etc/acpi/vdrpoweroff.sh

/etc/acpi/events/remote_powerbutton

Code

event=button/sleep SBTN 00000080 00000000 K
action=/etc/acpi/vdrpoweroff_null.sh

/etc/acpi/events/remote_powerbutton2

Code

event=button/power PBTN 00000080 00000000
action=/etc/acpi/vdrpoweroff.sh

4. ACPI-Skript's erstellen

/etc/acpi/vdrpoweroff.sh

Bash

#!/bin/sh
# /etc/acpi/vdrpoweroff.sh

/usr/sbin/svdrpsend.sh "HITK POWER" > /dev/null
sleep 10

/etc/acpi/vdrpoweroff_null.sh

Bash

#!/bin/sh
# /etc/acpi/vdrpoweroff_null.sh

/usr/sbin/svdrpsend.sh "HITK POWER" > /dev/null

4. ACPI-Daemon neu starten und Status kontrollieren

Code

systemctl restart acpid

systemctl status acpid

Fertig.

M-Reimer · 11. Mai 2020

Ich glaube nicht das es "input16" ist. Da glaube ich eher das LIRC "drauf sitzt" und das da die IR-Codes kommuniziert werden.

Es wird schon "input0" geblieben sein. So Kram der direkt auf dem Mainboard sitzt (vor allem wenn man ihn nicht mit "lsusb" sieht) wird sehr früh in der Boot-Folge initialisiert. Vermutlich besteht der CIR-Kram aus mehreren Devices, denn irgendwie startet der Rechner ja auch per Fernbedienung. Das geht aber ohne Betriebssystem. Schon denkbar das die eine Taste von einem dedizierten Controller behandelt wird und der Rest dann von einem zweiten.

Füge mal vor dieser Zeile:

https://projects.vdr-developer…rpbd.git/tree/vdrpbd#n201

noch folgendes ein:

/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input

Weil der vdrpbd-Daemon ein Script ist kannst du eine Sicherheitskopie der Version auf deinem System machen und dann direkt im installierten vdrpbd editieren.

Dann vdrpbd neu starten oder ggf. mit dem gepatchten vdrpbd die Kiste mal rebooten.

Wenn das geht, dann ist der Power-Button vorne am Gerät aber erstmal nicht mehr abgefangen. Das kann natürlich nicht so bleiben. Ich würde aber gerne wissen ob das überhaupt im Prinzip funktioniert bevor ich auf mehrere Threads umstelle.

Es wäre wohl auch nicht falsch diesen hier abzufangen: "ACPI: Power Button [PWRB]" aber meine Vermutung ist, dass wir das Event nie bekommen wenn wir schaffen den Sleep zu verhindern.

M-Reimer · 11. Mai 2020

Zitat von stschulze

Lösung:

ACPI-Events für den Intel NUC NUC8i3BEH2 benutzen

Kann man machen, muss man aber nicht. Eigentlich war "vdrpbd" als "fire and forget"-Lösung gedacht um eben acpid nicht mehr konfigurieren zu müssen. Der sollte auf einem VDR-System dann eigentlich gar nicht mehr laufen.

Wenn ich aber keine weiteren Infos mehr bekomme ist das Thema hier für mich durch. Selber habe ich kein CIR und VDR im Frontend nutze ich schon seit Jahren nicht mehr.

Wie schon erwähnt: Mit Kodi geht das "einfach so". Der schaltet für die Tasten selber einen "inhibit" und behandelt die dann selber.

447377 · 11. Mai 2020

Folgenden Eintrag habe ich in meinem Log-Buch gefunden. Ich meine, dass ich damals den "Power-Sleep" beim NUC in den Griff bekam.

Stefan

Code

• Sleep bzw. Suspend durch Fernbedienung Poweroff-Taste
        ◦ vi /etc/systemd/logind.conf
            ▪ #HandleSuspendKey=suspend
            ▪ HandleSuspendKey=ignore

Ubuntu 20.04: Power Button Problem

Jetzt mitmachen!

Teilen