ATI radeon 9200se TV-Out

netvista-fan

Schau mal hier, tvout per Xorg. HowTo's dazu habe ich aber noch nicht gefunden. Soweit ich das sehe, ist die angegebene Version des ati-Modules in Debian Lenny und Ubuntu 7.10 beinhaltet.

Zu Gentoo kann ich nix sagen, aber evtl. kommst Du damit weiter.

Wenn Du einen Fernseher an den S-Video-Out anschließt und den Rechner/VDR anschaltest, solltest Du direkt die Console sehen. Dazu mußt Du nix ändern, das erkennt die Karte selbst. Problem ist dann nur in irgendeinen Grafikmodus zu kommen.....

Grüße
hummingbird_de

Zitat

Dann tüddel ich lieber am framebuffer oder löte mir ein Kabel.

wenn du schon loetfreudig bist, baue dir halt nen VGA->SCART Kabel:)
Bessere RGB-Qualitaet bekommst du mit einer Graka grundsaetzlich nicht hin. TV-OUT
(via Composite) ist leider immer eine Kruecke.

ein paar Links zum Thema:
TvOut mit VGA to RGB Kabel geht nicht (ATI)

Zitat

Naja, nur ob mein großer alter Grundig TV auch RGB versteht ist da so eine Sache...

der versteht garantiert RGB, da hiermit direkt die Ablenkelektronik gesteuert wird.
D.h. der Schaltungsmehraufwand fuer den Hersteller geht gegen Null. Ich habe hier ueberigens
auch 'nen alten Grundig SuperColor:) ( unter anderem )

Zitat

Also ein Tip für eine unkomplizierte konfiguration mit X und s-video wäre nett.

ich glaube sowas gibts fuer ATI nicht. Aber ich lasse mich gerne vom Gegenteil ueberzeugen.

Hi,
ich hab mit meiner Radeon9200 auch problemlos VGA->TV mit simplem Kabel gemacht.
Optimal und "lightweight" wäre dann der Weg direkt über den framebuffer.
Kernelpatchen ist dafür halt nötig, dann hat man aber ne Spitzenqualität.

Das Hauptproblem ist mit der framebuffer-Lösung ist allerdings noch:
- bff-Video wird als tff abgespielt (=Ruckeln bei Bewegung), bei ei
- man hat keine automatische 4:3 <> 16:9 Umschaltung mehr (dies könnte man evtl mit ein paar weißen Punkten (=bits) oben in der richtigen Zeige oben richten!)
- iDCT & MotionCompensation hab ich noch nicht zum laufen bekommen, d.h. man hat selbst bei normalem TV ne recht hohe CPU-Belastung

(Bitte korrigiert mich, falls ich wieder was verschlafen habe, was mittlerweile geht!)

Zitat

Das Hauptproblem ist mit der framebuffer-Lösung ist allerdings noch:
- bff-Video wird als tff abgespielt (=Ruckeln bei Bewegung)

um Probleme mit der Skalierung und den Fields zu umgehen, benutze ich im Moment noch tvtime zum
Deinterlacen. Skalieren geht dann ganz normal ueber die xv Extension. Qualitaet ist IMHO recht gut.
Mit Celeron 2GHz reicht die CPU Leistung auch gut aus.

Ich habe inzwischen auf Basis der drm-Lib in die xv- Extension ein paar Hooks eingebaut, die
es erlauben, die Fields zu jedem Zeitpunkt korrekt zu ermitteln. Der xv-Extension Standard
beiinhaltet das ja leider nicht.

Auf diese Weise kann ich ohne Scaling und Deinterlacing, die Fields direkt, wie sie vom
Decoder kommen ueber die GraKa auf den VGA Port geben. Das klappt schon richtg gut. Es werden
keine Fields mehr vertauscht. Es gibt aber leider noch das
entscheidende Problem, dass ich noch keine elegante Moeglichkeit gefunden habe,
Halbbilder moeglichst geschickt auszulassen/einzufuegen.

Das ist noetig, da die GraKa nie exakt mit 50Hz laeuft. Mit der Folge, dass ich deswegen ca.
alle 70 Sekunden genau ein Halbbild verliere.

Dieses letzte Problem muss aber loesbar sein, da es bei Matrox und Co. ja (angeblich?)
auch funktioniert. Moeglicherweise deinterlacen die temporaer in diesem einen Fall
der Resynchronisation.

Hat sich also leider doch noch nichts getan.

> Skalieren geht dann ganz normal ueber die xv Extension
> Mit Celeron 2GHz reicht die CPU Leistung auch gut aus.

Das ganze Deinterlacen ist ja leider wieder ein Qualitätsverlust, den man tunlichst vermeiden sollte. Da weiß ich nicht, ob das überhaupt was mit VGA-out bringt.
Und 2GHz Rechenleistung ist eigentlich auch viel zu viel. Ich würde hier gerne meinen runtergevolteten AthlonXP auf 1GHz laufen lassen, der (quasi-) passiv gekühlt auch leise genug für's Schlafzimmer ist.

Argh! Und ich hab mir doch immer ein Leichtgewicht ohne X.org Monster gewünscht.
Es muss gefälligst ohne deinterlacen gehen!

Optimal ist es einfach, den PAL-Stream auf nen 720x576i Framebuffer zu knallen, wobei dann (zB bei 480x576i input) nur noch horizontal skaliert werden muss (das aber dann bitte hardware-beschleunigt). Und YV12->RGB müsste doch eigentlich auch schon mit allen Karten beschleunigt gehen.

> Das ist noetig, da die GraKa nie exakt mit 50Hz laeuft. ...alle 70 Sekunden genau ein Halbbild verliere.

Es kann gut sein, dass X.org selbst Schuld daran ist und irgendwelche IRQs im Hintergrund was zucken lassen.
Beim framebuffer-Treiber gibt's eine broadcast Option, die dafür da ist, eben genau die boadcast 50Hz stabil zu halten.
Ich kann mich jetzt nicht genau erinnern, aber ich glaube, dass bei meinen Tests damals normale PAL-streams stabil gelaufen sind, ohne dass da jede Minute ein Halbbild verschluckt wurde.
Allerdings gab's halt die Probleme mit dem Bruchteil an Hardware-Beschleunigung, zT falscher field-order und der fehlenden WSS-Umschaltung.

Zitat

Argh! Und ich hab mir doch immer ein Leichtgewicht ohne X.org Monster gewünscht.

bei mir lauft nur der plain - Xserver und xine(liboutput). Sonst kein Xclient. Das braucht dann nur sehr wenig Resourcen.

Zitat

Es kann gut sein, dass X.org selbst Schuld daran ist und irgendwelche IRQs im Hintergrund was zucken lassen.

wie meinst du das? Es fehlt IMHO einfach eine Synchronisation zwischen dem dekodierten Stream und der GraKa.
Somit muessen die Takte eigentlich doch immer auseinanderlaufen. EIn Wert von nur 1 Halbbildverlust pro 70 Sekunden
erscheint mir ohnehin schon recht gut.

Zitat

Beim framebuffer-Treiber gibt's eine broadcast Option, die dafür da ist, eben genau die boadcast 50Hz stabil zu halten.

hast du da naehere Infos drueber? Hoert sich sehr interessant an! Aber ich kann mir nicht vorstellen wie das funktionieren soll.
Man kann doch nicht dynamisch das Timing der GraKa veraendern? Falls das doch irgendwie gehen sollte, haetten wir eine
Loesung wie von Dir gewuenscht - Ohne Deinterlacen und Field-Order immer korrekt.
Das laeuft dann auch auf deinem Schlafzimmer Athlon:)

> wie meinst du das?

Ich dachte einfach, dass da ein IRQ vielleicht die Verarbeitung der playback-surface unterbricht und der Spieler (xine bei dir?) dann ein Halbbild verschluckt.

> Es fehlt IMHO einfach eine Synchronisation zwischen dem dekodierten Stream und der GraKa.

Hmm.
Die Frage ist, wie Zeit-stabil so eine xv-surface eigentlich ist. Es darf halt einfach *überhaupt*kein* Halbbild verworfen werden, oder gleich 2 Halbbilder.
Man müsste es da auch schaffen, dass die xv-surface allerhöchste Priorität bekommt, vor allem anderen X.org Zeugs im Hintergrund.
Bisher waren Kernel und X.org immer darauf optimiert die Rechenzeit möglichst auf alles gleichmäßig zu verteilen. Realtime-Sachen (Audio etc.) waren schon immer kritisch. Hast du schon nen realtime-kernel probiert? An den Prioritäten der Prozesse gefeilt?

Es ist ja auch so, dass X.org nun mal eine Vollbild-Oberfläche anzeigt, und es nie Ziel war irgendwas direkt an die Anzeigetimings anzupassen. Geht ja auch nicht, weil die Playback-Geschwindigkeit eigentlich nie zum Bildschirm passt: Bsp. bei eingestellten 85Hz am Bildschirm soll trotzdem ein Film mit 30fps, 29,97fps, 25fps, 24fps, 23,975fps in richtiger Geschwindigkeit ablaufen.

Das ist ja auch der Grund, dass es immer zu tearing gibt, weil playback-Geschwindigkeit und Anzeigefrequenz nie genau zueinander passen (können). Dass man das tearing mit double-buffering verändern kann, löst das nur scheinbar, weil damit nicht das Problem gelöst wird, dass Film-fps und Bildschirm-fps auseinander laufen und irgendwann was verschluckt werden *muss*.

>> Beim framebuffer-Treiber gibt's eine broadcast Option, die dafür da ist, eben genau die boadcast 50Hz stabil zu halten.
> hast du da naehere Infos drueber? Hoert sich sehr interessant an!

Das ist mit der Grund, warum ich so am direkten framebuffer hänge. http://www.directfb.org
Auch wenn ich den noch nicht richtig zum Laufen bekommen habe, soll es doch genau das Teil für unsere Probleme sein.
Das ist ein hardware-treiber, der explizit auf solche timing-kritischen Sachen ausgelegt ist.
quote:
DirectFB is a graphics library which was designed with embedded
systems in mind. It offers maximum hardware accelerated performance
at a minimum of resource usage and overhead.

Mplayer unterstützt den framebuffer schon sehr gut. Insbesondere beim field-switchen, passt sich mplayer an den framebuffer an. Wenn ein (Halb)bild also schon fertig decodiert ist, kann da mit der Anzeige eigentlich nichts mehr schief gehen.
Nur bff kann mplayer noch nicht. Ich hab es aber damals versäumt das bei den mplayer-Entwicklern anzustoßen.

Diese -bcast Option kann man zB mit fbset setzen:
If enabled the frame buffer generates the exact timings for several broadcast modes (e.g. PAL or NTSC). Note that this option may not be supported by every frame buffer device

Weitere info dazu habe ich auch nicht. Ich denke mir halt, dass entsprechende Varianzen vom RAMDAC auf volle 50Hz ausgeglichen werden.
Es ist übrigens so, dass ein TV "ungenaue" 50Hz recht gut ausgleichen kann, D.h. ein Halbbild darf von der Grafikkarte ruhig mal ne Spur früher oder später kommen. Nur konstantes Driften zwingt natürlich irgendwann zum Halbbildverlust.
So ein Driften wird -bcast, denke ich, ausgleichen.

Tja, nach über einem Jahr müsste sich aber eigentlich was getan haben, oder?
Damals hab ich das tff/bff-Problem und das fehlende widescreen-signaling schon angesprochen (und konnte damal auch von der Idee lesen, die WSS-Signale durch weiße Punkte/Linien in Zeile 0 zu emulieren).
Ich denke ich muss nochmal etwas Zeit investieren!

Nachtrag:
Das ist übrigens mein framebuffer, der ohne Zuckeln funktioniert auf meiner
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01)
Interessanterweise, wie ich gerade feststelle, hab ich das letztes Jahr ohne das -bcast flag stabil hinbekommen. Ich glaube dass das damals keine Auswirkung hatte; müsste man sicherlich aber mal genauer mit Langzeitstudie beobachten.

vdr:/usr/src# fbset -i
mode "720x576-50"
# D: 13.500 MHz, H: 15.625 kHz, V: 50.000 Hz
geometry 720 576 720 576 32
timings 74074 64 16 39 5 64 5
hsync high
vsync high
laced true
rgba 8/16,8/8,8/0,0/0
endmode

