[erledigt] uvesafb kennt richtigen mode nicht

Fortgeschrittener

31.01.2012, 18:09

uvesafb kennt richtigen mode nicht

Hallo,

angestoßen durch den Thread von mnt_gentoo und weil nun endlich gnome3 mit fglrx richtig funktioniert, habe ich gedacht, machst du endlich mal gescheite Konsolenauflösung.
Warum man dazu einen Framebuffer-Treiber benötigt habe ich zwar nicht ganz verstanden, aber einfach mal so akzeptiert.
Habe mir uvesafb installiert nach, spocks Anleitung, und es funktioniert auch.
Mein Bildschirm hat als native Auflösung 1680x1050. Das habe ich dann auch als Kernel Parameter so eingestellt.
Mir kam die Schrift zwar angenehm klein, aber trotzdem unscharf vor. Daher habe ich nochmal nachgebohrt.

Quellcode

# dmesg | grep vesa
[    0.000000] Command line: root=/dev/sda2 video=uvesafb:1680x1050-32
[    0.000000] Kernel command line: root=/dev/sda2 video=uvesafb:1680x1050-32
[    0.335025] uvesafb: (C) 1988-2005, ATI Technologies Inc. , CYPRESS, 01.00, OEM: ATI ATOMBIOS, VBE v3.0
[    0.351313] uvesafb: VBIOS/hardware supports DDC2 transfers
[    0.412532] uvesafb: monitor limits: vf = 75 Hz, hf = 83 kHz, clk = 150 MHz
[    0.412621] uvesafb: scrolling: redraw
[    0.416760] uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
[    0.587894] uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
[    0.773061] uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
[    0.956703] uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
[    1.140376] uvesafb: framebuffer at 0xd0000000, mapped to 0xffffc90010100000, using 11550k, total 16384k
[    3.954613] uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
[   22.944978] uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.

Und siehe da, er kennt den richtigen mode nicht und fällt scheinbar zurück auf 1400x1050.

Quellcode

# cat /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes
640x400-8, 0x0100
640x480-8, 0x0101
800x600-8, 0x0103
1024x768-8, 0x0105
1280x1024-8, 0x0107
640x480-15, 0x0110
640x480-16, 0x0111
800x600-15, 0x0113
800x600-16, 0x0114
1024x768-15, 0x0116
1024x768-16, 0x0117
1280x1024-15, 0x0119
1280x1024-16, 0x011a
320x200-15, 0x010d
320x200-16, 0x010e
320x200-32, 0x0120
320x240-8, 0x0193
320x240-16, 0x0195
320x240-32, 0x0196
512x384-8, 0x01b3
512x384-16, 0x01b5
512x384-32, 0x01b6
640x350-8, 0x01c3
640x350-16, 0x01c5
640x350-32, 0x01c6
720x400-8, 0x0133
720x400-16, 0x0135
720x400-32, 0x0136
1152x864-8, 0x0153
1152x864-16, 0x0155
1152x864-32, 0x0156
1280x960-8, 0x0163
1280x960-16, 0x0165
1280x960-32, 0x0166
640x480-32, 0x0121
800x600-32, 0x0122
1024x768-32, 0x0123
1280x1024-32, 0x0124
1400x1050-8, 0x0143
1400x1050-16, 0x0145
1400x1050-32, 0x0146

Kann ich da jetzt was dagegen tun oder muss ich einfach akzeptieren, dass mit uvesafb was nicht klappt?

Gruß
Foyaxe

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Foyaxe« (03.02.2012, 18:21)

Zum Seitenanfang

josef.95

OSI Layer 8

Beiträge: 7 674

2

31.01.2012, 18:37

Hallo

Doch, uvesafb kennt die von deiner Grafikkarte unterstützten modes schon, das sind die die
/sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes
auflistet.
Sprich, das sind die Modes die von deinem Grafikarten BIOS für den framebuffer unterstützt werden. Ändern wirst du daran wohl kaum etwas können (es sei denn du spielst ein anderes Grafikkarten BIOS ein (eher nicht empfohlen )

Mein Vorschlag wäre: Nutze die für Dich passendste Auflösung und Farbtiefe die deine Grafikkarte ( bzw deren BIOS) unterstützt.

Oder aber nutze den OpenSource (radeon) Treiber mit KMS - da gibt es dann auch gleich passend die native Auflösung deines Displays ;)

Zum Seitenanfang

Foyaxe

Fortgeschrittener

Beiträge: 287

