i810 + xineliboutput: Nur halbes Bild zu sehen

  • Hallo,


    ich versuche im Moment, per VGA-zu-Scart einen normalen alten Fernseher zum Laufen zu bekommen. Das Board hat eine Intel-82815 Onbord-Grafik, die mit X11 eigentlich zufriedenstellend im 720x576-interlaced-Modus funktioniert. Zumindest wird der leere X11-Desktop und eine Uhr mit
    "xclock -geometry 720x576+0+0" korrekt und bildschirmfüllend auf dem Fernseher dargestellt.


    Starte ich jedoch vdr-sxfe zur Anzeige der VDR-Ausage, sehe ich leider nur die obere Hälfte des Bildes. Hat jemand eine Idee, woran das liegen kann? vdr-sxfe habe ich sowohl komplett ohne parameter als auch mit "vdr-sxfe --aspect 4:3 --width=720 --height=576 --noscaling --verbose" gestartet, kein sichtbarer Unterschied.


    Hier ist noch der verwendete Bildschirmmodus dazu:

    Code
    (**) I810(0):  Mode "720x576@25i": 13.5 MHz, 15.6 kHz, 49.9 Hz (I)
    (II) I810(0): Modeline "720x576@25i"   13.50  720 732 795 864  576 581 586 625 interlace -hsync -vsync


    Grüße,
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

    2 Mal editiert, zuletzt von hsteinhaus ()

  • vermutlich ein Bug in der Implementierung der XV Extension. Da wird die Verdoppelung/Halbierung der Zeilenzahl wegen Interlaced nicht richtig beruecksichtigt. Du kannst mal testweise vielleicht versuchen, mit den Deinterlace Optionen zu spielen, um den Fehler einzugrenzen.


    Moeglicherweise ist der Bug nur auf ein bestimmtes Pixelformat begrenzt. Dieses aendert sich abhaengig von den Deinterlace Optionen. So aehnliche Probleme gibt's auch mit den Radeons und DirectFB, siehe dieser Post

  • Ich habe einfach mal angenommen, dass du den Deinterlacer aktiviert hast. Eigentlich sollte das bei PAL RGB Ausgabe nicht erforderlich sein. Vorausgesetzt, die Grafik unterstuetzt den Sync auf die Fields (50Hz).


    eine Frage haette ich jetzt doch:
    Hast du es geschafft komplett ohne Deinterlacer zu arbeiten? Ich versuche das gerade mit nVidia Boards. Das waere dann wirlich die perfekte Ausgabemethode fuer Roehren-TVs.

  • Hallo,


    Zitat


    vermutlich ein Bug in der Implementierung der XV Extension.


    Ja, zu der Einsicht bin ich inzwischen auch gelangt. Mit XShm tritt der Fehler nämlich nicht auf, das Bild ist hier komplett. Wenn man genau hinsieht, ist da Bild nicht nur halbiert, sondern auch verschoben. Ich werde mal mit fbfe gegentesten.


    Zitat


    eine Frage haette ich jetzt doch:
    Hast du es geschafft komplett ohne Deinterlacer zu arbeiten? Ich versuche das gerade mit nVidia Boards. Das waere dann wirlich die perfekte Ausgabemethode fuer Roehren-TVs.


    Das ist auf jeden Fall mein Ziel, denn alles andere wäre für einen 50HZ-TV wirklich ziemlich sinnlos.


    Grüße,
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

  • Zitat

    Das gleiche Problem hatte ich auch schon mit i810fb, xineliboutput und DirectFB.


    das


    Code
    video.device.directfb_layer_id:0


    schon mal probiert? Siehe hier


    bei Softdevice und halben Bildern mit interlaced Video Output am VGA-Port scheint dies


    Code
    Pixel Format: YUY2
    Use StretchBlit: on


    Wunder zu wirken. Siehe hier

  • Zitat

    Originally posted by hsteinhaus


    Das ist auf jeden Fall mein Ziel, denn alles andere wäre für einen 50HZ-TV wirklich ziemlich sinnlos.


    einen (interlaced) 50HZ-TV ohne vorheriges Deinterlacing ueber die Xv Extension zu betreiben, ist nicht ganz einfach.


    Ich habe mir fuer Radeon und nVidia Chipsets hierzu ein VGA->SCART Kabel gebaut. In beiden Faellen habe ich eine interlaced Modeline erfolgreich am laufen. Ein tadelloses Bild (bei statischen Inhalten) ist auf diese Weise ueber den X-Server realisierbar.


    Probleme gibt es, wenn dynamische Inhalte ins Spiel kommen, d.h. wenn (De)Interlacing eine Rolle spielt.


    Das Problem, das ich hier habe ist, dass die Xv Extension Spezifikation offenbar keinen Field-Sync beinhaltet. D.h. wenn irgendwann mal ein Halbbild gedroppt wurde, werden alle Fields bis zum naechsten Drop vertauscht wiedergegeben.


    Das kann aber nicht so schwierig zu fixen sein. Da werde ich mich als naechstes dranmachen.

  • Zitat

    ich versuche im Moment, per VGA-zu-Scart einen normalen alten Fernseher zum Laufen zu bekommen. Das Board hat eine Intel-82815 Onbord-Grafik, die mit X11 eigentlich zufriedenstellend im 720x576-interlaced-Modus funktioniert. Zumindest wird der leere X11-Desktop und eine Uhr mit


    Darf ich fragen mit welchem XServer der Interlaced Modus auf dem i815
    funktioniert?
    Mein XServer (xorg/debian etch) weigert sich nämlich, die Option interlace
    in einer Modeline zu akzeptieren. (mit einer Matrox Mystique funktionierts)

  • Hallo herm,


    ich habe dazu einen minimal modifizierten xserver-xorg-video-i810 1.7.2-4 benutzt. Die Modifikation besteht in zwei gefühlvoll plazierten Kommentarzeichen, die die Funktion I810ValidMode() in i810_driver.c dazu überreden, nicht über Interlaced-Modi zu meckern.


    Leider habe ich inzwischen schon festgestellt, dass die xv-Implementierung offenbar wirklich nichts von Interlaced-Modi weiß. Ich habe meine Versuche in dieser Richtung erst mal aufgegeben und eine alte DXR3 wiederbelebt.


    Funktioniert denn mit der Matrox die Interlaced-Ausgabe mit xv? Eventuell kann man an einem langen Winterabend ja da mal spionieren und den Inteltreiber etwas erweitern...


    Grüße,
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

    2 Mal editiert, zuletzt von hsteinhaus ()

  • Zitat

    Funktioniert denn mit der Matrox die Interlaced-Ausgabe mit xv?


    ueber Matrox kann ich nichts sagen. Aber wie oben schon erwaehnt, VGA->SCART laeuft hier mit Radeon und nVidia ueber XV.
    Das 'einzige' Problem ist, dass ich im Moment in beiden Faellen deinterlacen muss, weil XV offenbar keine Odd/Even Fields unterscheidet.


    Wenn dieses Problem geloest werden kann, haetten wir einen vielseitig verwendbaren RGB Output realisierbar mit den meistverwendetsten Grafikkarten.


    Da kann man im Vergleich jeden TV-OUT ueber Composite qualitativ vergessen.


    Ich habe bei abgeschaltetem Deinterlacer in dieser Konstellation bereits jetzt ca. 1Minute lang ein perfekt interlactes Bild am Roehren-TV. Danach sind fuer eine weitere Minute die Fields vertauscht. Um anschliessend wieder fuer 1 Minute korrekt zu laufen.


    Ein 2GHz Celeron D idled mit 80%, wenn er nur dekodieren aber nicht deinterlacen muss. Ich bin begeistert.

  • Hallo,


    Zitat

    Original von hsteinhaus
    Funktioniert denn mit der Matrox die Interlaced-Ausgabe mit xv? Eventuell kann man an einem langen Winterabend ja da mal spionieren und den Inteltreiber etwas erweitern...


    Ich habe diese Änderung mal eingebaut und übersetzt. Ich werde das heute abend mal testen. Die Interlaced-Ausgabe mit xv werde ich auf einer Matrox G400 ebenfalls ausprobieren. Wenn das klappt, müsste man doch einige Sachen übernehmen können. Es scheint ja im wesentlichen darum zu gehen, daß im Interlaced-Modus durch die Halbbild-Darstellung der Bildschirmmodus nur noch 288 Zeilen hoch ist.
    Wär ja zu schön, Videoausgabe oder Streaming ohne zusätzliche Karten auf dem Mainboard.

  • Zitat

    Original von hsteinhaus


    ich habe dazu einen minimal modifizierten xserver-xorg-video-i810 1.7.2-4 benutzt. Die Modifikation besteht in zwei gefühlvoll plazierten Kommentarzeichen, die die Funktion I810ValidMode() in i810_driver.c dazu überreden, nicht über Interlaced-Modi zu meckern.


    Im i810fb Treiber gab es ein ähnliches Problem, dort war der Minimalwert für die Dotclock zu hoch gesetzt. Passt man diesen an, ist Interlaced möglich und der Mode wird trotzdem weiterhin validiert.

  • den i810 habe ich mir jetzt mal genauer angesehen. Es ist so, dass xf86-video-intel offiziell gar keinen Interlaced-Modus unterstuetzt. Ich habe inzwischen die erforderlichen Teile im Xserver nachimplementiert. Im Wesentlichen muss man den Chip im Field- statt im Frame-Modus betreiben. Leider muss hierzu auch noch das zugehoerige i810-DRM Modul um eine Interruptroutine und anderes erweitert werden. Falls Interesse besteht, kann ich die Patches mal zusammenfassen und zugaenglich machen.


    - sparkie

  • Hallo!
    Ich wäre daran interessiert!
    Ich habe den Xserver auch soweit modifiziert, daß er interlaced-Darstellung akzeptiert. Ich bin dann aber bei xvideo im Fieldmodus hängen geblieben.


    Hast Du wirklich die Image-Übergabe (putImage? Ist schon länger her...) auf Interrupts umgestellt? Bisher scheint das ja im Frame-Modus mit Polling auf vsync passiert zu sein.


    Also, immer her damit :)

  • Hi,


    Zitat

    Originally posted by herm
    Ich habe den Xserver auch soweit modifiziert, daß er interlaced-Darstellung akzeptiert. Ich bin dann aber bei xvideo im Fieldmodus hängen geblieben.


    ja das ist ein eigenartiges Zeug.


    Zitat

    Hast Du wirklich die Image-Übergabe (putImage? Ist schon länger her...) auf Interrupts umgestellt? Bisher scheint das ja im Frame-Modus mit Polling auf vsync passiert zu sein.


    sagen wir mal so: ich habe bislang nicht herausgefunden, wie ich alleine anhand der Register zu beliebigen Zeitpunkten bestimmen kann, welches Field vom CRT Controller gerade ausgegeben wird. Ich meine hierbei also _nicht_ das Field, das per DOV0STA programmiert wird.


    Da ich aber fuer meinen vga-sync-fields Patch sowieso einen Interrupt brauche, habe ich da die fehlende Funktion einfach nachgebildet.


    Vielleicht faellt dir aber was einfacheres dazu ein? Das wuerde mich dann auch sehr interessieren.


    Ich habe die Vorab-Patches (noch ohne DRM Erweiterung) mal hier hinterlegt. Sie sind alleine schon ablauffaehig. Im Moment schaut's in meinem DRM naemlich aus wie Kraut und Rueben:)


    Das DRM reiche ich am Wochenende im ZUge der naechsten vga-sync-fields Release nach. Da ich mit vga-sync-fields in Zukunft auch den i810 unterstuetzen moechte. Waere doch recht nuetzlich fuer die S100:)


    - sparkie

  • Moin,

    Zitat

    sagen wir mal so: ich habe bislang nicht herausgefunden, wie ich alleine anhand der Register zu beliebigen Zeitpunkten bestimmen kann, welches Field vom CRT Controller gerade ausgegeben wird. Ich meine hierbei also _nicht_ das Field, das per DOV0STA programmiert wird.


    Ich kann zwar nicht aus dem Kopf sagen welches Register das war (ist schon ein paar Monate her), werde es am Wochenende aber mal raussuchen. Ich bin von der anderen Seite gekommen. Der Field-Kram im i810 war klar, aber ich habe nicht gefunden wie der mplayer die Bilder fieldweise übergeben könnte. Meine provisorische Lösung war, daß mplayer das wie bisher das ganze Frame übergibt, der Xserver wartet bis vsync, dann flip auf field 0, warten auf vsync, flip auf field 1, dann kopieren des neuen Frames. Ist natürlich ein Performancefresser, wird aber bei normalem XVideo auf i810 auch so gemacht. Deshalb erzeugt die Ausgabe über xv genauso hohe Rechenlast wie Ausgabe über xshm. Im Datenblatt wird vorgeschlagen, einen Interrupt auf die letzte Bildzeile zu setzen. Wird sowas im DRM gemacht? Muss mir mal ein bischen Background anlesen...
    Der S100 wird das wohl nicht helfen, da dort der i830 verbaut ist. In dem ist die Ausgabe anders aufgebaut. xv-Ausgabe funktioniert da vernünftig mit 15% Auslastung, aber auch nur frameweise. Der FS454 pflückt dann die fields auseinander. Da in XVideo die Frames nicht immer auf jedes 2. Bild synchronisiert, sondern ab und zu 1 oder 3 (Das war ja glaub ich der Grund für deinen Framerate-Patch) kommt der FS454 ausser Tritt und es ruckelt.
    Was noch viel mehr bei der S100 stört ist der begrenzte Farbraum (Darstellung über SCART sieht aus wie 16Bit). Das Interlaced-Bild über VGA ist perfekt, ist aber nur frame- und nicht fieldsynchronisiert.
    Wie gesagt, ich schaus mir noch mal an und schreib dann Sonntag etwas weniger konfus :)

  • Hi,


    Zitat

    Originally posted by herm
    Moin,


    Ich kann zwar nicht aus dem Kopf sagen welches Register das war (ist schon ein paar Monate her), werde es am Wochenende aber mal raussuchen.


    inzwischen habe ich sogar eine Moeglichkeit gefunden:


    Der DISP_SL zaehlt abhaengig vom Field auf unterschiedliche Maximalwerte hoch. Hieraus kann man also indirekt das Field ableiten. Das scheint zu funken. Ist aber natuerlich immer noch umstaendlich.


    Zitat

    lip auf field 0, warten auf vsync, flip auf field 1, dann kopieren des neuen Frames. Ist natürlich ein Performancefresser, wird aber bei normalem XVideo auf i810 auch so gemacht.


    fue solche Faelle habe ich mir einen ioctl() ins DRM gebastelt. Der zumindest den Busywait ueberfluessig macht. Der Xserver geht in den ioctl() und wacht auf wenn die SYNC Bedingung erfuellt ist.
    Eine Alternative ist, das 2. Field direkt (also ohne Xserver) aus dem DRM heraus zu triggern. Dann braucht der Xserver auf nix zu warten.


    Zitat


    Deshalb erzeugt die Ausgabe über xv genauso hohe Rechenlast wie Ausgabe über xshm. Im Datenblatt wird vorgeschlagen, einen Interrupt auf die letzte Bildzeile zu setzen. Wird sowas im DRM gemacht? Muss mir mal ein bischen Background anlesen...


    damit faellt natuerlich die hohe Rechenlast komplett weg. Richtig, man kann das aus dem DRM heraus machen, wenn man es erst implementiert:-) Das DRM des i810 von Haus aus bietet nur wenig Brauchbares.


    Zitat


    Der S100 wird das wohl nicht helfen, da dort der i830 verbaut ist. In dem ist die Ausgabe anders aufgebaut. xv-Ausgabe funktioniert da vernünftig mit 15% Auslastung, aber auch nur frameweise.


    hier wird es super interessant! Hast du Specs vom i830? Wenn ich in die Xserver Sourcen gehe, ist ja dort auch von Fields die Rede. Der Registeraufbau ist dem i810 nicht unaehnlich.


    Zitat


    Der FS454 pflückt dann die fields auseinander. Da in XVideo die Frames nicht immer auf jedes 2. Bild synchronisiert, sondern ab und zu 1 oder 3 (Das war ja glaub ich der Grund für deinen Framerate-Patch) kommt der FS454 ausser Tritt und es ruckelt.


    mit dem FS454 kenne ich mich leider nicht aus. Aber der sollte auch komplett ueberfluessig werden.
    Es gibt auf der Xorg ML Leute, die den i830 interlaced spielen. Dann schaffen wir das auch:)


    Zitat


    Was noch viel mehr bei der S100 stört ist der begrenzte Farbraum (Darstellung über SCART sieht aus wie 16Bit). Das Interlaced-Bild über VGA ist perfekt, ist aber nur frame- und nicht fieldsynchronisiert.


    das liegt sicher am FS454. Und den wollen wir eh nicht.


    Zitat


    Wie gesagt, ich schaus mir noch mal an und schreib dann Sonntag etwas weniger konfus :)


    nein, das ist hervorragend, dass du hier schon Erfahrung hast. Ich bin erst seit ein paar Tagen mit dem i810 dabei. Dann freu ich mich schon auf den Sonntag!


    - sparkie

  • Moin,


    Zitat

    sagen wir mal so: ich habe bislang nicht herausgefunden, wie ich alleine anhand der Register zu beliebigen Zeitpunkten bestimmen kann, welches Field vom CRT Controller gerade ausgegeben wird. Ich meine hierbei also _nicht_ das Field, das per DOV0STA programmiert wird.


    Das hast Du glaub ich falsch verstanden. DOV0STA ist ein Statusregister, und damit read-only. Bit 20 gibt an, welcher Buffer gerade angezeigt wird. Bit 19 gibt an, welches Field angezeigt wird (natürlich nur wenn field-mode eingestellt ist). Geschrieben werden die wichtigsten Sachen in OV0CMD.
    Hier mal die wichtigen Stellen in i810_video.c. Hier wird in der Funktion I810PutImage darauf gewartet, daß der Buffer der gefüllt werden soll nicht mehr angezeigt wird. Hier wird bis jetzt nur Bit 20 von DOV0STA ausgewertet.



    Wenn der andere Buffer angezeigt wird, wird das Image in den freien Buffer kopiert, auf den nächsten Bildwechsel gewartet und dann der Buffer auf das aktuelle Bild umgeschaltet:


    Code
    overlay->OV0CMD &= ~BUFFER_AND_FIELD;
        if (pPriv->currentBuf == 0)
            overlay->OV0CMD |= BUFFER0_FIELD0;
        else
            overlay->OV0CMD |= BUFFER1_FIELD0;
    
    
        OVERLAY_UPDATE(pI810->OverlayPhysical);


    Zitat

    hier wird es super interessant! Hast du Specs vom i830? Wenn ich in die Xserver Sourcen gehe, ist ja dort auch von Fields die Rede. Der Registeraufbau ist dem i810 nicht unaehnlich.


    Ich habe das Datasheet vom i830. War im Netz nur indirekt zu finden. Soll ichs zumailen (2Mb)?
    Der i830 ist ähnlich zum i810, ist aber um einige Features erweitert worden. Er hat glaub ich mehrere Overlaybereiche und kann Textured Video. Das macht das ganze aber noch deutlich unübersichtlicher. Wir sollten zuerst den i810 zum Laufen bringen :)
    Ich habe übrigens zum Testen eine Scovery XS (i815), Compaq Deskpro EN (i815) ein No-Name i810-Board und eine S100 (i830). Wär schon Klasse wenn man damit eine 100%-Scart-Ausgabe hinkriegen würde.
    Zu welcher Debian gehört der Xserver-i810 Version 2.3.2? Ich habe Sid drauf mit Version 1.7.2.


    Wie funktioniert das Ganze mit Interrupt? Der XServer merkt sich den zu kopierenden Speicherbereich, zieht einen Interrupt auf, der im DRM einläuft und dort wird dann der Buffer geflippt? Hört sich nach Arbeit an.
    Ich werde morgen oder übermorgen meine Änderungen mal testen und die Ergebnisse posten.


    herm

  • Woah, Herm, nach der Spec vom i830 hab ich mir schon nen Wolf gesucht. Wenn du mir die mal zukommen lassen könntest wär ich dir super dankbarst. Gern per email an hibbelharry ed gmx dot de.
    Magst das mal machen ?


    Grüz
    Hibbel

    - HTPC mit zerbasteltem Yavdr 0.6 , Origen ae X15e, MCE Remote, Asus P5N7A-VM, 1x Digibit R1, Kodi und vdr an Pana 46PZ85E
    - Diverse HTPCs im Umfeld bei Familie und Freundenm die sich vor mir fürchten, mit allen möglichen gruseligen Konfigurationen.
    Auch gern Debian, aber wehe jemand kommt mir mit Suse.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!