Gen2vdr macht das so:
Code
XINITOPTS=""
XVT="vt7"
XSERVEROPTS="-br"
CMD="xinit $XINITOPTS -- $XVT $XSERVEROPTS"
screen -dm sh -c "su -c "$CMD""
softhddevice für Dummies?
-
-
Wenn ich softhddevice mit '-x' (als root) starte, dann scheint sich etwas mehr zu tun, aber ich bekomme auch nur einen schwarzen Bildschirm.
Was stand dabei im Log? Ich hätte es noch mit dem zusätzlichen Startargument "-v va-api" probiert (unter der Voraussetzung, dass bereits ein ausreichend aktueller intel-vaapi-driver installiert ist).
Ich wollte halt einfach schnell zu einer Lösung kommen, aber das ist mit softhddevice anscheinend nicht so einfach...
90% davon war es gegen die Besonderheiten bei den Paketstrukturen von Open SuSE zu rudern, die restlichen 10% sind dann noch Eigenheiten von xorg und softhddevice. -
Ja, X11 kann schon mühsam sein, wenn man einzelne Paket installiert, gibt doch bestimmt eben die Möglichkeit eine kompletten Desktop zu installieren, da ist in der Regel doch alles dabei. Platz-mäßig fällt das wenig ins Gewicht auf der Platte ...
Ich mache mir die Mühen nimmer, Ubuntu Desktop Standardard Installation, X11 startet schon automatisch. Ein Autologin für den Nutzer "vdr", den Standard Fenstermanager Unity auf openbox ändern, .xhosts mit "127.0.0.1", läuft ...
Feinarbeiten, eine "20-intel.conf" nach "/etc/X11/xorg.conf.d" legen, damit der Monitor fest 50Hz macht, kann meine posten, wenn wieder zu Hause. Und noch unclutter installieren, damit der Mauszeiger nicht nervt.
Gruß
FrankPS.: Für Nvidia eben "20-nvidia.conf" ...
-
Naja, wenn das schon eine Weile nutzt ist eigentlich schon einfach, ich würde auch etwas brauchen bis ich die FF-HD am laufen hätte, weil keine Erfahrung.
Dein J3455 hat beste Vorraussetzungen für softhddevice-vpp-hevc ...
... die Lernkurve ist steil, wenn X11 läuft.Gruß
Frank -
Bei dem kurzen Test, den ich mit MLD gemacht habe, hat das alles auf Anhieb prima funktioniert. Daher dachte ich, das sollte sich ja wohl hinkriegen lassen. Aber so einfach ist das anscheinend nicht. ich weiß schon, warum ich immer auf FF-Karten gesetzt habe ;-).
Na ja, aber das liegt doch an SuSE und nicht an softhddevice. Siehe MLD, und mit Debian/Ubuntu, Archlinux und dem Zeug von den Gentoo-Rittern hättest du deutlich weniger Probleme gehabt.Gerald
-
aber das liegt doch an SuSE
Ganz so schwarz-weiß würde ich das nicht sehen. OpenSuSE hat auch ein große zufriedene Nutzergemeinde, das funktioniert nicht schlechter als die anderen genannten ... eben X11 muss halt laufen.
Du würdest Dich wundern wie stark zypper dem apt ähnelt ...
Gruß
Frank -
Ganz so schwarz-weiß würde ich das nicht sehen. OpenSuSE hat auch ein große zufriedene Nutzergemeinde, das funktioniert nicht schlechter als die anderen genannten ... eben X11 muss halt laufen.
Das stelle ich gar nicht in Frage, nur ist diese Nutzergemeinde aber nicht gewillt, oder nicht in der Lage, einigermaßen aktuelle VDR-Pakete zur Verfügung zu stellen. Da hilft dann zypper auch nicht weiter.Gerald
-
Daher dachte ich, das sollte sich ja wohl hinkriegen lassen. Aber so einfach ist das anscheinend nicht. ich weiß schon, warum ich immer auf FF-Karten gesetzt habe ;-).
Die kleine Herausforderung ist, ein minimales X11 zum laufen zu bringen und sauber in den Systemstart zu integrieren, dass den Anforderungen von softhhdevice genügt.Anschließend softhddevice zum laufen zu bringen ist eine Kleinigkeit. Abhängigkeiten müssen natürlich installiert sein, und man muss wie schon geschrieben den richtigen branch auswählen.
Du bist diesbezüglich vermutlich einfach nur etwas aus der ÜbungBei mir läuft der "petsintta-Branch" auf einem Asrock N3150 seit einiger Zeit mindestens so problemlos wie das vorher verwendete nvidia-vdpau.
Ich vermisse nur das HL-OSD von louis, ohne das läuft der skindesigner doch deutlich zäher. Ist aber für native Skins kein Thema.Also gibt dir noch mal einen Ruck, du wolltest doch deine Hardware modernisieren: Die 6400 muss wech, softhddevice rulez
-
nur ist diese Nutzergemeinde aber nicht gewillt, oder nicht in der Lage, einigermaßen aktuelle VDR-Pakete zur Verfügung zu stellen. Da hilft dann zypper auch nicht weiter.
Wenn Klaus mit selbst gebauten VDR-Entwicklungsversionen an neuen Features arbeiten will, dann helfen fertige VDR-Pakete nicht unbedingt weiter ...Die ganzen VDR-Distributionen existieren ja nur, weil es nicht ganz trivial ist einen VDR samt Plugins und ggf. einem oder mehreren X-Servern zum Laufen zu bringen
-
Was sagt denn das X Log?
Das liegt i.d.R unter: "/var/log/Xorg.0.log"
-
Ohne Ausgabemethode sieht man nichts:
CodeFeb 2 23:47:04 vdr3 vdr: video/noop: noop driver running on display ':0'
Ich würde wie schon weiter oben geschrieben mal vaapi explizit mit "-Psofthddevice -v va-api" setzen. Außerdem scheinen die Alsa-Bibliotheken beim Bau des Plugins gefehlt zu haben, sonst würde er nicht auf oss zurückgreifen, was mich zur Frage führt, ob du die Bau-Abhängigkeiten für die zusätzlichen Bibliotheken (insbesondere alsa-devel und libva-devel) installiert hattest, als du das Plugin gebaut hast. -
Das ist sehr schade! Ich dachte eigentlich, daß das für alle, die keine FF-Karten verwenden, das wichtigste Ausgabeplugin wäre - oder täusche ich mich da?
Da sollte es doch wirklich *eine* verbindliche Quelle geben...Wäre wünschenswert. Bei der "offiziellen Quelle" steht auch immer noch "planned: remove VA-API support". Und letztes Commit irgendwo vor über einem Jahr. Aber es wird wohl auch Gründe haben warum diejenigen, die in letzter Zeit Features implementiert haben, sich nie um Commit-Rechte bemüht haben.
Das Starten des X-Servers ist in der Tat ein bisschen eine Herausforderung. In dem Zusammenhang finde ich es mittlerweile fast schade, dass softhddevice den VDR auf "direktem Weg" mit dem X-Server verbindet. Xineliboutput hat getrenntes Backend und Ausgabe aber leider ist die Ausgabe mit xineliboutput zumindest bei mir nicht ganz so nah an der Full-Featured. Also wird Klaus da wohl durch müssen.
Die Funktion, dass softhddevice den X-Server mitstartet, bringt nichts. Hat nie richtig funktioniert. Der X-Server ist immer zu spät da. Teile des OSDs werden verschluckt. Mit softhddevice muss ein X-Server bereit sein bevor der VDR gestartet wird. Nein, detaching wird nicht sein was Klaus will, denn auch dann sind teile des OSDs schon "abgefrühstückt" bevor eine Ausgabe bereit ist. Zum Beispiel entfällt dann das Aufpoppen der Kanal-Info beim Starten. Für Entwicklungszwecke würde ich die aber sehen wollen.
Ich habe keine Ahnung wie Klaus seinen VDR startet? Aber im Prinzip müsste er nur sowas wie https://github.com/joukewittev…n/blob/master/x-daemon.in vor dem VDR starten. Dieses kleine Script macht etwas, was der X-Server eigentlich selber können sollte: Es startet den X-Server und beendet sich (forkt) sobald der X-Server bereit ist. Wenn also dieses Script sich "beendet" kann danach der VDR gestartet werden.
Die bereits angesprochenen Treiber-Probleme bleiben davon natürlich unberührt.
-
Ich habe jetzt alsa und alsa-devel installiert und auch https://software.opensuse.org/package/vaapi-intel-driver.
Hast du auch libva-devel installiert, damit softhddevice mit VAAPI-Unterstützung gebaut werden kann?
-
-
Ich habe keine Ahnung wie Klaus seinen VDR startet?
Am liebsten gehe ich so vor:
- Minimale Linux-Installation (traditionell SUSE, weil ich halt damals damit angefangen habe - Baby Duck Syndrome ;-).
- Alles installieren, was an Treibern und zum Übersetzen von VDR nötig ist.
- Per Script Treiber und VDR laden.Ich brauche auf der VDR-Maschine keinen Desktop (und möchte auch keinen). Wenn das Ausgabedevice X11 braucht, dann sollte es mit einer minimalen Variante ohne großen Desktop und Windowmanager zurecht kommen.
Mein Traum wäre: *ein* Script, das man nach einer minimalen Linux-Installation aufruft und das *alles* installiert und konfiguriert, was für die o.g. Betriebsweise erforderlich ist. Aber sowas gibt es anscheinend (zumindest für SUSE) nicht.
MLD hat mir da sehr gut gefallen. "It just works - out of the box!". Kann man das als Grundlage für ein Entwicklungssystem verwenden? Also alles nachinstallieren, was man zum Übersetzen von VDR und Plugins braucht? Wenn ja, dann wäre das vielleicht ein gangbarer Weg, denn das, was ich in den letzten Tagen mit openSUSE 42.2 erlebt habe, ist einfach nur traurig...
Klaus
-
Ich würde es mal mit der Version 1.7.3 des vaapi-intel-driver probieren - für ein 64-Bit System müsste das dieses Paket sein: http://download.opensuse.org/r…ver-1.7.3-55.1.x86_64.rpm
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!