3

31.01.2012, 18:44

Ok, dann kann ich also nichts machen.
Vom radeon Treiber habe ich gerade weggewechselt. War mit ihm zwar sehr zufrieden im Allgemeinen, aber beim Sauerbraten spielen hat er sich oft aufgehängt und hat immer wieder geruckelt.

Ist echt furchtbar mit einer AMD Karte. Man hat die Wahl zwischen dem einen oder dem anderen Übel.
Und der Opensource Treiber ist ja lizenzmäßig gesehen nicht mal richtig open, weil man ja binaries mit einkompiliert, oder?

Zum Seitenanfang

mnt_gentoo

Profi

Beiträge: 807

4

03.02.2012, 15:15

Hallo

Hehe, haben wohl im Moment "alle" irgendwie seichte Problemchen mit ihrem Graka- bzw UVesaFB Graka-Treiber... Also persönlich würde ich sagen, die binaries, die da einkompiliert werden, seien auch OpenSource. Aber das ist nur so ein Gedanke. Das kann ich nicht mit Gewissheit sagen.

NVIDIA/ATI... Sagen wir so, ich weiss nicht, was meine neue ATI bringt, die ich mir heute gekauft habe, sie liegt noch hier im verschlossenen Karton, doch ich möchte sagen, das ich zumindest die letzten 10 Jahre mit AMD bzw vor dem Kauf von ATI durch AMD mit ATI immer sehr sehr zufrieden war. Die ATI Sapphire HD4890, die ich hatte, hat mir niemals irgendwelche Probleme bereitet, die Pro9800 davor, die ich 4 Jahre hatte, auch nicht. Meine Mum hat sich vor einem knappen Jahr ein neues VAIO Notebook (nach langem Überreden) geleistet. Es hat eine NVIDIA-Karte drin, und ich habe um die Performance zu testen dort mal einige Spiele und Furmark usw installiert. Also Furmark läuft bis zum BlueScreen etwa 5min. Die Spiele halten 20min durch. Habs wegen meiner Graka-UVesaFB-Probleme auf gentoo (steht auch in meinem Thread) gestern noch getestet. Einmal hatte ich zwischendurch mal eine ASUS-NVIDIA GT6600. Die konnte ich nur mit ASUS Treibern "füttern". NVIDIA orig-Treiber verweigerten dort ihren Dienst. Hoffe, diese neue ATI, die ich jetzt habe, war kein Fehlkauf und KMS unterstützt sie... Weil UVESAFB wird sonst dasselbe wahrscheinlich wiederholen. Um Testingkernel werd ich wahrscheinlich nicht herumkommen. Und TestingFW auch nicht. Doch ich werds versuchen, keine flgrx nutzen zu müssen. Ich hatte das mal eine kurze Zeit auf Arch (ATI/AMD proprietär) und hatte nur Probleme. HD4890 lief mit dem OpenSource wie eine 1. Auf Arch immer, auf Ubuntu nicht (wegen Unity - aber flgrx war noch schlimmer). Auf gentoo zum Schluss bis zum Ausfall ja auch.

So, bevor ich hier auch anfange, Romane zu schreiben: KMS gefiel mir besser. Auch wenn man das "firmenseitige Panel" zum Einstellen der Graka-Optionen nicht hat. Doch das sehe ich mir persönlich auch in Windows nie an. Die Optionen sollten ohnehin so eingestellt sein "Application controlled". Dann kann jedes Programm sich die Recourcen selbst einteilen. Unter Linux war das Graka Panel sowieso eine Sparausgabe von dem, was man in Windows hat. Dann kann man auch direkt KMS nehmen (wenn es sich anbietet natürlich nur).

Gruß
mnt_gentoo
_________________________________________________________________________________________

Die Launen und das Schicksal eines Gentoo-Users:

...

Zum Seitenanfang

bell

Erleuchteter

Beiträge: 3 128

5

03.02.2012, 16:25

läuft denn die native Auflösung unter X?

Ist im Kernel CONFIG_FIRMWARE_EDID aktiv?

	Quellcode
1 2	│ │ --- Support for frame buffer devices │ │ │ │ [*] Enable firmware EDID │ │

CONFIG_FB_MODE_HELPERS (Enable Video Mode Handling Helpers. Ebenfalls unter "frame buffer devices") könnte auch was bringen.

Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

Zum Seitenanfang

josef.95

OSI Layer 8

Beiträge: 7 674

6

03.02.2012, 16:37

