VIA CN700 mit Softdevide + DirectFB + viafb

    Hi Zusammen!
    Ich habe ein kleines Prob mit dem CN700er Chipsatz der auf einem Mainboard von Jetway steckt.


    Folgendes habe ich ausprobiert:


    1) RealPC/viafb Howto strikt befolgen:
    Scheitert leider bereits an dem linux-viafb Modul. Ich musste erstmal die PCI-ID (3344) von dem Chipsatz in via_fbobj.c hinzufügen, damit das Ding überhaupt erkannt wird. Abgesehen davon dass die Timings total unpräzise sind und mein TFT nix anzeigen will (nur bei manueller Anpassung der fb.modes) zeigt der Fernseher nur ein GRAUES Bild. VDR Ausgabe klappt weder mit Framebuffer noch mit DirectFB (softdevice, xineliboutput)


    2) Originaltreiber von VIA (wird auch im RealPC Thread erwähnt) mit dem Acceleration Patch (55 -> 77)
    accel.h:

    Code
    /* To be included in fb.h */
#ifndef FB_ACCEL_VIA_UNICHROME
#define FB_ACCEL_VIA_UNICHROME  77
#endif


    In diesem Fall sieht das Ganze schon etwas besser aus. Ich sehe die Konsole sowohl auf dem TFT als auch auf dem Fernseher. Wenn ich jedoch VDR starte kommt nur das OSD, aber kein Bild :(((


    Also habe ich folgendes ausprobiert:


    2.1) Mit der "primary-layer" Einstellung (directfbrc) rumspielen:


    primary-layer=0
    selber Effekt, nur OSD.


    primary-layer=1
    Es kommt ein Bild, das jedoch nur die Hälfte des Bildschirmes einnimmt und total verzerrt ist. OSD wird nicht angezeigt.



    2.2) Den Layer im DirectFB umpatchen (Quelle)
    Damit kriege ich ein Bild, das sich aber im OSD befindet! Also wenn ich das Menü aufmache sehe ich das Fernsehbild als OSD Hintergrund!?!?! Mit primary-laxer konnte ich leider keine Änderung der Situation erzwingen.



    So wie es ausschaut könnte das Ganze also mit dem Originaltreiber von VIA funzen, würde DirectFB nicht irgendwie die Layer vertauschen.


    Hier noch ein Paar Ausgaben mit dem VIA Treiber:


    fbset -i

    (habe es auch mit 720x576-50 probiert, DirectFB schaltet ja eh auf die eigene Auflösung um)


    directfbrc

    Code
    fbdev=/dev/fb0
mode=720x576
depth=32
pixelformat=ARGB
#primary-layer=1
disable-module=cle266
no-vt

    (hier habe ich auch verschiedene Auflösungen probiert, leider immer mit dem selben Ergebnis)


    VDR-Ausgabe ohne primary-layer Einstellung (nur OSD wird angezeigt)


    VDR-Log mit primary-layer=1 in directfbrc und dem verstümmelten Bild ohne OSD


    Leider sagt mir diese Fehlermeldung nichts :(


    Versionen (alle Kombinationen probiert)
    Kernel: 2.6.19.1
    GCC: 4.1.1
    VIAFB (directfb source): linux-viafb CVS 06.01.2007
    VIAFB (Original von VIA): Linux-FBDev-kernel-src_2.6.00.02a mit Patch für >2.6.18 von hier
    DirectFB: 1.0.0-rc2 und/oder CVS 06.01.2007
    DFB++: CVS 06.01.2007
    libcle266mpegdec: 0.5
    Softdevice: CVS 06.01.2007
    VDR: 1.4.4


    Also, hat jemand schon mal den CN700 Chipsatz erfolgreicht ans Laufen gekriegt? Oder hat jemand vielleicht einen Tip was ich noch ausprobieren könnte?


    Bin für jede Hilfe Dankbar!!!


    Gruß,
    Sevo


    PS: Habe 2 Screenshots mit "cat /dev/fb0 > /test.raw" gemacht und danach konvertiert. Das Bild von dem "NUR-OSD" Fall hat geklappt, aber bei dem primary-layer=1 also dem ersten Bild muss man sich die Bilder übereinandergelegt vorstellen. Beider Shots bei einer Auflösung von 720x576-60.


    PSS: Direct Framebuffer habe ich im BIOS aktiviert

    Also ich kann bestätigen, daß das, was auf älteren (CLE266) Chipsätzen von Via angeblich noch problemlos funktioniert (Video im Hintergrund, OSD im Vordergrund) auf dem CN700 definitiv nicht mehr geht.


    Mit den bisher bekannten Methoden

    • funktioniert der CLE266 Treiber von DirectFB gar nicht (stellt nichtmal /dev/fb0 bereit)
    • liefert der 2.6'er Treiber von viaarena zusammen mit DirectFB nur das OSD, aber kein TV-Bild


    Mich beschleicht das Gefühl, daß das TV Bild zwar da ist, aber aus irgendeinem Grund vom vollflächig undurchsichtigen OSD verdeckt wird.


    Vielleicht gibt es ja einen Parameter, der beim CLE266 noch egal ist, beim CN700 aber zu einem opaken OSD-Layer führt, wenn man ihn falsch setzt. Also z.B. so etwas wie (jetzt fiktiv ausgedacht):


    CLE266: Register Bla / Bit Blubb: Reserved for future use. Set to 1.
    CN700: Register Bla / Bit Blubb: Gfx layer alpha mode. 0=RGB, 1=ARGB


    Würde DirectFB das auf 0 setzen, fiele es beim CLE266 nicht auf, beim CN700 jedoch könnte es zu dem entdeckten Effekt führen.


    Nur ein Denkanstoß, aber vielleicht stimmt die Richtung ja!

    In Betrieb: Serener GD-L01 mit VIA EPIA-EN15000G (passiv / 30W Betrieb / 4W Standby), Hitachi 80GB 2.5", FF: TT-DVB-S 2.3, c't-VDR 5
    Reserve: Asus Pundit mit P4 1.6 GHz (sehr leise / 60W Betrieb), IBM 60 GB 2.5", FF: TT-DVB-S 1.6, Budget: TT-DVB-T 1.3, c't-VDR 5

    Danke erstmal für eure Antworten!


    Das mit den Layern ist echt total komisch. Mit dem Layer Patch kriege ich ja auch das Bild in den OSD Layer (Punkt 2.2). Dabei ist das Bild am besten (richtige Auflösung, Farben etc), wäre es nicht der Hintergrund vom OSD und daher von diesem beschnitten :))).


    @Morone
    Also mit dem rc1 habe ichs noch nicht probiert. Werds mal testen und berichten. Welcher Chip ist denn nun im Real-Digitainer drin? Auch CN700?


    Ach und mir ist auch noch heute Nacht aufgefallen (konnte nicht einschlafen, als die Dachrinne auf dem Dach spazieren ging ;)), dass Softdevice nicht mit der aktuellen CVS Version (18.01.2007) von DirectFB funktioniert. VDR stürzt beim Initialisieren der Layer einfach ab.


    Gruß,
    Sevo

    Hi,
    Also mit DirectFB-1.0.0-rc1 passiert das gleiche, nur OSD sichtbar wenn kein primary-layer definiert wird. Mit primary-layer=1 ähnlicher Effekt wie bereits beschireben, nur dass das Bild jetzt die richtige Größe hat. Leider aber ohne OSD und sehr pixelig.


    Log:


    Log mit primary-layer=1:


    Der Code vom unichrome Treiber unterscheidet sich auch nicht stark.


    Warum muss man eigentlich den cle266 DirectFB Treiber kompilieren, wenn dieser sowieso mit disable-module=cle266 deaktiviert wird?


    Ich habe mal probiert diese Option wegzulassen, aber außer einiger neuer Fehlermeldungen ändert sich nix, also nur OSD.


    Log mit cle266


    Hat jemand noch eine Idee?


    Gruß,
    Sevo

    Zitat

    Warum muss man eigentlich den cle266 DirectFB Treiber kompilieren, wenn dieser sowieso mit disable-module=cle266 deaktiviert wird?


    Wenn ich das richtig verstanden habe, soll das cle266 Modul nicht als Ausgabemodul verwendet werden, sondern nur zum MPEG decodieren. Die Ausgabe übernimmt das Modul viatv.


    Wenn Du das Softdevice nur mit "-vo dfb:viatv" startest, verwendet der VDR die ffmpeg Library zur Decodierung. Bei "-vo dfb:cle266:viatv" hingegen läuft die MPEG2-Decodierung über den Hardwarebeschleuniger.

    In Betrieb: Serener GD-L01 mit VIA EPIA-EN15000G (passiv / 30W Betrieb / 4W Standby), Hitachi 80GB 2.5", FF: TT-DVB-S 2.3, c't-VDR 5
    Reserve: Asus Pundit mit P4 1.6 GHz (sehr leise / 60W Betrieb), IBM 60 GB 2.5", FF: TT-DVB-S 1.6, Budget: TT-DVB-T 1.3, c't-VDR 5

    Ich habe was neues entdeckt!
    Und zwar wenn ich softdevice mit "-vo dfb:viatv" starte und dann in den Einstellungen folgendes setze:
    Pixelformat: YUY2
    StretchBit verwenden: ein


    kriege ich ein super Bild, das aber scheinbar unbeschleunigt wiedergegeben wird, da die CPU last bei 99 Prozent liegt. Das Bild hat dementsprechend kleine Aussetzer und in der Konsole kimmen immer wieder +++++ Zeichen.


    Sobald ich das OSD aufmache, wird das Bild von diesem überdeckt und ist nur im OSD Hintergrund sichtbar. Also alles um das OSD herum ist schwarz und der Teil des Bildes der sich 'hinter" dem OSD Hintergrund befindet, ist sichtbar.


    Log Sieht so aus:

    Code
    [surface capabilities] videoSurface: videoonly PixelFormat = 0x00200806
