Beiträge von shh

    Hallo,
    ich suche ein Mainboard, bei dem S3-wakeup/resume (also Aufwachen nach suspend-to-ram) klappt, und volle Hardware-Beschleunigung genutzt wird.
    Leider habe ich die Entwicklung der letzten 2 Jahre nicht verfolgt und bin daher nicht ganz auf der Höhe.
    Unter welcher Distribution das dann läuft, ist mir ziemlich egal - solange kein Windows ;) - VDR soll halt laufen via HDMI an den Fernseher. Dauer-patchen würde ich aber, wenn's geht, lieber vermeiden.


    Ausserdem brauche ich GBit-Lan, 2 PCI-Steckplätze und ein PCIe x1 (PCIe zum späteren Aufrüsten), d.h. ITX-ION-Boards passen wohl nicht; wünschenswert wäre ein µATX.
    Ach ja, die Boot-Zeit des BIOS sollte natürlich "super" sein. :D


    - funktioniert denn S3 mit aktuellen nforce7xx boards von ASUS?
    - gibt's schon volle Unterstützung für ATI/AMD-IGPs?
    - wären Intel-Chipsätze ne Alternative zu VDPAU?


    Falls das zZ nicht geht, gibt's dann vielleicht ITX-ION-Boards mit funktionierendem S3, die auch 1920x1080p24 [<= MKV via Netzwerk] und 1920x1080i50+(guter)deinterlacer abspielen können, ohne zu Ruckeln, oder abzurauchen? (für diese Lösung bräuchte ich halt gleich ne neue Twin-Tuner-Karte, neues Gehäuse usw... )


    Grüße...

    Hmm, leider klappt das aber anscheinend immer noch nicht richtig hier. :(
    - Wenn man auf DD umschaltet stürzt vdr-sxfe ab
    - Wenn man unter den plugin-Optionen xon bitstreamout, das plugin abschaltet, geht DD auf einmal (und wird auch automatisch gewählt), nur andere Kanäle mit MP2 bleiben stumm


    Irgendwelche Ideen?

    Hatte das gleiche Problem, dass bitstreamout nicht geladen wurde (Ubuntu).
    Hier hat aber ein simpler Link geholfen; neues Kompilieren war nicht nötig:

    Code
    root@vdr:/usr/lib/vdr/plugins# ln -s libvdr-bitstreamout.so.1.6.0-2 libvdr-bitstreamout.so.1.6.0
    Zitat

    Original von halbfertiger
    Wo soll da horizontal was verloren gehen?
    Wo geht bei Deinterlacing vertikal was verloren? Warum muss man für einen Röhrenfernseher deinterlacen. Diese Geräte benötigen Interlace-Material!

    Ich dachte, ich hätte das schon erklärt. Bin ich zu schnell? :)
    Wenn man eine korrekte aspect-ratio des Quellmaterials an einem auf fix 16:9 gestellten TV haben muss, muss VDR/xine bei einem 4:3-Film zuerst das Material um den Faktor 1.333 schrumpfen, weil dein TV, das ja um 1.333 wieder streckt: Bei einem 720er Film sind das schlußendlich 25% (=540/720) weniger horizontale Linien Bildinformation.
    Alternativ müsste man für korrekte aspect-ratios (wenn denn WSS nicht geht, oder man nicht umschalten möchte), den TV auf 4:3 lassen und 16:9-Quellmaterial vertikal um den Faktor 1.333 schrumpfen. Dafür müsste man den Film aber vor dem vertikalen Skalieren deinterlacen (naja, man könnte auch fieldweise schrumpfen, was aber laut meinen Erfahrungen schlechtere Qualität bringt, und ich weiß auch nicht, ob xine das fieldweise überhaupt machen kann, beschleunigt per XV jedenfalls nicht...)


    Zitat

    Original von halbfertiger


    Verabschiede dich von Pixel, der Röhrenfernseher wird mit einem analogen Signal angesteuert, da gibt es keine Pixel nur Frequenzen. Und die geringen Frequenzen eines 544x576 oder 480x576 Datenstroms können in einem anamorphen 16:9 RGB-Signal locker verlustlos übertragen werden. Das unscharfe Bild bei solchen Signalen entsteht nicht erst im Fernseher, sondern schon beim Sender im Encoder.


    Öhm. Ja. Schön, dass du verstanden hast, wie ein PAL-Bild funktioniert. :tup
    Ich habe absichtlich Pixel-Auflösungen angegeben, um grob darzustellen, was da durch das bilineare Vorskalieren an horizontalen Linien verloren geht. Verlust wg Kellfaktor kommt ja noch dazu.
    Man hat geich an der Quelle weniger Bildinformationen, da ist die Darstellung des Signals am TV erstmal uninteressant. Um 16:9-Material gehts doch hier auch gar nicht, das wird natürlich ohne Frage optimal übertragen.

    Igitt! Daran hab ich nicht gedacht.
    Wie sicher bist du dir damit, dass man ein FBAS-Signal braucht?
    Hier übrigens mal ein Link zu den WSS-bits: http://www.intersil.com/data/an/an9716.pdf
    NACHTRAG: Da steht zumindest auf S.1 links unten: "For analog
    RGB video signals, WSS information should be present on
    all three signals."
    Ob das allerdings den gängingen TVs genügt ist natürlich fraglich...


    Ich hab hier ein MPEG von Bloomberg, wo die WSS-bits hartcodiert mitgesendet wurden. Aber leider 4:3, d.h. ich kann das nicht testen, weil mein TV standardmäßig in 4:3 anfängt und wenn man das mal manuell umgeschaltet hat, macht er nichts mehr automatisch (Sony-Klump).
    Hat jemand 16:9-Material mit codierten weißen WSS-Strichen für mich? Dann könnte ich die Umschaltung auf meinem TV im reinen RGB-Modus testen.


    > Es werden immer weniger Röhrenfernseher...


    Mag ja sein, aber meiner läuft schon 8-10 Jahre und ich hab auch keine Lust nen neuen zu kaufen. ;)
    Wenn das alles mit dem WSS nicht läuft, wird das fixe 16:9-Setzen aber die einzige Lösung sein. Lieber horizontal 25% verlieren, als vertikal durch deinterlacing viel mehr.
    Aber oft gesendete 544x576 (oder 528x576) gehen damit schon auf magere 408x576 (bzw 396x576) Pixel runter. Das ist schon seeehr wenig! :(
    ...jetzt könnte noch einer kommen und die horizontale bilineare Filterung des DVB-Materials gutheißen .... hehehe . . . nö lieber nicht! :lol2

    Ich hab hier das selbe Problem mit der Formatumschaltung.


    Dauerhaft auf 16:9 schalten bringt eigentlich nichts, bzw nur was bei 16:9-Material.
    Einen 4:3-Film müsste xine vorher auf 540x576 schrumpfen und dann auf 720x576 padden, damit man immer korrekte aspect-ratio hätte. Aber der hozizontale Auflösungsverlust ist eigentlich nicht das, was man möchte. Schlimmstens hat man einen 4:3er Film mit 480x576 oder 352x576 vorliegen. Sowas weiter geschrumpft und gepadded kann man wirklich nicht mehr anschauen.
    Vertikal irgendwas skalieren geht ja auch keinesfalls, weil man so wieder deinterlacing bräuchte.
    Lösung ist also nur ordentliches widescreen-signaling.


    Kann man die kleinen weiße Striche denn nicht per Software im VDR erzeugen? Oder das OSD oder xine dazu missbrauchen, nach einem Auflösungswechsel oben ein paar wss-bits aufs overlay zu schreiben?
    Hat sich schon jemand damit beschäftigt?


    In der Firmware der Technotrend FF-Karte kam das ja auch vor einiger Zeit dazu. Wie wurde das da gelöst?


    Zitat

    Original von iNOB
    Welche Modline verwendest du? Sollte bei 16:9 Ausgabe diese sein:

    Code
    ModeLine	"1440x576_50i"	27.75   1440 1488 1609 1769   576  580  585  625  -hsync -vsync interlace


    Warum? Formatumschaltung hat doch nichts mit ner fixen Auflösung zu tun.
    Du müsstest im Prinzip die gleichen Probleme haben. ;)

    > Ich behaupte mal, dass der bei dir im Moment ohne meine Patches ebenfalls nicht kompiliert.


    Doch! Ohne patches kompiliert das tatsächlich durch (bringt aber natürlich nichts)


    Lösung:
    Ich hab hier ja noch den 2.6.28er von e-tobi auf dem System und irgendwie bekommt xserver-xorg-video-ati dann das __user nicht mehr definiert. (die build-dependencies stimmen da anscheinend nicht mehr, weil das radeon-Modul implizit was vom Kernel braucht)
    Genauer hier bei der Fremdhilfenanfrage: http://debianforum.de/forum/viewtopic.php?f=34&t=114116&p=723425#p723425


    D.h. wenn man einen anderen Kernel benutzen möchte, muss man den radeon_drm.h patch noch erweitern:
    In /usr/include/drm/radeon_drm.h in Zeile 35 folgendes hinzufügen:

    Code
    #ifndef __user
    #define __user
    #endif

    Ich hab mal meine aktuellen, modifizierten patches für den 2.6.28er Kernel angehängt, für alle, die's evtl brauchen können.
    Patchen mit -p1 aus dem Kernel-Sourcen-Verzeichnis

    VGA2SCART mit dem aktuellen Release (vga-sync-fields-0.2.0) klappt nicht,
    xserver-xorg-video-ati_6.9.0 kompiliert nicht durch. :(
    D.h. die aktuelle Debian/lenny Version mit dem xv-patch für Radeons.
    Egal, ob ein komplettes dpkg-buildpackage oder nur ein make im obj-i486-linux-gnu gemacht wird, ich bekomme immer folgendes:


    radeon_drm.h ist schon gepatcht und sitzt in /usr/include/drm/
    (ich hab sie unten angehängt)
    Hier kann man die anschauen: http://pastebin.com/m1733c0fe


    apt-get build-dep xserver-xorg-video-ati hab ich auch ausgeführt...
    Tja keine Ahnung mehr. Habt ihr Ideen?

    Hmm, scheint da nicht sowieso mit den Repositories irgendwas im argen zu sein?
    Wie kommt man denn zB an die gepatchten libxine1 oder libxine-dev?
    Gibt's dafür irgendeinen Grund, dass die nicht in lenny/vdr-experimental und auch nicht in sid/vdr-experimental zu finden sind?
    Es ist ja zZ in Debian/testing(sqeeze) auch schon die libxine1 1.1.16.3 zu finden, die übrigens ohne Probleme auch unter Lenny durchkompiliert.
    Ich hab hier folgende sources.list:

    Code
    deb http://ftp.de.debian.org/debian/ lenny main non-free contrib
    deb-src http://ftp.de.debian.org/debian/ lenny main non-free contrib
    deb http://security.debian.org/ lenny/updates main contrib non-free
    
    
    deb http://debian-multimedia.org lenny main
    
    
    deb http://e-tobi.net/vdr-experimental lenny base backports addons vdr-multipatch
    deb-src http://e-tobi.net/vdr-experimental lenny base backports addons vdr-multipatch

    Egal was ich da an den Repositories von e-tobi rumstelle, es wird immer nur die libxine-dev aus Lenny gefunden. :schiel

    Es läuft jetzt. Allerdings mit einem gepatchtem e-tobi 2.6.28er Kernel.
    Frag mich nicht warum das auf einmal geht - ich hab praktisch einen unveränderte Änderung in radeon_base.c


    Folgendes kommt jetzt mit der 9250er:
    [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.28-20090916 root=UUID=xxxxxxx ro video=radeonfb:800x520-32@50i
    [ 0.510352] radeonfb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
    [ 0.511551] radeonfb: Found Intel x86 BIOS ROM Image
    [ 0.511601] radeonfb: Retrieved PLL infos from BIOS
    [ 0.511647] radeonfb: disregarding BIOS ppll_min of 20000
    [ 0.511694] radeonfb: using ppll_min of 12000 instead
    [ 0.511741] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, System=166.00 MHz
    [ 0.511800] radeonfb: PLL min 12000 max 40000
    [ 0.512853] radeonfb: Monitor 1 type CRT found
    [ 0.512899] radeonfb: Monitor 2 type no found
    [ 0.633302] radeonfb (0000:01:00.0): ATI Radeon 5960 "Y`"


    Verbesserungsvorschläge:
    Das hier gilt alles für meine Radeon 9250 auf Standard-PAL-TV
    pal_modeline:
    Die Ausgabe stimmt nicht, bzw stimmt die nicht mit dem empfohlenen Patches zusammen.
    -hsync und -vsync sollten false sein (oder weglassen) für den Framebuffer
    - accel true könne man noch setzen (falls das was bringt; funktioniert jedenfalls)
    Modeline für X11 ist auch nicht die, die in der xorg.conf empfohlen wird
    Passendes wäre also:
    fbset -g 720 576 720 576 32 -t 74074 64 16 39 5 64 5 -laced true -accel
    oder
    fbset -g 800 520 800 520 32 -t 58823 144 64 72 28 80 5 -laced true -accel true


    INSTALL:
    Beim Kernelbauen baut das Buildsystem alle 10(?) Kernel-Varianten, was ewig dauert und nicht nötig ist.
    Also lieber so bauen:
    apt-get build-dep linux-image-2.6.26-2-686
    apt-get source linux-2.6
    cd linux-2.6-2.6.26
    cp /boot/config-2.6.26-2-686 .config
    make oldconfig
    patch -p1 </pfad/zum/patch
    make-kpkg kernel_image --initrd
    Allerdings sind da modifizierte patches nötig, die vom linux-2.6-2.6.26-Verzeichnis mit -p1 durchlaufen.
    Man spart sich damit auch den meiner Meinung nach umständlichen Schritt zuerst zu bauen, dann nach debian/build/build_i386_none_686 gehen, patchen, nochmal bauen,...
    Bei mir hätte man ein .deb in einem Rutsch.
    Das gilt übrigens für alle Debian-Pakete. Es ist überhaupt nicht notwendig, zuerst ein dpkg-buildpackage auszuführen oder manuell Module zumzukopieren, wie etwa:
    cp ./src/.libs/radeon_drv.so /usr/lib/xorg/modules/drivers
    Es genügt, gleich zu patchen, und dann dpkg-buildpackage auszuführen, was ein gepatchtes deb erzeugt.
    (oder hab ich da vielleicht einen tieferen Sinn übersehen)


    Frage noch am Schluss:
    xine-lib und vdr-plugin-xineliboutput sind in Debian/testing zu finden, mit zT neuerer Version, als bei deiner Anleitung mit CVS oder Sourceforge
    Ich hab die gepatcht und durchkompiliert. Allerdings semmelt VDR dann bei aktiviertem sync-fields ab (Schaltet man das in xorg.conf aus, gibts zumindest keine Abstürze von X11)
    Hast du ne Ahnung was da an den xine-libs von Debian verändert/verschlimmbessert wurde?


    Grüße.....


    Nachtrag:
    drift_control und dumpio gehen nur, wenn ich für meine Radeon 9250 den device-id 0x5960 hinzufüge.

    Ich möchte mich mal hier dranhängen, hab nämlich (glaube ich) das gleiche Problem.


    Ich hab seit ein paar Jahren ein System mit FF-Karte laufen. Aktuell nen 2.6.30er Kernel, das Problem besteht aber seit schätzungweise Kernel 2.6.23/2.6.24 (also etwa seit nem Jahr).
    Ich hab dabei meistens nen aktuellen Vanilla-Kernel laufen (mit mini-patches)
    Mein ASUS/Via-chipsatz-board braucht übrigens keinen Reboot für nvram, aber der Effekt ist hier glaube ich der gleiche:
    Ich hab nen Timer abgespeichert und nach längerer Laufzeit fahre ich das System via Fernbedienung runter (beim automatischen runterfahren passiert das aber auch)
    Dann hängt er aber, CPU-Lüfter geht auf full-speed und die Festplatte hängt auch bei full-speed.
    Da hilft dann auch nur noch ein Ausschalten via Power-Knopf.
    Und es passiert auch nur 2-3mal pro Monat. (vielleicht seltener)


    Leider kann ich wegen FF-Karte aber nicht kontrollieren, was sich da aufhängt.
    NVRAM wird aber anscheinend nicht mehr korrekt geschrieben, denn der vdr wacht nach manuellem Poweroff (Power-Knopf 4sek halten) nicht mehr zum programmierten Zeitpunkt auf.
    Aber wahrscheinlich ist das auch irgendein SEGFAULT, wenn der CPU-Lüfter auf Notbetrieb (fullspeed) geht.


    Kann das sein, dass das NVRAM mit der Zeit kaputt geht, und dann SEGFAULTS auftreten?

    Hi!
    Die aktuellen patches v0.2.0 setzen bei mir die Framebuffer PAL-Auflösung beim booten nicht, obwohl ich mich an die Anleitung gehalten habe, und X zB auch in PAL-Auflösung läuft.
    System ist Debian/lenny mit dem aktuellen gepatchtem Kernel 2.6.26-2.
    Graka (Radeon 9250):
    01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01)
    01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01)


    Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.26 root=UUID=xxxxxxxxxx ro video=radeonfb:720x576-32@50i


    dmesg liefert dann:
    [ 0.456452] radeonfb: Found Intel x86 BIOS ROM Image
    [ 0.456501] radeonfb: Retrieved PLL infos from BIOS
    [ 0.456549] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, System=166.00 MHz
    [ 0.456608] radeonfb: PLL min 20000 max 40000
    [ 0.457656] radeonfb: Monitor 1 type CRT found
    [ 0.457701] radeonfb: Monitor 2 type no found
    [ 0.498777] Console: switching to colour frame buffer device 100x37
    [ 0.527213] radeonfb (0000:01:00.0): ATI Radeon 5960 "Y`"
    [ 0.527894] isapnp: Scanning for PnP cards...
    [ 0.764027] Switched to high resolution mode on CPU 0
    [ 0.881929] isapnp: No Plug & Play device found
    [ 0.886157] Linux agpgart interface v0.103
    [ 0.886413] intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/965G/965GM chipsets
    [ 0.886797] intelfb: Version 0.9.5
    [ 0.886991] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
    [ 0.887426] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
    ...
    Einkompiliert ist hier radeonfb, intelfb und auch lirc (also nicht wundern)


    scheinbar ist da PLL min immer noch bei 20000, wo man doch eine min von 12000 bräuchte. Wahrscheinlich wird deshalb eine andere Auflösung statt PAL gesetzt, denn später lande ich bei:


    satvdr:~# fbset -i -v
    Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
    (C) Copyright 1995-1999 by Geert Uytterhoeven


    Opening frame buffer device `/dev/fb0'
    Using current video mode from `/dev/fb0'


    mode "800x600-56"
    # D: 36.001 MHz, H: 35.157 kHz, V: 56.252 Hz
    geometry 800 600 800 600 32
    timings 27777 128 24 22 1 72 2
    rgba 8/16,8/8,8/0,0/0
    endmode


    Getting further frame buffer information
    Frame buffer device information:
    Name : ATI Radeon 5960
    Address : 0xd8000000
    Size : 134217728
    Type : PACKED PIXELS
    Visual : DIRECTCOLOR
    XPanStep : 8
    YPanStep : 1
    YWrapStep : 0
    LineLength : 3200
    MMIO Address: 0xe8020000
    MMIO Size : 16384
    Accelerator : ATI Radeon family



    Hmm, irgendwelche Lösungsvorschläge?


    NACHTRAG:
    Scheinbar patcht der radeon-PLL-patch irgendwas in der falschen Zeile im Kernel, radeon_base.c
    Da passen nämlich die Kernel -Kommentare gar nicht mehr mit den Log-Ausgaben des patches zusammen!
    Da wird die ppll_min nur auf 12000 gesenkt, wenn man einen x86 hat? Hääh, ich habe aber nen x86 laufen (AMD Athlon(tm) XP 1800+) und trotzdem wird laut kernel-log erst das nächste IF ausgeführt!?!


    Ich probier' mal, den patch anzupassen und neu zu kompilieren...

    Kurze Zwischenfrage:
    Sind die Pakete von c't-VDR und Debian/testing die selben?


    Ich hab mir vor ein paar Tagen aus testing auch eine libxine1 kompiliert, die Version 1.1.16.3 hat. (allerdings heißt die source da "xine-lib")
    Und die semmelt sofort ab, wenn ich den VDR mit vdr-sxfe starte.
    => Sind die "Segfaults bei Einblendung des OSD" also auch mein Problem? Ich hab's hier nämlich noch nicht lokalisieren können.


    Ich hab hier debian/lenny mit
    vdr von stable
    libxine1 von testing kompiliert
    vdr-plugin-xineliboutput von testing kompiliert
    auf ner Radeon 9250 (nicht NVIDIA/VDPAU, wie oben verlinkt)

    Dank euch erstmal!
    Threads kann ich erst morgen anschaun, hab heute keine Zeit mehr.
    Suchfunktion hat tatsächlich nichts ergeben. Und ich suche auch schon seit 2 Tagen rum und probier alles mögliche. Vielleicht hab ich wieder mal die falschen Suchbegriffe eingegeben... deinTitel, hummingbird_de, hätte mich aber ohnehin weiterspringen lassen: "EPIA M10000, FF,...". :(
    Vielleicht könnte einer mal relevante HOWTOs pinnen, oder vielleicht das vdr-wiki aktualisieren? Beides hab ich nämlich auch durchforstet, und da war entweder zu altes, oder auch wieder unrelevantes.
    Es fehlt nämlich einfach ein schlichtes aktuelles HOWTO für Debian oder Ubuntu, der einen budget-Client aufsetzen möchte. Da weiß man überhaupt nicht, was man denn nehmen, und wie man das letztendlich umsetzen soll.
    (ich hab halt noch meinen seit ewigen Zeiten laufenden FF-Client und hab keine Plan über die aktuelle Entwicklung)


    Grüße...

    debian/lenny, vdr-1.6.0, xineliboutput mit vdr-sxfe auf X:
    (ich hab hier ne Radeon 9250, also nix vdpau)


    Wie startet ihr denn den vdr automatisch beim boot, "Debian-konform"?
    Ich hab zwar einige Anleitungen schon gelesen für vdpau, easyvdr, ubuntu; meistens sind das aber massive Eingriffe in irgendwelche bootscripts, bzw gleich komplett neue. Ist das denn nötig?
    Wie macht Ihr denn das, damit das schnell/einfach/sicher(tm) geht?


    Folgendes:
    startx
    xhost + local:
    /etc/init.d/vdr restart


    bringt schon alles zum Laufen. Automatisch bräucht' ich's halt noch; natürlich mit möglichst kurzer boot-Zeit.


    Grüße...

    > Bezueglich deiner Fehlermeldungen beim Kompilieren:
    > Du hast im INSTALL diese Zeilen ueberlesen:
    >> # before building the DDX patched 'radeon_drm.h' must be
    >> # copied to /usr/include/drm/radeon_drm.h (see below).


    Eigentlich hab ich das nicht vergessen.
    Ich hab die Datei vom xserver-xorg-video-ati Verzeichnis nach /usr/include/drm/ kopiert.
    Das xserver-xorg-video-ati läuft trotzdem nicht durch.
    Das ist aktuell ne Version 1.5.2, 6.9.0+git20081012


    Ich habe mich an folgende Anleitung gehalten:
    http://vdr-wiki.de/wiki/index.php/CheapBudget
    Deine INSTALL ist ja nahezu identisch dazu.
    Aber die debian-experimental Version vom xserver-xorg-video-ati funktioniert funktioniert einfach nicht. Dein 0.0.9er patch sowieso nicht, da bricht am Anfang das Nachpatch-System ab (weil debian noch irgend einen extra-patch drüber laufen lassen will: 01_gen_pci_ids.diff), der 0.0.8er patch bricht später mit Fehler 2 ab.


    >>Edit: Ach ja, Vorsicht mit der xorg.conf vom ersten post. [...]
    >> Option "ForceMinDotClock" "12.0MHz"
    > diese Zeile steht doch korrekt ebenfalls im README?


    Ich bezog mich dabei auf die xorg.conf, die durchflieger am Anfang seines threads angehängt hat. Da fehlt die Einheit und steht nur "12.0".
    Deshalb auch mein post im anderen thread, also nix wofür dein README was kann. ;)



    Aber, dieser thread ist eh schon 4 Wochen alt und du scheint den ja quasi an durchflieger abgegeben zu haben (siehe letzte Meldung). Ist der patch-set von durchflieger "besser"?

    Kann mir jemand mal eine Quelle vom xserver-xorg-video-ati (xorg V7.4 (xserver V1.5)) nennen, die auch durchkompiliert?
    Die aktuelle Version von debian experimental tut´s jedenfalls seit mind. einer Woche nicht (mit dem video-ati patch von vga-sync-fields-0.0.9.tgz oder vga-sync-fields-0.0.8.tgz) und endet immer mit Fehler 2 (log dazu findet man ein einem post von mir weiter oben).


    Und ich möchte auch meine vorherige Frage wiederholen, weil sich darüber nahezu jeder ausschweigt - auch das CheapBudget-wiki:
    Mit welchem vdr-plugin und lib wird das hier realisiert?
    vdr-xine?
    vdr-plugin-xineliboutput?
    vdr-softdevice?
    xineliboutput-sxfe?


    Danke!


    Edit: Ach ja, Vorsicht mit der xorg.conf vom ersten post.
    Ich hab hier vom debian-experimental den server 1.5.2 laufen und folgendes (wie in der angegebenen xorg.conf) geht da nicht:


    Option "ForceMinDotClock" "12.0"


    der verlangt jetzt je Einheit hinten dran, also so was:


    Option "ForceMinDotClock" "12.0MHz"


    Es ist möglich, dass da einige drüber stolpern, weil so (ohne Kernel-patchen) ja keine normalen PAL-timings mehr von der radeon-Karte gesetzt werden und man am TV kein Bild bekommt.

    Öhm, und wie lasst ihr den VDR eigentlich laufen?
    vdr-plugin-softdevice ?
    vdr-plugin-xine ?
    vdr-plugin-xineliboutput ?


    Öhm, und was ist vdr-sxfe, und wird das auch verwendet?
    - tut mir leid, VDR ohne FF-Karte ist völliges Neuland für mich.
    - war ja bisher nicht in zufriedenstellender Qualität möglich. :schiel


    EDIT:
    Hehe! Zumindest konnte ich das xine-lib Problem killen. :applaus
    Wenn man experimental schon in der /etc/apt.conf hat, kann man einfach folgendes machen:
    1. apt-get -t experimental build-dep libxine2-vdr
    [Vorsicht! Da werden 100tausend Sachen auf die Platte gekloppt!]
    2. apt-get -t experimental source libxine2-vdr
    3. Ins xine-lib* Verzeichnis gehen und patchen mit dem xine-lib.patch
    4. Dann bauen mit:
    dpkg-buildpackage -tc -us -uc -b


    ABER ohne den gepatchten xserver hilft mir das gar nix! HÜLFE! [schnüff!]

    > ProSavage


    Tut mir leid. Danke nachträglich für die Tipps. :unsch
    Ich hatte das noch einige Tage probiert, dann sind mir die Prüfungen dazwischen gekommen. Deine Tipps haben aber leider nichts geholfen bzw verändert. Ich hatte dann noch probiert das savage-Kernel-Modul anzupassen, um timings anzupassen und/oder mitzuprotokollieren. Bin aber damit nicht weitergekommen; entweder der Chip benötigt tatsächlich irgendeine Minimum-Frequenz, oder kann das Interlacing nicht ordentlich.
    Jedenfalls hat´s mich irgendwann angekotzt und ich "opfere" jetzt wohl doch meine Radeon 9250 für den vdr-Rechner. Es wäre zwar schön gewesen, die onboard-Karte zu nutzen, aber hilft ja nix.... bei euch scheint´s ja mit der Radeon auch schon richtige *Ergebnisse* zu geben. :)


    xine-lib geht übrigens auch nicht:

    Seit ihr zwei die einzigen, die das zum Laufen bekommen haben, oder bin ich nur zu blöd dafür?! :schiel

    Ich hab hier auch auf Lenny aktualisiert, und irgendwie geht bei mir hier gar nichts. :(


    kernel:
    Welchen genauen Kernel nehmt ihr denn her? Nen vanilla, oder den von Debian (der von Debian heißt übrigens anders als in den Anleitungen angegeben)
    Kann das alles hier daran liegen, dass ich mit nem vanilla 2.6.27(.1) rumprobiere?


    drm (via git):
    das baut mir ein Modul, was beim Einfügen aber lauter ungültige AGP-Symbole symbole anzeigt => drm.ko und radeon.ko werden nicht eingefügt.


    xserver-xorg-video:
    Läuft gar nicht durch, da sagt er irgendwas von fehlendem Strichpunkt oder so. Irgendein type ist nicht initialisiert ...
    Das hier müsste aber eigentlich Kernel-unkritisch sein, also was läuft hier schief?. Haben die mittlerweile wieder was am repository geändert?


    Tja, weiter bin ich noch nicht. Tipps?


    [Rant on] genau das meinte ich mit dem Kompilieren. Man verstopft das System mit 100ten libs und dev-Programmen, und am Schluss geht´s doch nicht. Ist's denn wirklich so schwer, die passenden drm.ko, radeon.ko und zumindest das xserver-xorg-vi*.deb hochzuladen?!?


    EDIT
    Ok, jetzt bin ich auf (vanilla-)kernel 2.6.26.6:


    drm:
    Geht scheinbar. Die Module klinken sich ohne Beschwerden ein.
    (allerdings sind die Modul-Daten die selben, wie vor dem patchen; ich hoffe, ich habe alles richtig gemacht)


    xserver-xorg-video-ati vom git, kompiliert mit dpkg-buildpackage:

    Diesmal mit dem patch aus vga-sync-fields-0.0.8 weil der von 0.0.9 gar nicht durch lief. Der 0.0.9er kollidiert irgendwie mit dem debian-patch, der da mit dem ´apt-get source´-paket mitgeliefert wird. Fehler ist aber der selbe wenn man zB beim 0.0.9er den debian-patch ausklammert.


    Tja ohne gepatchten ati-Treiber bin ich verratzt. Hat jemand ein .deb-Paket für mich?