[patch] RGB over VGA auf Pundit (IGP 9100) ab boot (radeonfb)

  • wie in Pundit und Tvout die xte beschrieben, kann der Pundit (Versionen mit ATI IGP9100, also z.B. Pundit ID2/3) bereits mit Bordmitteln an seinem VGA Anschluss ein PAL RGB konformes Signal erzeugen. D.h. der Pundit braucht zum Erzeugen eines RGB Signales keine FF (die sowieso kaum rein passt) mehr. Wenn also ein VDR mit blosser Wiedergabefunktion und RGB-Ausgang aufgebaut werden soll, kann dies mit dem Pundit sogar direkt, also ohne jede PCI-Zusatzkarte oder sonstige Erweiterung realisiert werden. Man benoetigt nur noch ein einfaches, rein passives (2 Widerstaende) VGA -> SCART Adapterkabel, um dann direkt ein RGB SCART faehiges Display oder Roehren-TV etc. zu betreiben. Weitere Infos im obigen Thread.


    Ein Bild war bis jetzt jedoch erst nach Start des Xservers zu sehen, da erst dieser in der Lage ist eine entsprechende Modeline umzusetzen. Der nachfolgende Patch erlaubt bereits ab Boot ein PAL RGB konformes Timing. Die Parameter fuer 'fbset' sehen so aus:

    Code
    1. fbset -g 720 576 720 576 32 -t 74074 64 16 39 5 64 5 -hsync true -vsync true -laced true


    Leider ist derzeit noch ein Patch fuer den Radeon-fbdev Treiber erforderlich (auch im aktuellen Kernel 2.6.18.3) , da dieser sonst die erforderliche Pixelfrequenz von 13.5MHz und den Composite Sync nicht akzeptiert:


    eine Utility zum Erzeugen eigener PAL konformer Modelines gibt es hier
    den Patch als File hat shh zur Verfuegung gestellt. Vielen Dank!


    [EDIT]
    hier eine Liste mit Hardware, die damit erfolgreich getestet wurde. Bitte teilt mir mit, falls eure noch nicht dabei ist, damit ich die Liste aktuell halten kann.


    Radeon 7000
    Radeon IGP 9100 (integriert)
    Radeon 9200 PRO (HIS 9250CL)
    Radeon 9200 SE
    Radeon 9600
    [/EDIT]

  • Ay caramba!


    Danke für deinen Einsatz. Das werde ich später mal testen.

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI 16.1. Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2;  DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

  • Optional:
    Damit wirklich bereits der Bootscreen auf PAL RGB laeuft, ist natuerlich ein Eintrag in der 'menu.conf' erforderlich (Beispiel):


    Code
    1. kernel /boot/vmlinuz-2.6.18.3-radeon root=/dev/hda1 ro video=radeonfb:720x576-32@50i


    Weiterhin beim Kernel '.config' (i2c hab ich mal weggelassen):


    Code
    1. CONFIG_FB_RADEON=y
    2. # CONFIG_FB_RADEON_I2C is not set
    3. # CONFIG_FB_RADEON_DEBUG is not set


    Weil das radeon-fbdev halt kein PAL kennt, wird ein weiterer Patch erforderlich:


  • Hi Hitman47,


    ja dann viel Spass beim Testen. Bei mir laeuft es jetzt einwandfrei. Vielleicht sollte man bei
    Gelegenheit noch 'ne Modeline ohne Overscan basteln... Mach' ich evtl. naechstes Wochenende.
    Nachdem wir zuerst den Xserver und jetzt den Framebuffer RGB tauglich gemacht haben, fehlt nur noch das
    BIOS.


    Frage: Laeuft das bei dir irgendwie schon ueber RGB? Eine entsprechende Option gibts ja. Scheint
    aber irgendwie ignoriert zu werden. Vielleicht muessen wir das BIOS auch noch patchen:-)


    Also ich bleibe dabei, nach diesen Modifikationen ist der Pundit fuer mich die No1 fuer VDR
    Basishardware. Soviel Funktionalitaet bei *diesen* geringen Abmessungen (nur 275x90x355)
    habe ich noch nirgends gesehen. Zu erwaehnen 2 PCI Slots in die sogar eine FF passt
    (wenn man sie jetzt noch will). Nach Lueftertausch ist das Teil auch wirklich leise.
    Leider laesst sich mit dem ASUS M2NPV-VM Motherboard kein so kleines Geraet realisieren. Sonst
    waere das vermutlich mein Favorit.


    sparkie

  • Das war ganze Arbeit! Danke, sparkie!


    Ich habe es gerade getestet und es funktioniert tadellos.
    Der Overscan stört doch etwas. Das sollte aber kein Problem sein.



    Das BIOS fehlt noch, da hast du wohl Recht.


    Ich traue mich ohne Recovery-Option nicht an diese Geschichte. Vielleicht findet sich mal jemand mit dem richtigen Equipment!?

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI 16.1. Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2;  DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von Hitman47 ()

  • Zitat

    Das war ganze Arbeit


    das freut mich! Die Idee dazu hast ja du mir gegeben (wie im obigen Thread zu lesen).


    Zitat

    Der Overscan stört doch etwas.


    mache ich naechstes Wochenende. Poste dann das Ergebnis wieder hier.


    Zitat

    Ich traue mich ohne Recovery-Option nicht an diese Geschichte.


    nun ja - man kann den Pundit ja direkt von einer selbstgebrannten CD flashen - ohne DOS, Windows
    oder anderen Kram. Aber ich im BIOS kenn' ich mich fuer einen Fix nicht wirklich gut aus:-)

  • nachdem ich nix Adaequates im Internet gefunden habe, habe ich jetzt eine kleine Utility geschrieben, die das Herausfinden von PAL kompatiblen Parametern fuer 'xorg.conf' oder 'fbset' erleichtern soll. Folgendes leistet das kleine Script:


    - beliebige Aufloesung waehlbar
    - eine Zentrierung horizontal und vertikal ist vorgesehen
    - der Overscan kann horizontal und vertikal beliebig konfiguriert werden
    - es werden nur PAL kompatible Parameter (50Hz, 15.625 kHz) erzeugt.


    Die erzeugten Timings sind direkt verwendbar fuer Fernseher mit Kathodenstrahl-Bildroehren und RGB SCART Anschluss. Also praktisch alle (auch vorsintflutlichen) Modelle. Der Fernseher kann also (eine entsprechende Grafikkarte vorausgesetzt) direkt als Ausgabegeraet fuer Xserver und Framebuffer Device dienen. Optimal in Kombination mit xine/xineliboutput/softdevice und anderen Softdecodern! Wenn genug Daten von verschiedenen Benutzern gesammelt wurden, folgt noch eine Liste mit kompatiblen Grafikkarten (hauptsaechlich ATI und MATROX). Da geeignete Karten in der Bucht nur noch ein paar Euro kosten, ergibt sich eine sehr kostenguenstige Alternative fuer eine FF ohne auf einen vollwertigen RGB Anschluss verzichten zu muessen.


    sorry, momentan ist alles ein wenig verstreut hier. Eine Anleitung, wie man mit dem Script schrittweise die optimalen Parameter ermittelt befindet sich in diesem Post:


    Anleitung


    Interessantes zum Thema gibts auch hier (herzlichen Dank an nordlicht fuer die Zusammenfassung)


    VGA-to-SCART-Adapter mit/für ATI-Radeon-Grafikkarten
    und
    VGA-to-SCART-Adapter an Fernseher - suche Erfahrungsberichte

  • Hier noch ein paar Parameterbeispiele fuer X und fbdev, die ich mit obigem 'pal_modeline.sh' ermittelt habe. Sie sind zwar auf mein altes TV-Roehren-Geraet hin optimiert. Als Ausgangsbasis fuer die Optimierung auf andere Geraete sind sie aber sicher auch ganz gut brauchbar.



    Aufloesung 720 x 576 mit Overscan (fuer Bilddarstellung):


    Modeline "720x576i" 13.5 720 736 800 864 576 581 586 625 Composite interlace
    fbset -g 720 576 720 576 32 -t 74074 64 16 39 5 64 5 -hsync true -vsync true -laced true



    Aufloesung 720 x 520 ohne Overscan (fuer Textdarstellung):


    Modeline "720x520i" 15 720 784 856 960 520 548 553 625 Composite interlace
    fbset -g 720 520 720 520 32 -t 66666 104 64 72 28 72 5 -hsync true -vsync true -laced true



    Aufloesung 800 x 520 ohne Overscan (fuer Textdarstellung):


    Modeline "800x520i" 17 800 864 944 1088 520 548 553 625 Composite interlace
    fbset -g 800 520 800 520 32 -t 58823 144 64 72 28 80 5 -hsync true -vsync true -laced true

  • die 800x520 Aufloesung fuer Textdarstellung (ohne Overscan) hat sich inzwischen bei 4 ganz unterschiedlichen Roehren-TV Fabrikaten bewaehrt. Deswegen habe ich sie jetzt in den Patch uebernommen.


    Beispiele fuer menu.lst:

    Code
    1. #kernel /boot/vmlinuz-2.6.18.3-radeon root=/dev/hda1 ro video=radeonfb:720x576-32@50i
    2. # oder alternativ
    3. kernel /boot/vmlinuz-2.6.18.3-radeon root=/dev/hda1 ro video=radeonfb:800x520-32@50i


    der erweiterte Patch sieht dann so aus:


  • Hallo,


    ich habs mit dem Kernelpatchen noch nicht so ganz rauß. Könnt Ihr mir bitte mal helfen? Habde den Kernel linux-2.6.18.3 runtergeladen und wollte ihn mit dem ersten Patch hier ganz oben patchen. Klappt aber leider nicht:


    easyVDR:/usr/src/linux-2.6.18.3/drivers/video/aty# dir
    ati_ids.h atyfb.h mach64_cursor.c radeon_accel.c radeon_base.c.diff radeonfb.h radeon_pm.c
    aty128fb.c mach64_accel.c mach64_gx.c radeon_backlight.c radeon_base.c.orig radeon_i2c.c
    atyfb_base.c mach64_ct.c Makefile radeon_base.c radeon_base.c.rej radeon_monitor.c
    easyVDR:/usr/src/linux-2.6.18.3/drivers/video/aty# patch -i radeon_base.c.diff
    (Stripping trailing CRs from patch.)
    patching file radeon_base.c
    Hunk #1 FAILED at 683.
    Hunk #2 FAILED at 1663.
    2 out of 2 hunks FAILED -- saving rejects to file radeon_base.c.rej
    easyVDR:/usr/src/linux-2.6.18.3/drivers/video/aty#


    Was mache ich denn da falsch?



    Grüße
    Dr Jones

  • ...so ich bin auch wieder zurueck.


    Zitat

    Original von Dr Jones
    Was mache ich denn da falsch?


    vielleicht ein Problem mit Whitespaces? Das 'Stripping trailing CRs' deutet ja auch darauf hin,
    dass beim Uebertragen der Patches was schief gelaufen ist. Aber diese paar Zeilen kann man ja eh
    manuell mit Editor (also ohne patch) einfuegen :]

  • Hi All.
    I have problems with interlaced modes via Xineliboutput:DirectFB(bottom half screen is black), via Xineliboutput:FB picture normal(but cpu usage high).
    Non interlaced modes, like 720x288 looks ok via DirectFB, but out of visible range on TV screen. Any suggestions?


    Thank you.


    P.S. I don't speak German, Only English a little.

  • Hi SergArb


    Zitat

    I have problems with interlaced modes via Xineliboutput


    probably this is not the right thread to answer this.
    a few questions: what is your graphics hardware? what frame buffer driver do you use and what parameters do you specify to activate it?


    sparkie

  • Zitat

    Originally posted by sparkie
    Hi SergArb


    probably this is not the right thread to answer this.
    a few questions: what is your graphics hardware? what frame buffer driver do you use and what parameters do you specify to activate it?
    sparkie


    I tried with Radeon9200SE and Radeon7000. Framebuffer is patched radeonfb for RGB over VGA, in grub i set video=radeonfb:720x576-32@50i - works fine on TV :) But have this problem only via DirectFB output.


    Best regards.

  • Zitat

    works fine on TV


    nice to know that it works for Radeon9200SE and Radeon7000 also:-)


    Zitat

    Non interlaced modes, like 720x288 looks ok via DirectFB, but out of visible range on TV screen


    how did you verify it looks ok in that case? Did you connect a VGA monitor?


    Zitat

    via Xineliboutput: DirectFB(bottom half screen is black)


    I have no clue what's going on here. Unfortunately I haven't tried DirectFB yet. I only used Xserver's XV-extension to get at hardware accelerated scaling and other functions. XV does not show the 'bottom half' symptom.


    It indeed appears that DirectFB has some problems with interlaced modes. Programming the CRT controller for interlaced mode does not affect the way pixels are organized in graphics memory. I think interlaced mode should be completely transparent (but obviously is not?) to any application inluding DirectFB.


    how exactly does it look like? Is it stretched, compressed, are pixels on bottom half (i.e. from middle of screen to bottom) simply cut away? Other graphic applications are running fine under same conditions?


    I know about many reports in the net where people complain about missing top/upper half problems with radeon chips. Maybe DirectFB tries to compensate for that leading to the effect you describe.


  • It's cuted from midle to bottom. I don't know other app with directfb(i use only VDR).
    If only radeonfb used, without DirectFB, picture not cuted. Seem's it's DirectFB "feature" :( I tryed DirectFB 0.9.25 and 1.0.0-RC2 - both give that bug :(
    Anyone else tryed it?

  • Zitat

    Originally posted by sparkie
    you could run DirecFB over softdevice instead of xineliboutput. Maybe it's a bug in DirecFB triggered by a special behavior of xinelib.


    With softdevice same things :( Only none interlaced mode, like "720x288pal", fully viewable, but have "horizontal scan lines" :(

  • Zitat

    Originally posted by sparkie
    sounds not good. I can't believe that interlaced timings on radeons don't work with DirecFB. Maybe you try DirecFB Mailing Lists or as a last resort we fix it ourselves :]


    I have searched in DirecFB Mailing Lists and not found anything about interlaced modes and radeon :( It will be great, if we can fix it ourselves :)