[dfb] (re)configured 0x00200806
++++++[setup-softdevice] storing data
+++++++++allocating buffer format orig->format 0
++++++++++++++++++allocating buffer format orig->format 0
++++++++++++++++allocating buffer format orig->format 0
++++++++


    Komischerweise kann ich die genannten Einstellungen von Softdevice nur ändern, wenn ich "dfb:viatv" verwende. Mit "dfb:cle266" oder "dfb:cle266:viatv" funktioniert das nicht. Die sind garnicht aktiviert, also auswählbar.


    EDIT: Da haben wir gleichzeitig geantwortet, dann ist das schon mal klar.


    Gruß,
    Sevo


    Diese Situation (Video als OSD-Hintergrund) scheint mir am vielversprechendsten, da mir das bekannt vorkommt.


    Die Inkompatibilität zwischen softdevice und DirectFB, die seit 2006-12-12 existiert, ist im CVS von softdevice nun beseitigt. In der directfbrc muß aber jetzt als Pixelformat AiRGB angegeben sein.



    Stefan Lucke

    Noch ein kleiner Nachtrag:
    Wenn der oben genannte Patch für DirectFB verwendet wird, so sollte sich der Video-Layer mit dem Namen "VIA Unichrome Video 3" melden. Diesen Namen sehe ich aber in Deinen Logs nicht. Da softdevice aber nur auf den Namen "VIA Unichrome Video" für Sonderbehandlung von VIA-Chpis reagiert, würde bei Verwendung dieses Patches diese Sonderbehandlung nicht aktiviert.


    Die VIA-Unichrome-erkennung sollte also für diesen Patch auf

    Code
    if (!strncmp (videoLayerDescription.name, "VIA Unichrome Video", 19))

    umgeändert werden (video-dfb.c: Zeile 361).


    Stefan Lucke

    Aaahhh! Klingt logisch, werde den Patch anpassen und noch MAl ausprobieren.


    Danke für den Tip!


    Nachtrag: Den Log mit dem Patch habe ich garnicht gepostet, also nicht wundern. Mit dem Patch meldet er sich wirklich mit V3. Das meinte ich mit dem Patchen. Es sollte doch reichen, die Zeile mit dem neuen Namen aus dem Patch rauszunehmen. Oder?


    Gruß,
    Sevo

    Hhm,
    das ist ja blöd. Ohne Hardwaredecoder läuft es ja ansatzweise wenn ich "-vo dfb:viatv" verwende, aber das Bild ruckelt sehr stark, weil die CPU damit nicht klarkommt. Komischerweise funktioniert "-vo dfb:fb" also ohne DirectFB dann sogar besser. Ich kriege mit Framebuffer sogar ein flüssiges Bild bei ca. 95% CPU Last. Ist ein C7 1200 Mhz. Das einzige was da besser werden könnte, wäre die OSD Ausgabe, was aber dann eh egal ist.


    Ist das überhaupt nicht möglich (technisch gesehen) bei diesem Chipsatz die Beschleunigung zu aktivieren? Oder ist das einfach zu neu? Ich würde mich auch zum Testen missbrauchen lassen. Beim Coden bin ich aber leider ne Niete, sonst würde ich mich selber rantrauen :((


    Gruß,
    Sevo

    So, habe jetzt mal DirectFB und Softdevice auf den aktuellen CVS Stand (21.01.07) gebracht und die Patches angewandt.


    Und es läuft FAST! OSD und Bild sind da und flüssig! CPU Last liegt bei 54% (also doch mit ner gewissen Beschleunigung ??)


    Beim Bild gibt es jedoch noch ein kleines Problem, und zwar ists verschoben und die Farben stimmen nicht. Ich habe mal ein Foto gemacht und drangehängt (cat /dev/fb0 liefert komischerweise nur das OSD). Dazu kommt dass der partout kein Bild auf dem Fernseher anzeigen will. Nur das OSD. Egal ob ich cle266:viatv, viatv, oder cle266 als Parameter übergebe. Das Bild kommt nur auf dem Monitor/TFT.


    [Blockierte Grafik: http://www.sevo.org/screenshot-dfb.jpg]


    So sieht der Log aus:


    Gruß,
    Sevo

    Zitat

    Original von Sevo
    Hhm,
    das ist ja blöd. Ohne Hardwaredecoder läuft es ja ansatzweise wenn ich "-vo dfb:viatv" verwende, aber das Bild ruckelt sehr stark, weil die CPU damit nicht klarkommt. Komischerweise funktioniert "-vo dfb:fb" also ohne DirectFB dann sogar besser. Ich kriege mit Framebuffer sogar ein flüssiges Bild bei ca. 95% CPU Last. Ist ein C7 1200 Mhz. Das einzige was da besser werden könnte, wäre die OSD Ausgabe, was aber dann eh egal ist.


    Bei mir hab ich mit einem VIA Nehemiah 1000 MHz bei der Verwendung von YUY2 eine CPU-Last von ca. 60% . Das ist allerdings VGA out .


    Zitat

    Ist das überhaupt nicht möglich (technisch gesehen) bei diesem Chipsatz die Beschleunigung zu aktivieren? Oder ist das einfach zu neu?


    Die Hardwaredekodierung ist über die externe Lib libcle266mpegdec gemacht und die liefert nur I420/YV12 , sprich ich weiß nicht was es da noch für Möglichkeiten gibt.


    Um die Verschiebung und die falschen Farben kümmer ich mich anschließend.


    Stefan Lucke

    Hi,

    Zitat

    Original von stl
    Bei mir hab ich mit einem VIA Nehemiah 1000 MHz bei der Verwendung von YUY2 eine CPU-Last von ca. 60% . Das ist allerdings VGA out .


    Jep, 50-54% beim C7! Reicht mir vollkommen für den Anfang. Wär türlich cool wenns auch noch mit TV Out gehen würde (träum) :)


    Zitat

    Um die Verschiebung und die falschen Farben kümmer ich mich anschließend.


    Das wär echt toll! Freu mich schon drauf!


    Gruß,
    Sevo

    Zitat

    Original von Sevo
    Hi,


    Jep, 50-54% beim C7! Reicht mir vollkommen für den Anfang. Wär türlich cool wenns auch noch mit TV Out gehen würde (träum) :)


    Zu TV-out war auf der directfb-user Liste am 4.7.2006 zu lesen, daß da ein Video-Encoder für TV-out nicht unterstützt wird :( .
    http://mail.directfb.org/piper…ers/2006-July/001961.html


    Zitat


    Das wär echt toll! Freu mich schon drauf!


    Da hab ich zu viel erwartet :( . Wenn ich den besagten Patch bei mir verwende, so hab ich zwar ein OSD in den richtigen Farben, aber die Videofläche ist konstant in Rosa (dabei hab ich keine Brille auf).


    Stefan Lucke

    Hallo stl,


    gehört zwar nicht hierein, aber eine kleine Frage sei gestattet hoffe ich.


    Ich betreibe seit gestern einen cle266mpegdec mit neuesten Versionen von gestern von DFB++-CVS, DirectFB-CVS und Softdevice-CVS. MeinProblem ist jetzt, das er alle 10 Minuten den Screen (Layer1) abschaltet, also schwarz wird. Ein Druck auf die Tastatur bringt das Bild auf den LCD (Anschluß über VGA) zurück.


    Trieiber für die Graka ist viafb_1.2


    Was läuft da falsch, oder wie kann ich das Fehl-Verhalten beheben?


    Mit jeweiligen Versionen vom 05.Dezember.2006 war dieses Verhalten nicht!


    Gruß
    Wolfgang

    Zitat

    Original von stlZu TV-out war auf der directfb-user Liste am 4.7.2006 zu lesen, daß da ein Video-Encoder für TV-out nicht unterstützt wird :( .
    http://mail.directfb.org/piper…ers/2006-July/001961.html


    Hhm, da gehts aber doch um den "viafb" Treiber von Directfb, also das Kernel-Modul (nicht den DirectFB Unichrome Treiber). Ich verwende aber den "viafb" Originaltreiber von VIA. Die DirectFB Version tut bei mir ja nicht (siehe Anfangspost bei Punkt 1)


    Zitat


    Da hab ich zu viel erwartet :( . Wenn ich den besagten Patch bei mir verwende, so hab ich zwar ein OSD in den richtigen Farben, aber die Videofläche ist konstant in Rosa (dabei hab ich keine Brille auf).


    So meinte ich das auch. OSD ist völlig OK und an der richtigen Position. Der scheint beim Video LAyer irgendwas flasch zu machen. Aber es geht ja schon in die richtige Richtung, vorher ging ja garnichts.


    Gruß,
    Sevo


    Bin mir keiner Änderung bewußt, die das verursachen könnte.
    Ist bei Dir fbcon geladen und der "normale" VGA screensaver aktiv ?


    Stefan Lucke

    Hallo Lucke,


    danke für deine schnelle Antwort.


    Ich habe das hier in der Runvdr drin:


    setterm -clear -powersave off -powerdown -cursor off -store > /dev/tty$VDRTTY
    setterm -clear -powersave off -powerdown -cursor off -store > /dev/tty$STARTKONSOLE


    und das geht mit der älteren Version.


    fbcon ist nicht geladen. Da das Modul nicht existiert.


    Gruß
    Wolfgang

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden