softhddevice und vdr shutdown

So, jetzt erst mal die wenig spektakuläre Erweiterung des Softhddevice-Plugins. Das Patch ist jetzt erst mal für den vpp_branch aus dem presintta repo. Ich erstelle für das vdr-developer repo gleich noch einen Patch. Ich hoffe ich bekomme git in den Griff und kann beide Repos tracken.

Folgendes habe ich gemacht:
* In den Settings unter General wurde eine neue Option eingeführt: "VDR shutdown erlaubt wenn detached".
* Die entsprechenden Abfragen im Plugin-Code habe ich eingeführt.

Folgendes habe ich gestestet:
* Der Shutdown-Counter läuft nicht, wenn die Option nicht aktiv ist.
* DerShutdwon-Counter läuft, wenn die Option aktiv ist.
* Die Übersetzung ins Deutsche wird angezeigt.
* Die Einstellung bleibt über Neustart erhalten.

Zitat von seahawk1986

Ich denke, das Problem ist, dass KDE nicht zuerst bei Logind nachschaut, ob es Inhibitoren gibt, sondern direkt Suspend aufruft - ich hatte die gleiche Frage wegen dem Verhalten von KODI auch schon mal im Bugtracker gestellt und die Antwort von L. Poettering war, dass das so gedacht ist, wenn eine Anwendung des gleichen User über DBus auf logind zugreift: https://bugs.freedesktop.org/show_bug.cgi?id=66321
Man mste den Inhibitor also unter einem anderen User setzen, damit er den Suspend in dem Fall blockiert.

Das mit der anderen User wäre im VDR Fall ja implizit so. Ich habe das eben versucht mit positivem Ergebnis. Sowohl der manuelle als auch der automatische Shutdown werden blockiert. In beiden Fällen wir ein Dialog geöffnet um nach einem Freigabepasswort zu fragen. Leider hängt der gesamte Prozess danach an dem Dialog. Auch wenn der Inhibitor geschlossen wird, wird der Suspend aber nicht fortgesetzt. Der Rechner würde also nicht automatisiert einschlafen, wenn der vdr einen Inhibitor gesetzt hat und der Timer für den Shutdown abläuft. Im Anhang das Log von dem Ganzen.

Wenn ich das richtig verstehe, dann hat der KDE damit wiederum nur wenig zu tun, sondern agiert nur als Frontend für das Policy Kit. Der logind sagt dem Policy Kit es solle mal eine Autorisierung einfordern. Und das wartet dann eben. Wie seht ihr das?

Zitat von seahawk1986

IMHO verhält sich da KDE nicht optimal - es müsste erst unter org.freedesktop.login1.Manager CanSuspend aufrufen und wenn das nicht 'yes', sondern z.B. 'challenge' zurück liefert einen automatischen Suspend-Versuch abbrechen, da das nicht nicht-interaktiv ablaufen kann und wenn der Suspend interaktiv aufgerufen wird, könnte es den Nutzer fragen, ob er den Suspend erzwingen will und muss auch damit zurecht kommen, wenn die PolicyKit Authentifizierung fehlschlägt bzw. abgebrochen wird.

Soll ich dazu einen Bug-Report an die KDEler schreiben? Vlt. ändern die das dann ja. Einen Versuch wäre es wert!

Ok, hier noch das Patch für den Detach-Mode basierend auf dem master brach von Johns. Das Patch für den VPP-Support Branch hatte noch 2 andere Änderungen mit drin. Ich habe mich inzwsichen gitmäßig besser sortiert und meine Änderungen in Branches sortiert. Ich habe diesen Patch darum auch nochmal angehängt.

Zitat von seahawk1986

Probieren kann man es mal... - du könntest auch noch ausprobieren, ob KDE auf what="idle" bei einem Inhibitor im mode="block" reagiert, das sollte die Aktionen bei Inaktivität betreffen.

Danke für den (weiteren) Tipp! Der vdr muss aber gerade den Tatort aufnehmen. Ich teste das dann danach.

Das Ticket bei KDE erstelle ich morgen.

Wenn man idle blockiert geht der Rechner einfach in den Suspend. Ich habe das Inhibit-Programm von einem anderen User ausgeführt und dann den Rechner automatisch einschlafen lassen. Hier das angepasste Python Programm, zur Kontrolle:

#!/usr/bin/python3


import dbus
import logging
import time


bus = dbus.SystemBus()




def inhibit(what='idle', who='First Base',
            why="left field", mode="block"):
    try:
        a = bus.get_object('org.freedesktop.login1',
                                '/org/freedesktop/login1')
        interface = 'org.freedesktop.login1.Manager'
        print("Inhibitor opened: what = {}, mode = {}".format(what, mode))
        fd = a.Inhibit(what, who, why, mode, dbus_interface=interface)
        return fd
    except Exception as error:
        logging.exception(error)
        logging.warning("could not set inhibitor lock")


if __name__ == '__main__':
    my_inhibitor_fd = inhibit()
    #input('press any key to exit inhibitor')
    inhibitTime = 120
    print("Suspend inhibitor will be active for {} seconds".format(inhibitTime))
    time.sleep(inhibitTime)

Gute Nacht

Zitat von seahawk1986

IMHO verhält sich da KDE nicht optimal - es müsste erst unter org.freedesktop.login1.Manager CanSuspend aufrufen und wenn das nicht 'yes', sondern z.B. 'challenge' zurück liefert einen automatischen Suspend-Versuch abbrechen, da das nicht nicht-interaktiv ablaufen kann und wenn der Suspend interaktiv aufgerufen wird, könnte es den Nutzer fragen, ob er den Suspend erzwingen will und muss auch damit zurecht kommen, wenn die PolicyKit Authentifizierung fehlschlägt bzw. abgebrochen wird.

Bevor ich den Bug-Report bei KDE gepostet habe, wollte ich die Sache nochmal testen. Der Methode CanSuspend ist übrigens nicht vom logind, sondern von org.freedesktop.PowerManagement.Inhibit. Ich habe das getestet mit aktivem inhibitor:

qdbus org.freedesktop.PowerManagement.Inhibit /org/freedesktop/PowerManagement/Inhibit CanSuspend
true

Das klappt also leider nicht.

Wenn ich an der Kommandozeile vom Sessionuser

systemctl suspend

eingebe, wird der suspend wie zuvor geprüft verhindert (zur Sicherheit nochmal ausgeführt). Ich habe den Bug trotzdem gemeldet, vtl. hat sich die Architektur auf dem dbus auch geändert. KDE hat bestimmt Know-How auf dem Gebiet und weiß wie es gemacht werden müsste.

mini73: Ich habe bereits 6 Downloads für den Patch.

Die Antwort von KDE kam prompt. Immerhin ist der Fehler akzeptiert. Mal sehen ob es irgendwann gelöst wird.

Bzgl des Inhibit habe ich nochmal auf dem dbus gestöbert. Wenn man

qdbus --system --literal org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.ListInhibitors

ausführt, bekommt man alle Inhibitoren angezeigt. Darüber sollte man ein kleines Programm erstellen können, das die Inhibitoren auswertet, evtl. auf vdr als "reason" prüft und im Falle eines vdr-Inhibitors dies dann auf den Session-Bus mapt. Da dieses Vorgehen den inhibitor Mechanismus zweckentfremdet, könnte man auch gleich einen eigenen Service schreiben, der mit dem vdr direkt kommuniziert. Damit wäre dann auch gleich ein VDR Desktop Statusmonitor mit drin.

Wie seht ihr das? Wäre das auch mit anderen Desktops verträglich?