Ubuntu 20.04: Power Button Problem

stschulze · 11. Mai 2020

Zitat von M-Reimer

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.

mir wäre die Lösung über vdrpbd sehr recht ..... ich habe alles was ich finden konnte in den beitragen gepostet ...wir können gern zusammen versuchen das hinzubekommen.

M-Reimer · 11. Mai 2020

Siehe:

Ubuntu 20.04: Power Button Problem

Ggf. kann ich gerne auch eine gepatchte Version bereitstellen wenn das mit dem manuellen Eintragen nicht hinhaut. Wir bräuchten erstmal den passenden Device-Pfad.

Wenn es damit funktioniert könnte ich im nächsten Schritt schauen das ich das Lesen vom Device auf mehrere Threads auslagere. Dann würde auch wieder der Power-Button an der Gehäusefront gehen.

stschulze · 11. Mai 2020

Ich würde sagen, diese drei Input-Devices sind zu beachten:

Super wäre, wenn der vdrpbd in einem Analyselauf ein log in Datei schreibt und die Brauchbarkeit der Devices darstellt ..... oder ist das nicht machbar?

Code

aus dem Syslog:
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]



Terminal:
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

Alles anzeigen

M-Reimer · 11. Mai 2020

Eine "Brauchbarkeit" kann ich nicht kennen. Zumal man sich dann ganz schnell in Bereiche bewegt auf die ich keine Lust habe. Da wären z.B. USB-Tastaturen mit einem Sleep-Button. Die könnte auch jemand im Betrieb einstecken und nein: Ich möchte kein Hot-Plug-and-Play implementieren. Das Ding soll übersichtlich und pflegbar bleiben.

Davon abgesehen das ich eine Tastatur nun wirklich nicht vom X-Server trennen will. Ich glaube die große Mehrheit würde die Tastenanschläge doch gerne zum X-Server senden

Und ich glaube aktuell nichtmal das man mehr wie das /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input benötigt. Würde halt auf einen Versuch ankommen den ich selber nicht durchführen kann.

/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input würde nicht schaden aber ich glaube der ist bei CIR "interrupt-getriggert". Diesen Interrupt bekommen wir aber nie wenn das Ding garnicht erst schlafen geht.

M-Reimer · 11. Mai 2020

Nachtrag: Anbei ein gepatchtes "vdrpbd". Der Test bringt aber nur etwas wenn acpid definitiv deaktiviert und beendet ist.

Edit: Deine "dritte Variante" ist sogar schon drin. Einige Mainboards haben da wohl tatsächlich den "Hardware-Power-Button" dran. Folglich wären die drei die ich beachten würde genau die drei von dir vorgeschlagenen. Fehlt halt aktuell eine Multi-Threading-Unterstützung damit ggf. alle drei gleichzeitig genutzt werden.

stschulze · 11. Mai 2020

mit neuem vdrpbd

Code

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

Alles anzeigen

bei druck auf die PowerTaste der FB kommt eine Meldung des VDR am OSD bzgl. Ausschalten ...aber der NUC fährt sofort runter

M-Reimer · 11. Mai 2020

Dann haben wir aber fast das Ziel erreicht.

Vermutung: Systemd Inhibit geht nicht. Stelle Mal sicher das perl-net-dbus installiert ist.

stschulze · 11. Mai 2020

Code

root@BM2LTSR66Nuc64native:~# apt install libnet-dbus-glib-perl
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
libnet-dbus-glib-perl ist schon die neueste Version (0.33.0-3build1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

hatte nochmal ein reboot gemacht ....

Bei Druck auf Powertaste der FB kommt jetzt die Meldung am VDR "Taste drücken um ausschalten abzubrechen" ...dann fährt der VDR den NUC runter. Wenn eine Aufnahme läuft kommt "VDR schaltet später aus. Power zum erzwingen...."

alles schick an dieser Taste.

Der Power-Taster am NUC reagiert allerdings noch nicht.

M-Reimer · 12. Mai 2020

Prefekt. Ich werde dann mal vdrpbd so umbauen das ich das Behandeln der Devices als eigene Funktion ausgelagert ist. Und die starte ich dann so oft als eigenen Thread wie Devices da sind.

stschulze · 12. Mai 2020

das wäre super ....

ein Gedanke noch dazu ..... wenn noch irgendwelche anderen Devices dazu kommen würden, weil der vdrpbd noch auf anderer Hardware laufen müsste ....wäre es vielleicht sinnvoll die Devices in die conf einzutragen ....dann müsste nicht des vdrpbd-Skript angepasst werden ......

M-Reimer · 12. Mai 2020

Eigentlich ist der Wunsch ja gerade das nichts konfiguriert werden muss. Und wenn "ganz nach Wunsch" konfiguriert werden kann, dann dauert es nicht lange bis jemand auch irgendwelche USB-Geräte da reinkonfiguriert und sich dann wundert das nichts geht.

Teste das mal:

https://projects.vdr-developer…t/vdrpbd.git/plain/vdrpbd

Multi-Thread habe ich mir jetzt doch geschenkt. Es gibt "select" um mehrere Devices parallel zu beobachten.

stschulze · 12. Mai 2020

mmmhhhhh....jetzt fahren beide Powerbuttons (am NUC und auf der FB) den NUC ohne Warnmeldung sofort runter?! komisch .....

M-Reimer · 13. Mai 2020

Komisch. Kann ich so nicht nachvollziehen. Läuft wohl darauf hinaus das ich mehr Debug-Meldungen im Programm brauche.

Gibt es denn Fehlermeldungen im Log? Wenn der Shutdown stattfindet, dann erwarte ich zumindest das der exklusive Zugriff fehlschlägt.

Ubuntu 20.04: Power Button Problem

Jetzt mitmachen!

Teilen