[HowTo] Softdevice-Plugin, Epia ME6000, DirectFB, RealPC geht auch

Hallo morone,

danke für die Infos, habs mittlerweile auch rausgefunden.

Die Frage wäre halt ob man das mit einem Skript machen kann,
also ungefähr so:

setze das Register mit Wert für RGB
und
setze das Register mit Wert für S-Video

Gruß
Wolfgang

Warum kompliziert wenns auch einfach geht.
Beim viafb gibts auch Parameter aber da musst du dich an Htpc-Schrauber
wenden.

Hier mal nen Patch fuern Openchrome. Eigenes Risiko versteht sich
(vorher mal mit vt1622 testen).
Aber funzt hier .

Jo, ich hatte das nur beim Framebuffer-Treiber von DirectFB gemacht. Beim Openchrome kann natürlich logischerweise was anderes gesetzt werden.

Was die Parameter angeht:
Das ist mein Problem. Ich kanns nicht. Ich kann das eine Headerfile vom Treiber so anpassen, das RGB raus kommt. Wenn man es aber über Parameter steuern will, dann müsste man einen neuen Parameter für den Treiber erfinden. D.h. wirklich was programmieren. Ich kann zwar ein bißchen C, aber bei dem, was die da im Treiber veranstalten, hab ich echt keinen Durchblick. Deswegen kann ich nur einen harten Patch auf RGB zur Verfügung stellen. Bin gestern nicht mehr dazu gekommen. Heute abend mach ich den fertig.

Was die Schaltspannung angeht:
Eine Schaltspannung kann man vom VT1622 nicht abgreifen. Die gibt es einfach nicht. Deswegen wird das nicht gehen.
Aber wenn mich nicht alles täuscht, dann liegt beim Digitainer die Schaltspannung permanent an, egal was eingestellt ist. Deswegen kommt an nem RGB-fähigen Eingang immer nur S/W raus, egal was man im Bios einstellt. Der Eingang wird glaub immer auf RGB geschaltet. Aber ich werd mir das nochmal reinziehen. Da muss ich mal mit nem Messgerät an den Digitainer. Wird aber noch dauern.

Wie gesagt, heut abend kommt erstmal der Patch.

@Morone: Wie sieht bei Dir das RGB-Bild mit dem Openchrome aus? Auch so ein deutlicher Unterschied?

Hmmpf,
ich hab grad nochmal im Sourcecode vom viafb gewühlt. Also ich blick da nicht durch. Die Initialtabelle entsprechend zu ändern ist ja kein Problem. Aber was der dann damit treibt, das blick ich nicht. Was ich rein schreib, das funktioniert auch. Aber ich hab kein Durchblick, wie man den Sourcecode ändern könnte, damit man es per Parameter einstellen kann.

@Morone: Ich hab grad nochmal ins Datenblatt geschaut. Also bei Dir war schon auf RGB konfiguriert, wenn da 2b drin stand. Aber es war Sync on Green eingeschaltet. Das funktioniert bei Scart-RGB nicht. Da kommt der Sync über die Composite-Leitung, soweit ich weiß.
Außerdem war noch ein Parameter gesetzt, von dem ich nicht weiß, wozu er gut ist. Nennt sich 'Output for CSO'. Normalerweise ist 'Output for HSO' Default. So steht es jetzt auch, wenn man 0x02 rein schreibt. Mir fällt aber grad nicht ein, wofür CSO und HSO stehen könnten.

EDIT: Grad gefunden:
CSO steht für TV Composite Sync
HSO steht für Horizontal Sync

Eigentlich wäre CSO richtig, aber auf HSO funktionierts. Sehr komisch. Ich muss das heute nochmal austesten, bevor ich einen falschen Patch abliefere. Aber ich glaube, die CSO/HSO Einstellung ist egal, weil die auf nem extra PIN raus geht, der glaub gar nicht verbunden ist.
Ich denke, es lag bei Dir an dem Sync on Green.

Klingt einleuchtend ..lol (hab eh kein Plan ;))
aber deckt sich mit dem Zustand hier..

TV schaltet ja schon beim Booten auf RGB.
Register ist ohne viafb auf 0x2a ,
Mit fb ist der Wert hier auch 0x00.

Das Bild hat mich bis jetzt noch nicht so vom Hocker gehauen.

Btw. , wenn ich mir den openchrome Patch so anschaue , duerfte
da was schiefgegangen sein.

Muesste so sein :

-	xf86I2CWriteByte(pBIOSInfo->TVI2CDev, 0x02, 0x2A);
+//      Changes for Digitainer II
+//	xf86I2CWriteByte(pBIOSInfo->TVI2CDev, 0x02, 0x2A);
+ 	xf86I2CWriteByte(pBIOSInfo->TVI2CDev, 0x02, 0x02);

