Diskussion - X11

[brindosch]

Hallo @Paulchen-Panther ich hab wieder eine kleine Aufgabe :) Und zwar geht es um den X11Grabber, dein Liebling unter den Grabbern :)

• Ich hab angefangen mal was mit den den systemd services zu basteln. Du kannst mit make CPU_CORES package ja die packages basteln und die .deb mit dpkg -i /pfad/zur/Hyperion.deb. installieren. Den log output bekommst du über journalctl -u hyperiond. Die ENV_VAR display ist in dem Zusammenhang aber nicht verfügbar. Beim erzwingen von x11 als type crasht es direkt weg (seltsamerweise ohne x11 spez. log output - da ist ja genug der abgespuhlt werden sollte als Fehlerhinweis). Ich weiß gerade allerdings nicht so richtig wie man das mit den start der services so richtig nachstellt, weil in gdb laden kann man so ja nicht direkt im den segfault Punkt besser zu erkennen.
• Einen anderen Weg als getenv() um zu erkennen ob x11 gerade läuft (instanz erstellt werden soll). Eventuell macht es auch Sinn x11 beim kompilieren zu hardcoden wenn type auto ist. Das hängt aber maßgeblich mit dem systemd service zusammen, wie man das dann lösen kann.

Ist was zum tüfteln, dein Spezielgebiet :)

Schönen Sonntag brindosch

[Paulchen-Panther]

Beim erzwingen von x11 als type crasht es direkt weg (seltsamerweise ohne x11 spez. log output - da ist ja genug der abgespuhlt werden sollte als Fehlerhinweis). Ich weiß gerade allerdings nicht so richtig wie man das mit den start der services so richtig nachstellt, weil in gdb laden kann man so ja nicht direkt im den segfault Punkt besser zu erkennen.

Ich glaube dein Problem beschreibt dieser Post am besten: stackexchange.com

Die ENV_VAR display ist in dem Zusammenhang aber nicht verfügbar

Zum Zeitpunkt der Packageerstellung sollte die DISPLAY variable doch verfügbar sein, sofern eine Sessions besteht!?! Soll aber nicht heißen das beim nächsten neustart eine besteht.

[brindosch]

Ich glaube dein Problem beschreibt dieser Post am besten

Hab es ja schon befürchtet. Dann muss das service file in den user context für x11. Selbst wenn man was versuchen würde zu umgehen, lässt der X11 bestimmt keine Verbindung ohne modifikation am System zu. Was natürlich gewollt ist. Zusammenfassung: Die .deb scripts müssen die x11 envvar überprüfen und einen service im Nutzer context erstellen. Wobei man sich natürlich fragen kann, ob man eine Desktop/Startmenü Verknüpfung anlegt und einfach keinen Service, so dass man es von Hand starten kann und beenden. Supi, wieder was zu tun :D

Zum Zeitpunkt der Packageerstellung

Hab mich unglücklich ausgedrückt. Ich meine beim Ausführen von hyperiond vom service file aus. Aber siehe oben.

Eigentlich könnte man x11 noch nen display Feld verpassen wie osx. Fällt mir gerade so ein. Jetzt mach ich aber erstmal v4l fertig.

[brindosch]

Oh ich muss vielleicht erwähnen, dass Ubuntu 16.04/Debian 9 mit qt5.5 und python 3.5 Mindestmaß sind. Zum einen hat es weder unter debian 8 noch unter ubuntu 14.04 kompiliert und zum anderen war mir die Zeit dann doch zu schade bei vergleichsweise wenig Nutzen (Rein zufällig hat erst kürzlich OSMC das update auf Debian 9 bekommen). Entsprechend kann ich jetzt wieder auf dem Nutzsystem testen.

Die Frage was man mit proto macht ist noch offen. Ich würds ja einfach entfernen und was simpleres nutzen. Vielleicht den websockets binär Ansatz den redPanther noch implementiert hatte mal antesten. Wobei websockets ohne client implementierung eher schlechter zu implementieren sind. Hm...

Oh du musst noch den wave effect testen und feedback geben :)

[Paulchen-Panther]

Hab da was gefunden zu X11 Errors. Vielleicht hilfreich um die unprotokollierten Abstürze von x11 zu loggen. CopyQ

[Paulchen-Panther]

Und eine alternative Methode um die DISPLAY var zu ermitteln. VideoLan

[brindosch]

Super danke. Ich versuche zuerst nur den service entsprechend anzupassen.