Am Sonntag 28 März 2010 schrieb Eduard Bloch:
> #include <hallo.h>
require "hallo.rb"
> * Martin Steigerwald [Sun, Mar 28 2010, 03:47:53PM]:
> > Also ich mit insgesamt bislang *ausgesprochen* zufrieden mit Radeon
> > KMS. Hab nicht ansatzweise erwartet, dass das so problemlos
> > funktionieren würde.
>
> Problemlos? Ich habe heute mal meine Onboard-Karte aktiviert, um mal
> den Zustand der Treiber zu begutachten. Mit stinknormaler
> 785G-Onboard-Grafik. Ergebnis: XVideo geht in 4 von 5 Fällen NICHT
> mehr, auch wenn ich DRI- und exa-Optionen in xorg.conf setze. Im Log
> finde ich diesbezüglich nichts auffälliges, exa wird aktiviert.
> Google-Hits bzgl. "radeon-Modul früher laden" passen auch nicht, es
> wird schon früh geladen.
Heute bliebt TuxOnIce bei "Seeking to free xx MB of memory" hängen. Da
hatte ich zwei KDE 4-Sitzungen mit DRI2 und OpenGL-Compositing offen. Und
mein Skript hat schon längst mit chvt 1 auf TTY1 umgeschaltet. Obs nun an
TuxOnIce oder Radeon KMS liegt, kann ich noch nicht sagen.
Ansonsten XVideo läuft bei mir. Einziges Problem, was ich bislang nur mit
einem Video mit Dragon Player hab: Das Bild flackert hin- und her, so als
ob jemand in kurzen Abständen vor- und zurückspulen würde.
Ich glaub ich hab in der xorg.conf nicht mehr viel gesetzt. Höchsten noch
Altlasten. Mal sehen:
Section "Device"
Identifier "Grafikchip"
## Radeon-Treiber
Driver "radeon"
Option "AGPMode" "4"
# Benötigt laut ThinkWiki.org CONFIG_FB_RADEON
Option "DynamicClocks" "true"
# 3D beschleunigen: Laut glxgears von ca. 1690 fps auf 2880 fps,
Yieeeha ;-), 6.7.2008
# http://dri.freedesktop.org/wiki/R300Benchmark
Option "EnablePageFlip" "true"
# EXA auch mit xserver-xorg-video-radeon 6.12.2-2 ein CPU-Fresser,
22.5.2009
#Option "RenderAccel" "no"
#Option "AccelMethod" "xaa"
# Für AROS
#Option "BackingStore" "True"
## Monitore
Option "Monitor-LVDS" "Notebook-Display"
Option "Monitor-VGA-0" "VGA-Ausgang"
EndSection
Ja, das EnablePageFlip kann evtl. noch raus... alles andere außer AGPMode
4, was ich als sinnvoll empfand, da AFAIR laut X.org-Protokoll ein
langsamerer Modus zum Einsatz kam, ist eh auskommentiert. Naja,
DynamicClocks halt auch, aber ob das auch mit dem KMS Framebuffer-Treiber
tut?
> Und Suspend-To-Ram weckt die Karte nicht auf. Da frage ich mich
> ernsthaft, was der Quatsch mit KMS denn soll. Die gleiche
> Hardware-Konfiguration lief vor ein Paar Monaten nahezu problemlos mit
> Kernel 2.6.32 (ohne KMS). Die Flackersekunde beim Umschalten hat mich
> auch nie gestört.
Suspend-To-Ram hab ich noch nicht probiert. Ich ziehe es vor, den
Arbeitsspeicher komplett auf Platte zu haben.
Ich bleibe also dabei: *Bislang* *erstaunlich* wenig Probleme. Und mir ist
X.org auch noch nicht einmal weggekachelt. Wie in einer früheren Mail von
mir in diesem Thread passierte das davor beim Betrieb mit zwei Sitzungen
häufig.
Also für *mich* ist es bislang stabiler und gefühlt *deutlich* schneller
als der vorherige Zustand.
martin@shambhala:~> lspci -nn | grep VGA
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350
[Mobility Radeon 9600 M10] [1002:4e50]
martin@shambhala:~> cat /proc/version
Linux version 2.6.33.1-tp42-toi-3.1-04961-gac10b02 (martin@shambhala) (gcc
version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9) ) #2 PREEMPT Wed Mar
24 22:12:58 CET 2010
Da im Debian 2.6.32-4 aber der DRM-Code von 2.6.33 drin ist, sollte das
keinen großen Unterschied machen.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.