@Morone: Du kannst natürlich keine VGA-Qualität erwarten. Konsole am TV über TV-Ausgang ist auch nix. Dafür ist es nicht gemacht. Aber vergleiche mal das Videobild mit dem eines DVD-Players. Bei mir (jetzt an nem 32" LCD) ergeben sich da keine sichtbaren Unterschiede. Sollte es bei Dir deutliche Unterschiede geben, dann streut vielleicht eine Steckkarte im Digitainer in das Verbindungskabel ein. Also ich hab hier zumindest ein absolut scharfes und klares Bild.
Versuch mal bitte den Wert 0x22 in dem Register. Das müßte eigentlich auch gehen. Und das schaltet den bei PAL eigentlich üblichen Composite Sync ein.

@All: Hier der Patch. Probiert es aus. Er ist gegen den linux-viafb aus dem DirectFB.org CVS. Er setzt 0x22. Also RGB mit Composite Sync. Die erste Version war RGB mit Horizontal Sync.
Ich bitte um Rückmeldung, ob es funktioniert. Sollte das bei einzelnen nicht hinhauen, dann muss ich nochmal andere Parameter setzen. Bei mir funktionert er ohne Probleme.

Nochmal: Nach dem Patch funktioniert nur noch RGB. S-Video kommt dann nicht mehr raus.

Und noch eins: Ich hab inzwischen rausgefunden, das man sogar Komponenten Video ausgeben könnte. Auch nett. Müßte man aber nen Scart-Adapter basteln/kaufen oder zusätzliche Buchsen in den Digitainer bauen. Allerdings seh ich da keinen Vorteil gegenüber RGB.

Also genug geschwätzt. Anzuwenden ist der Patch mit
patch -p1 -i linux-viafb-patch.diff

Hallo HTPC-Schrauber,

also bei mir klappt der patch so, danke nochmal. => Gibt astreines RGB!!!!

PS: Habs im easyVDR-Forum auch ein bisschen ausführlicher dokumentiert

http://www.easy-vdr.de/forum/i…ic=1728.msg14287#msg14287

Gruß
Wolfgang

Zitat

Morone: Du kannst natürlich keine VGA-Qualität erwarten. Konsole am TV über TV-Ausgang ist auch nix.

Ich hab schon vdr getestet
Ist hier aber mehr VHS-Qualitaet .
Kannst net mal deinen Treiber komplett posten oder mitteilen wo du ihn herhast.
Paar Register sind hier auch noch anders gesetzt.

Hallo morone,

das ist der Original-Treiber von directfb:

cvs -d:pserver:anonymous@cvs.directfb.org:/cvs/directfb -z3 co -P linux-viafb

Und hier die Änderungen:

http://www.easy-vdr.de/forum/i…ic=1728.msg14287#msg14287

Gruß
Wolfgang

Der Treiber ist der linux-viafb von directfb.org
Also ein reiner Framebuffer-Treiber.
Bei mir läuft VDR auf der Konsole via Framebuffer. Deswegen dieser Treiber.

Wahrscheinlich ist bei Dir noch ne Skalierung drin. Deswegen die schlechtere Quali. Der viafb ist direkt darauf optimiert, ohne Skalierung das TV-Bild auszugeben. Das ist gar nicht so simpel, weil der VT1622 eigentlich gar nicht darauf ausgelegt ist. Aber wie das unter Linux so ist, kann man jede Hardware vergewaltigen
Also erstmal musst Du eine Modline für PAL haben. Also 720x576.
Dann müssen noch ein paar Register im VT1622 gesetzt werden.
Vom Prinzip her läuft das folgendermaßen ab:
Es wird ein normales VGA-Bild erzeugt. Der VT1622 captured dann das VGA-Bild und formt es so um, das PAL draus wird.
Das bedeutet letztendlich, das man zuerst ein VGA-Bild erzeugen muss, das schon PAL entspricht. Dann muss der VT1622 noch überredet werden, das er das Bild nicht nochmals verwurschtelt, sondern es nimmt, wie es ist.

Du kannst die Registersettings vom viafb übernehmen. Die sind eigentlich auf PAL optimiert. Nur musst Du dann Deine Modline so anpassen, das das Bild auch passt.
Für den Framebuffer-Treiber ist halt schon ein passender Eintrag für die fb.modes dabei. Das ist der Vorteil.
Aber grundsätzlich sollte unter X dieselbe Qualität erreichbar sein.

Noch ein Hinweis für alles Framebuffer-Nutzer:
Ich habe nur den Teil des Treibers gepatch, der sich auf eine Overscan-Ausgabe ohne Skalierung bezieht. D.h. wenn eine Konsole ohne Overscan angezeigt wird, dann ist es immer noch S/W. Wichtig ist eigentlich, das in der fb.modes das Flag 'bcast true' gesetzt ist.

Zitat

Noch ein Hinweis für alles Framebuffer-Nutzer:
Ich habe nur den Teil des Treibers gepatch, der sich auf eine Overscan-Ausgabe ohne Skalierung bezieht. D.h. wenn eine Konsole ohne Overscan angezeigt wird, dann ist es immer noch S/W. Wichtig ist eigentlich, das in der fb.modes das Flag 'bcast true' gesetzt ist.

Habe mich schon gewundert.

Ist schon klar dass es sich um den dfb-viafb hier handelt.
Hier laeuft so ziemlich alles. Ich hatte gestern nur openchrome
getestet , da ich das viafb Modul geloescht hatte (wegen udev).

Was mich gewundert hatte :
Meine Werte :
/* TV regs (720x576 no scaling) */
{ 0x04, 0x00, 0x22, 0x04, 0x00, 0x00, 0x20, 0x4f, 0x84, 0x2a, 0x5a, 0x00, 0x49, 0x44, 0x00, 0x09, 0x00,

..bei dir:
{ 0x04, 0x00, 0x22, 0x04, 0x00, 0x00, 0x20, 0x4f, 0x7b, 0x2a, 0x5a, 0x00, 0x49, 0x44, 0x00, 0x09, 0x00,

Ansonsten Entwarnung.
Noname Scartkael raus , Oehlbach ran..top Bild ..das IST RGB

Ich werde mal das ganze als Kernelparameter einbauen , obwohl , wer will da zurueck ;). Das ist beim DFB-viafb eher spartanisch programmiert.
Beim Via-viafb braucht man nur ne case Anweisung um RGB ergaenzen.
Ob das dann klappt ist ne andere Geschichte , da egal was ich im BIOS
einstelle , mein TV immer auf RGB schaltet.

Ps.. und das der vt1621 kein RGB kann , da hat HTCP-Schrauber recht. Bei mir musste ich auch nur den einen Wert aendern.

Uuuups, das hab ich übersehen.
Folgendes:
Ich habe bei mir, wie schon erwähnt, die Ausgabe vom Digitainer ziemlich Pixelgenau mit der Ausgabe meines DVD-Players (Grundig GDP5100) abgeglichen. Im Vergleich war das Bild beim Digitainer um ein paar Pixel zu weit rechts.
Der zweite Parameter verschiebt das Bild um 9 Pixel nach links. Weiter nichts.

Hier nochmal der Patch für den Original viafb.
Ich hatte nicht dran gedacht, das ich den ja auch geändert hatte.

EDIT:
Morone: Wenn Du da nen Parameter draus machen kannst, das wär natürlich echt der Hit. Ich hatte an sowas gedacht: TVon=1 wie bisher CVBS und S-Video und TVon=2 gibt dann RGB. Dann braucht man keinen neuen Parameter.
Ich hatte, wie gesagt, reingeschaut. Aber ich hab da keinen wirklich Durchblick.
Das die Umschaltung nicht funzt, wenn man an nem RGB-Eingang ist, ist klar. Aber falls man mal umsteckt auch einen Nicht-RGB ist es hilfreich. Weil dann würde mit dem Patch nichts gescheites rauskommen. Auf jeden Fall mal kein S-Video. CVBS müßte trotzdem noch gehen.
Ich nehme an, das der Digitainer immer die RGB-Schaltspannung liefert und den TV damit auf RGB zwingt. Schaltbar machen kann man das wahrscheinlich nicht. Aber das werd ich nochmal durchmessen.

Schade:
Ich hab mich nochmal durchs Datenblatt gegraben. Der VT1622 bietet leider keine Möglichkeit, ein irgendwie schaltbares Ausgangssignal zu erzeugen. Mir gings um Automatische RGB-Umschaltung und evtl. sogar 16:9 Umschaltung. Aber vom TV-Encoder her bietet sich da nichts.

Verschiedene Spannungen an die Pins zu legen ist ja nicht das Problem. Nur sie per Software schaltbar zu machen, dazu fällt mir nichts ein. Leider. Wäre natürlich genial gewesen, wenn man 16:9 und auch RGB hätte irgendwie automatisch schalten können.

So und gleich nochmal:
Ich hab gerade noch die Pinbelegungen vom Scart angeschaut und mit dem Datenblatt des VT1622 abgeglichen.
Schlechte Nachrichten für alle, die bisher meinten, S-Video zu sehen:
Am Scart des Digitainer kommt im Normalzustand des viafb-Treibers so kein S-Video raus. Da gibts nur Composite. Geht auch gar nicht anders, weil Scart Composite und S-Video nicht gleichzeitig übertragen kann. Bei S-Video wird nämlich die Composite-Leitung für das Luma-Signal verwendet.
Um S-Video auszugeben, muss im Register 0x02 des VT1622 ein anderer Wert stehen. Und zwar 0x01.
Ich kanns an meinem derzeitigen TV nicht verifizieren. Weil der am Digitainer immer gleich auf RGB geht. Und er hat nur RGB-Fähige Eingänge. Ich müsste den Digitainer erst wieder in ein anderes Zimmer tragen. Es wäre nett, wenn das mal einer verifizieren könnte.

@Morone: Wenn Du wirklich den Treiber entsprechend änderst, dann sollten wir gleich auch noch S-Video vorsehen. Wäre dann echt stark, wenn man per Kernelparameter Composite, S-Video und RGB umschalten könnte.

Ich will heute abend auch nochmal reinschauen, weil ja momentan bei RGB mit dem Patch die Konsole noch S/W bleibt. Ich hatte, wie gesagt, nur den No-Scale mit Overscan angepasst. In meinem Falle läuft die Konsole ohne Overscan. Und diese Tabelle hatte ich nicht gepatcht.

Jo, das geht sicherlich. Wenn man noch einen COM-Port hat. Meiner ist belegt durch attric.

Aber zurück zum Treiber-Patch:
Ich hab nun noch einen Patch fertig gemacht. Wieder anzuwenden gegen das Original, nicht gegen die schon geänderte Version.
Die Änderung bezieht sich auf die Konsole. Ich hab bei mir die Ausgabe auf der Konsole auch auf 720x576, allerdings ohne Overscan. Und das kam noch nicht als RGB raus. Deswegen ändert dieser Patch auch noch die Ausgabe ohne Overscan auf RGB.

So, ich hab noch ein bißchen weiter experimentiert:

Ich hatte noch folgendes Problem:
Es hat nach dem VDR-Start sehr lange gedauert (ca. 10 Sekunden) bis ein Bild kam. Außerdem hatte ich teilweise sehr lange Umschaltzeiten (auch bis 10 Sekunden). Oft gings auch sehr schnell. Aber manchmal eben unerklärlicherweise nicht. Des weiteren hat mich genervt, das beim Umschalten das ganze Bild erstmal total verblockt ist.

Ich hab dann mal das Log genauer analysiert. Es scheint am Hardwaredecoder zu liegen. Der scheint mit fehlerhaften MPEG2-Daten richtig aus dem Tritt zu kommen.

Also versuchweise abgeschaltet, indem ich dem softdevice nur noch '-vo dfb:viatv' mitgebe anstelle von '-vo dfb:cle266:viatv'.
Siehe da, Umschaltzeiten sind allgemein kürzer (nur noch ca. 1 Sekunde). Keine Verblockung beim Umschalten. Denkpausen beim Umschalten sind nur noch äußerst selten. Zeit von VDR-Start bis zum Bild hat sich halbiert (ca. 5 Sekunden).

Nun zur CPU-Last: Ich hatte laut Top mit Hardware-Beschleunigung immer um die 30 % Last.
Jetzt sind es 10 % mehr. Also 40 %.
Der Digitainer kann das also eigentlich locker verkraften.
Ich habs jetzt so gelassen. Es nützt mir ja auch nichts, wenn sich die CPU langweilt. Von daher ist es egal.
Ruckler o.ä. hab ich dadurch auch keine. Die Bildqualität ist, wie gehabt, einwandfrei.

Kann ich nicht bestätigen. Bei mir sieht das RGB-Bild eigentlich genauso aus, wie über Composite. D.h. natürlich schärfer usw.
Aber von pixelig kann ich nicht sagen.

Ich hab den Digitainer an einem kalibrierten Philips 32PF9531 hängen. Das Bild sieht nach Einmessung genauso aus, wie der DVD-Player über RGB. Selbst Overscan und Bildposition sind absolut identisch.

Oder meinst Du in dunklen Farbverläufen Abstufungen? Also kein weicher Übergang der Farbe, sondern wirkt irgendwie abgestuft? Das hatte ich nämlich. Nachdem ich im Softdevice Plugin von Farbraum i420 auf YUY2 umgestellt hatte, wars aber weg. Zumindest ist es mir bisher noch nicht wieder aufgefallen.
Für TV wäre eigentlich YV12 als Farbraum korrekt. Komischerweise ergibt das Falschfarben.

Ich hab aber gerade festgestellt, das ich mich zu früh gefreut hatte. Mit Software-Decoder geht zwar das Umschalten viel schneller und ohne Verblockung. Allerdings hat heute nach Start von VDR bis zum Bild wieder lange gedauert. Wieder etwa 10 Sekunden.
Hast Du das auch? Oder evtl. ne Idee.
Im Log find ich nur, das nach den 10 Sekunden softdevice den Videolayer ein zweites Mal konfiguriert.