Ansonsten schaut dazu auch in der Kernel Dokumentation -->

	Quellcode
1	/usr/src/linux/Documentation/fb/uvesafb.txt

Zum Seitenanfang

Foyaxe

Fortgeschrittener

Beiträge: 287

7

03.02.2012, 18:20

Zitat von »bell«

läuft denn die native Auflösung unter X?

Ist im Kernel CONFIG_FIRMWARE_EDID aktiv?

Unter X ist die Auflösung wunderbar, sobald fglrx geladen ist.
Habe CONFIG_FIRMWARE_EDID jetzt aktiviert. Scheint keine Änderung zu bewirken, die Ausgabe der vbe_modes ist die gleiche.

In der Dokumentation habe ich gefunden:

Zitat

2. Caveats and limitations
--------------------------

uvesafb is a _generic_ driver which supports a wide variety of video
cards, but which is ultimately limited by the Video BIOS interface.
The most important limitations are:

- Lack of any type of acceleration.
- A strict and limited set of supported video modes. Often the native
or most optimal resolution/refresh rate for your setup will not work
with uvesafb, simply because the Video BIOS doesn't support the
video mode you want to use. This can be especially painful with
widescreen panels, where native video modes don't have the 4:3 aspect
ratio, which is what most BIOS-es are limited to.
- Adjusting the refresh rate is only possible with a VBE 3.0 compliant
Video BIOS. Note that many nVidia Video BIOS-es claim to be VBE 3.0
compliant, while they simply ignore any refresh rate settings.

Genau das habe ich hier.

Bin am Überlegen, ob ich zum radeon Treiber zurück wechseln soll mit KMS. Bei dem Treiber lief gnome außerdem flüssiger.
Allerdings konnte ich mit dem nicht spielen und auch kein OpenCL verwenden.

Mit dem fglrx Treiber habe ich dagegen keine schöne Konsole und ab und zu startet sich Mutter aus heiterem Himmel neu.

Ich bin inzwischen nur noch ein Fan vom Intel Treiber. Der flutscht, obwohl er gar keine vernünftige Grafik unter der Haube hat.

Naja - ist ja auch wurscht jetzt - die Konsole brauche ich eh fast nie und wenn dann ist 1400x1050 auch schon wesentlich angenehmer als 640x480 oder was auch immer ich sonst hätte.
Ich setze mal einfach auf erledigt.

Zum Seitenanfang

mnt_gentoo

Profi

Beiträge: 807

8

04.02.2012, 01:20

Zitat von »Foyaxe«

Ich bin inzwischen nur noch ein Fan vom Intel Treiber. Der flutscht, obwohl er gar keine vernünftige Grafik unter der Haube hat.

Dazu hatte bell mir mal irgendwann etwas Interessantes geschrieben... "Das Intel es richtig macht..." Aber sage es mal so, Auch wenn die Konsole gut ist, (man auch vernünftig die Temperatur erfährt, ist beispielsweise mir immer sehr wichtig), - habe ich die Konsole kaum benutzt. Gar auf Windows nicht. KMS fand ich einfach traumhaft. Auflösung 1920*1200 wie in X. Weiches Umschalten - ohne das der Monitor sekundenlang dunkel bleibt. Naja, aber jedem dasseine. In Archlinux hatte ich mal zu Zeiten meiner 4800er Serie AMD den fglrx installiert. Der war auch langsam. Hatte grundsätzlich asynchrone Videos. Streamin-Flash - noChance. Dort lief der OpenSource auch prächtig...

Ich schlag mich grade durchs Inet um dennoch Linux-Treiber für meine AMD zu finden. Soweit es das AMD-DeveloperCenter angeht, sollen bereits Unterstützungen geben. OpenSource ist wohl in Arbeit. fglrx ist in der "Mache". Es soll auch mit einem anderen FW-blob gehen, das man solange es die neuen nicht gibt, ebenfalls nutzen kann... doch das weiss ich nicht. Wird, wie Du sagtest - wahrscheinlich wirklich "Tahiti" werden...

Gruß
mnt_gentoo
_________________________________________________________________________________________

Die Launen und das Schicksal eines Gentoo-Users:

...

Zum Seitenanfang

GentooForum.de

uvesafb kennt richtigen mode nicht

Quellcode

Quellcode

Quellcode

Quellcode

Zitat von »bell«

Zitat

Zitat von »Foyaxe«

Ähnliche Themen

Verwendete Tags

Häufig verwendete Suchbegriffe: