ZitatOriginal von ebsi
Welche Hardware verwendest Du ? Bei mir läuft es nun auch mit dem 0.8.6'er compiz ohne Ruckler.
auch mit diesem Testschnipsel?:
ZitatOriginal von Flachzange
Ich habe mal die Testaufnahme hochgeladen, bei der man an der Laufschrift schön sehen kann, ob es flüssig läuft oder nicht:
Danke für die Mühe
ZitatOriginal von iNOB
In deiner Kernelconfig sollte für KMS das hier stehen:CodeCONFIG_AGP=y CONFIG_AGP_INTEL=y CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=yNähere Infos gibts dazu auch hier. Ich benutze z.B. den 2.6.35.10er. Den Rest hab ich alles aus dem git zusammengeklöppelt, inkl. Compiz
Wie schon vorher hier irgendwo geschrieben, sollte KMS in den neueren Kernel-Versionen per default aktiv sein. Bei mir werden die benötigten kernelmodule ja auch geladen und die Ausgaben im log deuten auch daraufhin, dass es funktioniert.
Zugegeben, meine Informationen waren etwas spärlich. Ich habe natürlich versucht den kompletten Stack zu bauen
1)Kernel 2.6.35, 37 und 38 probiert
2) libdrm 2.4.23 (git)
3) intel driver 2.14.0
4) mesa 7.10 (git)
5) libva 1.0.10 (git)
6) xserver 1.9.4
Ich habe ja auch nichts geupdated....Hatte vorher keine xserver packages etc drauf, sondern alles from scratch gemacht. Wenn ich das richtig verstanden habe, ist für die Funktion des xservers ja eigentlich nur Punkt 1, 2, 3 und 6 relevant. Mesa und libva sollten den blanken xserver ja eigentlich nicht jucken. Mich irritiert halt, dass der 2.13er Treiber funktioniert. Gefühlt tippe ich ja auf irgendetwas mit dem Kernel bzw. den Kernelmodulen, aber selbst verschiedene Kernelversionen bringen da keine Besserung. Aber kann auch gut sein, dass ich irgendwo in der Kette noch was falsch gemacht habe.
So. Habe heute noch mal einen xserver 1.9.4 vom Scratch erstellt (Ubuntu 10.10 minimal) und mich an diese Anleitung gehalten:
http://www.linuxfromscratch.or…iew/svn/x/installing.html
Soweit so gut. Mit dem 2.14er Intel-Treiber bekomme ich nun immer folgende Fehlermeldung und diese ziemlich oft:
(EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Invalid argument.Die Grafikausgabe sieht kaputt aus. Version 2.13 funktioniert. Google hat mir noch nicht die Erleuchtung gebracht, aber vielleicht habt ihr ja eine Idee.
Christoph
Einen Hinweis dazu: Framedrops werden bei mir nur angezeigt, wenn ich keinen Composite Manager benutze. Schalte ich einen Composite Manager hinzu verschwinden die Framedrops auf wundersame Weise aus dem Log, obwohl es natürlich nachwievor "ruckelt".
Nachtrag: Die schlechte Bildqualität habe ich nur mit Compiz und aktiviertem vsync.
Also ich hatte sowohl xfwm4 und compiz 0.9.2.1 ausprobiert. Mit xfwm4 hatte ich tearing als auch das Problem, dass das OSD nicht transparent war. Compiz 0.9.2.1 habe ich schon zweimal selbst gebaut und beide Male nicht richtig ans laufen bekommen.
Aber unabhängig davon, sollte das ganze nicht auch ruckelfrei ohne composite manager laufen? Denn das tut es bei mir ja nachwievor mit der vaapi xine-lib nicht (siehe oben). Kann mir irgendwie nicht vorstellen, dass der compositter das wieder ausbügelt.
ZitatOriginal von wbreu
Einen davon teste ich gerade, damit läuft das Aufnahmeschnippsel von Flachzange völlig ruckelfrei.
Ich bin gespannt 
Nabend zusammen,
danke für eure Berichte.
ZitatOriginal von wbreu
Nabend,
heute habe ich mir mal das "Ruckeln" mit 720p-Sendern angeschaut, es kommt eindeutig nur vor, wenn in der xorg.conf Composite eingeschaltet ist und damit auch mit einem Compositer gearbeitet werden kann.
Das kann ich so nicht ganz bestätigen.
1) xine-lib-vaapi ruckelt bei mir immer. Egal ob compositting aktiviert oder deaktiviert.
2) xine-lib normal läuft flüssig. Egal ob compositting aktiviert oder deaktiviert. Mit Compiz und Hardware-OSD habe ich aber die gleichen unschönen Effekte wie mit der vaapi xine-lib.
Könntet ihr beiden vielleicht mal die Aufnahme testen, die ich oben verlinkt habe und mir anschließend berichten, ob die Laufschrift flüssig läuft?
Also ich kann nur für 720p50 sprechen. Was anderes habe ich hier nicht zur Verfügung.
Ich habe jetzt noch mal den Referenztest gemacht und die xinelib ohne vaapi genommen. Das läuft flüssig und ordentlich. Sobald vaapi aktiviert ist habe ich entweder ein ruckeln oder tearing (je nach Einstellungen). Mit compiz und aktiviertem vsync hab ich zwar kein tearing/ruckeln, aber die Bildqualität ist schlecht. Ich habe mal die Testaufnahme hochgeladen, bei der man an der Laufschrift schön sehen kann, ob es flüssig läuft oder nicht:
http://rapidshare.com/files/447056979/00001.ts
Ich ziehe mich jetzt erst mal zurück von den Tests. Mir fehlt dafür schlicht die Zeit.
Moin, ich bin auch wieder am Boden der Tatsachen angekommen. Zuvor hatte ich immer nur einfach bei laufendem TV-Betrieb entschieden, ob das Bild ok ist. Jetzt habe ich mir mal so eine kurze Testaufnahme gemacht, bei der eine Laufschrift durchs Bild geht. Jetzt bekomme ich es selbst ohne HUD / ohne composition nicht mehr hin ein flüssiges Bild zu erhalten. Entweder Tearing oder Ruckeln.
Ich traue es mich ja kaum zu sagen, aber ich habe einen Erfolg zu vermelden...
Eine triviale Google-Suche nach "xine compiz ruckeln" hat mich dazu veranlasst das vsync im Compiz selbst zu aktivieren (compizconfig settings manager => Allgemeine Einstellungen). Das nervige Ruckeln ist jetzt tatsächlich weg...unfassbar. Jetzt kämpfe ich noch mit Bildqualitätseinstellungen. Insbesondere bei Laufschriften wird das deutlich: Selbst bei ARD HD mit 720p sieht das aus wie mit einem schlechten Deinterlacer. Bin mal gespannt, ob ich das auch noch irgendwie in den Griff bekomme.
Edit: Also das liegt auf jeden Fall an Compiz. Echt verrückt, welchen Einfluss das hat.
Compiz an mit vsync: Bild ruckelfrei aber besagte Bewegungsunschärfe
Compiz an ohne vsync: Bild ruckelt aber keine Bewegungsunschärfe
Ich muss jetzt noch mal den Referenztest ohne Compiz machen. Das habe ich heute morgen nicht mehr geschafft.
Also das Problem mit dem schwarzen Hintergund habe ich mit Compiz nich, nur mit allen anderen Compositting Engines
Moin zusammen,
danke für den Hinweis mit xfwm4. Das habe ich direkt mal getestet. Metacity wollte ich vorher schon probieren, aber da mein Ubuntu meinte es müsste den kompletten Desktop installieren, habe ich es dann erstmal gelassen.
So...mit xfwm4 habe ich folgendes Problem, welches ich übrigens auch bei metacity hatte (Ich nehme an, dass Debian per default das compositting von metacity nimmt):
Starte ich vdr-sxfe, ist der Bildschirm zunächst schwarz. Das OSD wird aber angezeigt. Erst wenn ich beispielsweise mit Alt-Tab ein anderes Fenster aktiviere, wird mir das TV-Bild angezeigt. Dann aber kein OSD mehr. Das TV-Bild ist ruckelfrei. Das gleiche Verhalten hatte ich schon mal ein paar Seiten vorher beschrieben, als ich meine ersten Versuche mit der Debian-Installation gemacht hatte.
Meine Vernutung: Transparenz funktioniert nicht. Das Vollbild OSD hat 100% opacity und überlagert demnach immer das TV-Bild.
Meine Frage: Wie bekomme ich das in den Griff?
Danke und Gruß
Christoph
0.8.6
Nachtrag: Ich hatte gestern mal auf dem Debian System versucht die 0.9.2.1 selbst zu bauen. Maken und installieren war kein Problem, es lief aber irgendwie nicht so wie ich dachte, aber ich kann das noch mal auf dem minimal system jetzt testen..ist auch übersichtlicher.
Gibt ja jetzt auch irgendwie nicht so viele Fenstermanager mit Compositing Engine. Bin gerade über Metisse gestolpert. Das wird aber wohl nicht mehr gepflegt und segfaulted beim Starten.
ZitatOriginal von Atechsystem
Flachzange: Ich habe dieses Ruckeln ja auch (bei ServusTV). Vielleicht hat das ja den selben Grund. Ich werde "nur compiz" jedenfalls mal ausprobieren.
Nachdem wbreu ja meinte man solle nicht so schnell aufgeben, habe ich mich heute noch mal rangesetzt und ein Ubuntu minimal aufgesetzt. Man muss dazu sagen, dass ich eigentlich nur Desktop-Systeme oder Comandline-Systeme kenne. Mit Fenstermangern und Co. habe ich mich noch nicht beschäft. Ich bin also schon stolz darauf es geschafft zu haben einen blanken X mit compiz zum Laufen gebracht zu haben
Leider die ernüchternde Nachricht: Ruckeln mit aktiviertem Compiz. Welche Alternative zu Compiz hab ich?
ZitatOriginal von Atechsystem
Ich werde meine XBMC-PVR Tests erstmal einstellen. Da hilft erstmal nur abwarten. Bezüglich des Deinterleacing bei verwendung der VAAPI im XBMC komme ich nicht weiter. Es gibt dort bei mir einfach kein Deinterleacing
Das habe ich auch noch nicht geschafft.
ZitatOriginal von Atechsystem
Ich werde jetzt erstmal mit der normalen Dharma weitertesten.
Dharma läuft bei mir mit dem Patch absolut perfekt.
ZitatOriginal von hoschi78
Mit o.g. hab ich auch immer recht störende "Streifen" bei HD+ oder Sky HD... kanns nicht so genau beschreiben.. sieht so aus als ob die obere Hälfte des Bildschirms schon ein Bild weiter is als die untere..
Setz doch mal in der config_xineliboutput: video.device.xv_sync_to_vblank:1
Ohne vsync und ohne compiz habe ich die Streifen auch.
Hallo Bernhard,
das sind ja mal gute Nachrichten...wird mit dem Treiber auch das CI gehen?
Grüße
Christoph
ZitatOriginal von Atechsystem
benutzt du keinen desktop manager bzw. wenn doch welchen? Wie "dockst" du compiz daran an?
Das frage ich mich auch....
ZitatOriginal von Copperhead
Hmm? Desktop (wie KDE, Gnome) und VDR widerspricht sich. Entweder Desktop oder VDR.
Das ist sicherlich abhängig von den persönlichen Vorlieben....aber gehört hier auch nicht hin.
Ich resigniere jetzt bei meinen VAAPI-Versuchen. Mit Dual-Channel RAM läuft es jetzt ohne compiz/hud reproduzierbar flüssig. Mit compiz/hud ruckelt es nachwievor in gleicher Stärke. Für den Gegentest habe ich noch mal Ubuntu 10.10 istalliert und die halbwegs aktuellen xorg-Pakete und Treiber für das edgers ppa nachinstalliert. Ich habe auch mal mein BIOS auf die Defaults gesetzt, um zu vermeiden, dass ich hier was kaputt ist, aber wie immer gilt: gleiches Ergebnis.
Ich bin jetzt etwas gefrustet und werde wieder meine G210 einbauen. Obwohl ich die integrierte Lösung mit der Intel-Grafik bevorzugt hätte (alleine schon weil es technich interessant ist), tut sich bei der Leistungsuafnahme im VDR nichts; nur im XBMC und im Idle zieht die Kiste dann mehr.
Falls jemand noch Ideen hat....
Gruß
Christoph
@64bit
Ich habe hier auch 64Bit. Beim kompilieren gibts eigentlich nie Probleme.
@KMS
Sollte das nicht mittlerweile per default im Kernel aktiv sein?
Edit: Auszug aus dmesg
Jan 30 17:18:04 carla kernel: [ 6.092272] [drm] Initialized drm 1.1.0 20060810
Jan 30 17:18:04 carla kernel: [ 6.151440] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jan 30 17:18:04 carla kernel: [ 6.180046] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
Jan 30 17:18:04 carla kernel: [ 6.567588] fb0: inteldrmfb frame buffer device
Jan 30 17:18:04 carla kernel: [ 6.567589] drm: registered panic notifier
Jan 30 17:18:04 carla kernel: [ 6.567601] No ACPI video bus found
Jan 30 17:18:04 carla kernel: [ 6.567749] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Laut der ober verlinkten Seite läuft KMS also und ich habe da nichts per Hand aktiviert.
Mach doch mal ein make && make install auf den vdr. Vermutlich liegt es daran, dass die packages von tobi anders gebaut sind, aber wenn du Pech hast laufen anschließend die anderen Plugins nicht mehr. Ein Versuch wäre es aber wert....