User "vdr" unter yavdr aktiv nutzen können?

  • Hallo,


    eventuell eine sinnbefreite Frage .. ich nutze yavdr und darin ab und zu kodi, um für meine Kids Spiele anbieten zu können. In kodi verwende ich die addons "rom collection browser" und "steam-launcher", um diverse Spiele in einer "library" zu haben. Nun ist es so, daß bei "steam" mittlerweile auch windows spiele mittel "steam play" und wine bzw. valve's fork proton unter linux laufen. Soweit ich es verstanden habe, wird kodi unter dem user kontext "vdr" ausgeführt und somit auch das addon "steam-launcher" - dieses führt den steam-client aber nur im "big picture mode" aus, unter dem es nicht die Möglichkeiten gibt, diverse Einstellungen zu unternehmen (zB. am beta program teilzunehmen, oder die zu verwendende proton-Version einzustellen).


    Als workaround rufe ich den steam-client unter meinem erstellten user auf, mache dort die Einstellungen und dann kopiere ich die ganzen abgeänderten Config-files aus .user/steam .. nach /var/lib/.vdr/steam .. und ändere dann die Rechte owner/group auf vdr/audio ab.


    Gibt es eine Möglichkeit, den user "vdr" direkt unter einem xterm zu nutzen? Also so, daß man den steam-client unter dem user "vdr" aufruft und dort die Einstellungen abändert, damit diese dann mittels addon steam-launcher unter kodi gleich richtig verwendet werden? Oder geht das gar nicht?


    Danke für einen Wink in die richtige Richtung!


    Gruß, ciax

  • dieses führt den steam-client aber nur im "big picture mode" aus, unter dem es nicht die Möglichkeiten gibt, diverse Einstellungen zu unternehmen

    Kannst du den Big Picture Mode nicht einfach mit ALT + Enter verlassen?


    Der User vdr hat bei yaVDR <= 0.6 in der Vorkonfiguration keine Login-Shell (was man aber ändern kann, wenn man für ihn eine Shell starten können will). Ansonsten gibt es in VDR-Hardware, Dual-Use als Steam-Client ein Beispiel, wie man Steam unter dem Benutzer vdr ausführen (und aus dem VDR-Menü heraus) lassen kann, da müsstest du in der /usr/share/yavdr/templates/etc/init/steam.conf/10_main

    dann halt noch das Argument für den Big Picture Mode in der letzten Zeile rausnehmen.


    Bei yavdr-ansible gibt es eine richtige Systemd User-Session, in der man u.A. auch xterm unter dem Nutzer vdr laufen lassen kann.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Danke, das ging schnell! Muß mal versuchen, den Big Picture Mode mittels ALT+Enter zu verlassen. Ich möchte hier eher beibehalten, kodi für die Spielesammlung zu nutzen und nicht direkt aus dem vdr menu heraus.


    Quote

    Der User vdr hat bei yaVDR <= 0.6 in der Vorkonfiguration keine Login-Shell (was man aber ändern kann, wenn man für ihn eine Shell starten können will).

    Hmm, das würde mich interessieren .. bin aber etwas eingerostet und brauche immer einen Schupser.


    Für yavdr-ansible konnte ich bisher noch keine zeit finden, warte also noch etwas zu .. irgendwann braucht es aber auch hier einen etwas moderneren Unterbau.


    Danke dir!

    ciax

  • Hmm, das würde mich interessieren .. bin aber etwas eingerostet und brauche immer einen Schupser.

    Wie ich gerade gesehen habe, muss man dafür nichts extra machen, der User vdr wird zwar von vdr-Paket durch den Befehl in https://github.com/yavdr/vdr/b…6/debian/vdr.postinst#L74 angelegt und hat durch das Argument--disabled-login erst mal keine Login-Shell, aber yavdr-utils ändert das im Zuge der Installation: https://github.com/yavdr/yavdr…n/yavdr-utils.postinst#L6


    Also könntest du xterm aus dem VDR-Menü heraus starten und dann mit

    sudo su - vdr eine Bash-Shell unter dem Nutzer VDR starten.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Moin, es passt nicht mehr ganz zum Thread, aber doch irgendwie schon.


    Ich habe nun mal unter yavdr-ansible probiert, das System so hinzubekommen, wie bei der alten Installation. Dort habe ich via Kodi das Addon RCB (Rom Collection Browser) gestartet und darin die jeweiligen Spiele-Emulatoren.


    Jetzt unter ansible funktioniert es zwar, aber sämtliche Emus starten unter user "vdr", nicht meinem normalen Systemuser. Die meisten Config-Dateien der Emus werden automatisch unter $HOME des user abgelegt. vdr hat so ein Heimatverzeichnis nicht. Somit können keine spezifischen Einstellungen unternommen werden (es happert da ja oft, zB sound-device, fullscreen, ..).


    Jetzt weiß ich nicht wirklich weiter .. kann man irgendwie den user switchen, oder vor/bei start eines Emu-binary dort den user mitgeben? War da bei yavdr-06 etwas anders bzgl. der user, kodi und damit addons .. hmm?


    Grusz!

    Lascala LC17 - tribute to viking ;o) + atric IR / SoC ASUS J3455M-E / OctopusNet S4 / yavdr-(testing) vdr / output: graphTFT-fe via 6.4" TFT & DVB-S/S2 via FullHD / NVidia GT1030 passiv

    The post was edited 1 time, last by ciax ().

  • Die meisten Config-Dateien der Emus werden automatisch unter $HOME des user abgelegt. vdr hat so ein Heimatverzeichnis nicht.

    Doch, das ist wie schon bei früheren yaVDR-Versionen in /var/lib/vdr/.


    Jetzt weiß ich nicht wirklich weiter .. kann man irgendwie den user switchen, oder vor/bei start eines Emu-binary dort den user mitgeben? War da bei yavdr-06 etwas anders bzgl. der user, kodi und damit addons .. hmm?

    Mir ist nicht ganz klar, was der User-Switch außer neuer Probleme bringen soll - der User vdr hat eine Systemd-User Session, in der ein DBus Session Bus, pulseaudio, gsettings und was sonst noch alles für die Programme nötig ist laufen können. Das erhöht IMHO nur unnötig die Komplexität, wenn man da jetzt noch einen weiteren User reinbastelt, der Zugriff auf die Soundkarte usw. benötigt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Doch, das ist wie schon bei früheren yaVDR-Versionen in /var/lib/vdr/.

    Mensch! :wow - Danke! Also, wenn da die Emus ihre config-Dateien hinschreiben, wäre wirklich super - hab da noch nicht rein geschaut.


    Quote

    Mir ist nicht ganz klar, was der User-Switch außer neuer Probleme bringen soll - der User vdr hat eine Systemd-User Session, in der ein DBus Session Bus, pulseaudio, gsettings und was sonst noch alles für die Programme nötig ist laufen können. Das erhöht IMHO nur unnötig die Komplexität, wenn man da jetzt noch einen weiteren User reinbastelt, der Zugriff auf die Soundkarte usw. benötigt.


    Ja, es wäre nur eine Krücke gewesen. Du hast mir mit deiner Antwort aber schon wieder auf die Sprünge geholfen. Komme erst am abend dazu, es nochmal zu versuchen ...


    Danke :tup