Frame buffer device information:
Name : ATI Radeon Y`
Address : 0xf0000000
Size : 134217728
Type : PACKED PIXELS
Visual : DIRECTCOLOR
XPanStep : 8
YPanStep : 1
YWrapStep : 0
LineLength : 2880
MMIO Address: 0xdf800000
MMIO Size : 16384
Accelerator : ATI Radeon family

Das erzeugt übrigens ein "richtiges" PAL-Vollbild mit overscan. Ein DVD-playback draufgeworfen schaut da genauso aus, wie aus dem DVD-Player.
Man muss also keine komischen skalierten Auflösungen wie 768x576 (richtigerweise ja 787x576) bauen, die mit Video-Auflösungen nichts zu tun haben.

Obigen PAL-Modus bekommt man übrigens mit

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

allerdings erst nach Kernel-patchen, wie gesagt.

Kernel-patch nochmal:

# Patch für PAL-RGB aus dem VGA-Ausgang fuer Radeon-Karten
# patchen mit -p0 aus dem Kernel-Verzeichnis
#
#
# Aktiviert niedrige DAC-Frequenzen für die Radeon, damit PAL-Auflösungen
# am VGA-Ausgang moeglich werden.
#
--- drivers/video/aty/radeon_base.c.orig        2007-01-10 20:10:37.000000000 +0100
+++ drivers/video/aty/radeon_base.c     2007-01-28 16:57:16.000000000 +0100
@@ -665,6 +665,9 @@ static void __devinit radeon_get_pllinfo
                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;
        }


@@ -1642,6 +1645,13 @@ static int radeonfb_set_par(struct fb_in
                                        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;


#
# Das hier ist, damit die fb-Aufloesungen auch schon als kernel-parameter (= beim booten) moeglich sind
#  zB: /boot/vmlinuz-2.6.18.3-radeon root=/dev/hda1 ro video=radeonfb:720x576-32@50i
# oder /boot/vmlinuz-2.6.18.3-radeon root=/dev/hda1 ro video=radeonfb:800x520-32@50i
#
--- drivers/video/modedb.c.orig 2007-01-10 20:10:37.000000000 +0100
+++ drivers/video/modedb.c      2007-01-28 17:06:41.000000000 +0100
@@ -259,6 +259,14 @@ static const struct fb_videomode modedb[
        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
+    }, {
        /* 1366x768, 60 Hz, 47.403 kHz hsync, WXGA 16:9 aspect ratio */
        NULL, 60, 1366, 768, 13806, 120, 10, 14, 3, 32, 5,
        0, FB_VMODE_NONINTERLACED

Hi shh,

danke fuer deine umfangreiche Antwort. Leider wird es OT - aber sehr interessant.
EIn paar Anmerkungen:

Zitat

Es darf halt einfach *überhaupt*kein* Halbbild verworfen werden, oder gleich 2 Halbbilder.

Sorry aber das stimmt nicht. Mit einem XvPutImage() Request an den Xserver kommt ein 'interlactes' Komplettbild also Even und Odd
Field. Dort wird es in den (bei Radeon) DoubleBuffer geschrieben. Der Interlace-Modus des CRT Controllers
gibt diese Fields dann sequentiell aus.

Das funktioniert auch ohne Probleme hier. ich habe schon genug im Xserver an dieser Stelle debuggt:-)

Es kommt aber darauf an in welcher Halbbildphase genau der DoubleBuffer beschrieben wird. Abhaengig davon
kann man dabei ein Halbbild verlieren. Ich habe aber zumindest einen Algorithmus in den Xserver
eingebaut, der in diesem Fall das Halbbild puffert. Somit merkt man erst noch nichts davon.

Erst nach den naechsten 70 Sekunden wenn das naechste Halbbild verloren wird, ergaenzen sie
sich zu einem Komplett-Bild-Verlust (even + odd frame). Theoretisch koennte man die Pufferung
sogar beliebig fortsetzen. Pro Stunde macht das nur 1020ms Verzoegerung aus. Dann
haette man bereits jetzt zusamman mit meinen sonstigen Modifikationen perfekte Wiedergabe ohne jeden Fieldverlust!

Man muesste halt Audio nur aequivalent verzoegern.

Zitat

Geht ja auch nicht, weil die Playback-Geschwindigkeit eigentlich nie zum Bildschirm passt:

darum muss es genau umgekehrt gemacht werden. Die Graka muesste permanent mit dem Stream synchronisiert werden.

Zitat

Nur bff kann mplayer noch nicht. Ich hab es aber damals versäumt das bei den mplayer-Entwicklern anzustoßen.

das laeuft hier bereits auch unter Xv mit Hile des drm-Kernel Modules. Ich habe es entsprechend erweitert. Das drm_modul erzeugt
genau nach jedem Halbbild einen Interrupt. Mit einem ioctl(() kann ich im Xserver den aktuellen
Status jederzeit ermitteln.

Zitat

Es ist übrigens so, dass ein TV "ungenaue" 50Hz recht gut ausgleichen kann,

richtig! Aber die Graka eben nicht. Man kann die Timingregister nicht dynamisch veraendern.
Zumindest ist mir keine Methode bekannt. Vermutlich wuerden spaetestens LCDs solche
Timing-Spielchen nicht mehr mitmachen. Und typischerweise haengt an einer GraKa halt kein TV:-)

Zitat

D.h. ein Halbbild darf von der Grafikkarte ruhig mal ne Spur früher oder später kommen

es kommt darauf an in welcher Double-Buffer Phase genau der naechste Update kommt. Man muesste das
Timing der Graka dynamisch so einstellen koennen, dass der Update *synchron* mit dem Stream verlaeuft.

-sparkie

> danke fuer deine umfangreiche Antwort. Leider wird es OT - aber sehr interessant.

Stimmt, wird wirklich off topic.
Ich werde aber die nächsten Tage noch ein paar Sachen testen.
Neuer thread? Oder soll ich deinen alten (von deiner Signatur wiederbeleben) wiederbeleben? Da gehört das hier ja eigentlich hin.

Zitat

Neuer thread?

ja gerne! Wir koennen ja mal unseren aktuellen Kenntnisstand festhalten. Ich koennte dann
auch meine aktuellen Patches dazustellen.

Ich vermute aber, dass es hier im Portal vielleicht nicht so ganz viele Leute interessiert, da es
eher Entwicklung statt Anwendung ist. Vielleicht waere es auf der vdr-ML besser aufgehoben?

netvista-fan

Falls noch von Interesse, gibt es hier ein HowTo bzgl. Xorg und xrandr. Bezieht eigentlich auf Dual-Screen, aber das automatisiert.

Grüße
hummingbird_de

Zitat

Originally posted by netvista-fan
@ sparkie / ssh
Habt ihr schon mal getestet ob das VGA->Scart-RGB Kabel auch über einen DVI Ausgang und DVI->VGA Adapter funktioniert?

nein

Zitat

Welche "Schaltung" habt ihr genommen?

frueher die aus diesem Post

aktuell nur noch die (D1 C1 LED1 sind oft nicht noetig) aus diesem Post

Zitat

Ah, hab grad gesehen die simple ohne transistor klappt nur für ATIs da diese das sync Signal erstellen (passt wohl für mich...

richtig. Ich baue die Kabel inzwischen aber trotzdem immer mit Transistor, dann funktionierts auch mit nVidia:)

WICHTIG: Das einfache Kabel (ohne Transistor) setzt einen Patch im radeonfb Kerneltreiber voraus.
Ansonsten wird das TV Geraet in der Zeit, bis der Xserver startet mit Separate-Sync betrieben!
Das kann fuer Geraete ohne interne Schutzschaltung evtl. gefaehrlich sein.

Wichtig ist ausserdem, die SyncPolarity in der ModeLine explizit anzugeben (der default lautet naemlich anders).

Die Modeline fuer Kabel *ohne* Transistor (GraKa macht den Sync selbst) lautet:

Modeline "720x576i"   13.875 720  744  808  888  576  580  585  625 -HSync -Vsync interlace composite

Fuer Kabel mit Transistor (externer Sync):

Modeline "720x576i"   13.875 720  744  808  888  576  580  585  625 -HSync -Vsync interlace

Noch ein Tipp:
wenn du die Kiste hochfaehrst werden im BIOS, im GRUB und auf der Konsole etc. ohne weitere
Modifikationen diverse Aufloesungen benutzt. Um auf der sicheren Seite zu sein
den TV erst nach Xserver Start anschliessen.

Zum Testen hat sich bei mir ein LCD Display sehr nuetzlich erwiesen. Mein LCD kommt sogar mit den Composite RGB
Signalen zurecht. Das ist zum Pruefen der Schaltung und Einstellen von GRUB, Framebuffer und Xserver Videotimings hilfreich.

Wenn du das Kabel MIT Transistor verwendest hat das den Vorteil, dass die 640x480 Aufloesung
fuer den TV ungefaehrlich ist. Ohne Framebuffer Patch wird dann horizontal zwar alles doppelt dargestellt aber das Geraet synchronisiert.

Damit GRUB ebenfalls 640x480 verwendet muss man ein entsprechendes SplashImage verwenden.
Die Console zunaechst (bis man den gepatchten radeonfb einsetzt) am besten mit 'vga=0x301' starten.

hallo,

ich hab eine ati radeon x300 (ausgänge: s vdeo,vga,dvi) und würde mir auch gerne dieses kabel basteln damit ich ein bild auf den fernseher hab.

Welche schaltung kommt für mich in frage ?

gruß
shadow

Zitat

Welche schaltung kommt für mich in frage ?

die x300 kenne ich leider nicht. Das Kabel mit Transistor ist universeller. Vermutlich geht aber auch die einfachere Variante. Wenn du ein Oszilloskop haettest, waere das schnell herausgefunden...