[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:

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:

diff -ur linux-2.6.18.3.org/drivers/video/aty/radeon_base.c linux-2.6.18.3/drivers/video/aty/radeon_base.c
--- linux-2.6.18.3.org/drivers/video/aty/radeon_base.c 2006-08-23 23:16:33.000000000 +0200
+++ linux-2.6.18.3/drivers/video/aty/radeon_base.c     2006-12-11 22:11:56.000000000 +0100
@@ -683,6 +683,9 @@
                rinfo->pll.ppll_max     = BIOS_IN32(pll_info_block + 0x16);
 
                printk(KERN_INFO "radeonfb: Retrieved PLL infos from BIOS\n");
+printk(KERN_INFO "radeonfb: disregarding BIOS ppll_min of %d\n", rinfo->pll.ppll_min);
+rinfo->pll.ppll_min = 12000;
+printk(KERN_INFO "radeonfb: using ppll_min of %d instead\n", rinfo->pll.ppll_min);
                goto found;
        }
 
@@ -1660,6 +1663,13 @@
                                        CRTC_CRT_ON;
        }
 
+/*printk(KERN_INFO "radeonfb: vmode requested 0x%x\n", mode->vmode);*/
+#define CRTC_CSYNC_EN (1 << 4)
+if (mode->vmode & FB_VMODE_INTERLACED) {
+    newmode->crtc_gen_cntl |= CRTC_INTERLACE_EN | CRTC_CSYNC_EN;
+}
+/*printk(KERN_INFO "radeonfb: crtc_gen_cntl 0x%x\n", newmode->crtc_gen_cntl);*/
+
        newmode->dac_cntl = /* INREG(DAC_CNTL) | */ DAC_MASK_ALL | DAC_VGA_ADR_EN |
                           DAC_8BIT_EN;

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]

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

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):

CONFIG_FB_RADEON=y
# CONFIG_FB_RADEON_I2C is not set
# CONFIG_FB_RADEON_DEBUG is not set

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

--- /usr/src/REMOVE_ME/linux-2.6.18.3/drivers/video/modedb.c   2006-08-23 23:16:33.000000000 +0200
+++ ./modedb.c  2006-11-27 12:48:01.000000000 +0100
@@ -259,6 +259,10 @@
        /* 1152x768, 60 Hz, PowerBook G4 Titanium I and II */
        NULL, 60, 1152, 768, 15386, 158, 26, 29, 3, 136, 6,
        FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
+    }, {
+       /* 720x576 @ 50 Hz, 15.625 kHz hsync (PAL RGB) */
+       NULL, 50, 720, 576, 74074, 64, 16, 39, 5, 64, 5, 
+       FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_INTERLACED
     },
 };

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

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:

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

der erweiterte Patch sieht dann so aus:

diff -ur linux-2.6.18.3.org/drivers/video/modedb.c linux-2.6.18.3/drivers/video/modedb.c
--- linux-2.6.18.3.org/drivers/video/modedb.c  2006-08-23 23:16:33.000000000 +0200
+++ linux-2.6.18.3/drivers/video/modedb.c      2006-12-11 22:16:53.000000000 +0100
@@ -259,6 +259,14 @@
        /* 1152x768, 60 Hz, PowerBook G4 Titanium I and II */
        NULL, 60, 1152, 768, 15386, 158, 26, 29, 3, 136, 6,
        FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
+    }, {
+       /* 720x576i @ 50 Hz, 15.625 kHz hsync (PAL RGB) */
+       NULL, 50, 720, 576, 74074, 64, 16, 39, 5, 64, 5, 
+       FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_INTERLACED
+    }, {
+       /* 800x520i @ 50 Hz, 15.625 kHz hsync (PAL RGB) */
+       NULL, 50, 800, 520, 58823, 144, 64, 72, 28, 80, 5, 
+       FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_INTERLACED
     },
 };

...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 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

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.

Zitat

I don't know other app with directfb(i use only VDR).

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

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