# Vesafb-TNG..... seltsames Problem.

## Fracoon

Hi@all

Ich habe ein meines erachtens nach sehr seltsames Problem....

Hab im Kernel vesafb-tng aktiviert:

```
<*>   VESA VGA graphics support 

                VESA driver type (vesafb-tng)  --->

                (1280x1024@60) VESA default mode

```

Is auch soweit alles super. Ich hab nen TFT Monitor und desswegen die Bildwiederholfrequenz auf 60Hz gestellt.

Beim Hochfahren erhalte ich wie gewünscht eine Auflösung von 1280*1024 und 60Hz

Sobal ich dann den XServer starte (startet automatisch mit /etc/init.d/xdm) ist auch alles soweit noch in Ordnung.

Wenn ich jetzt aber über Strg+Alt+F1 wieder in die Console wechsle gibt mein Monitor die folgende Meldung aus:

```

            Dies ist 85Hz Overscan,

            Monitor-Einganssignal auf 

            1280*1024@60Hz ändern.

```

Das bild wieder jedoch trotzdem angezeigt.

Jemand ne Idee an was das liegen kann?

----------

## smg

Ich habe ein ähnliches Problem, sobald ich den Xorg gestartet habe und per CTRL-ALT-FX auf VT switchen will, bekomme ich die Meldung: "ungültiger Modus, empfohlener Modus 1280x1024@60" obwohl ich diesen Modus eingestellt habe und beim booten auch diesen Modus bekommen.

Cheers..

----------

## thrashed

geht mir gleich wie euch 2   :Confused: 

----------

## tobo

selbes prob bei mir mit kernel 2.6.14-r2, mit dem 13 läuft alles bestens

----------

## smg

Ich habe eben mal 2.6.15-rcX probiert, ebenfalls Probleme mit vesa-tng.

Cheers.

----------

## smg

Hi, wenn ihr in euere /var/log/messages nach -i vesa grept, was findet ihr da vor? Auch eine Zeile die sagt: VBIOS/HArdware does nto support DDC transfers. (das ist nicht schlimm) aber die näcshjte zeile: no monitor limits have been set. könnt ihr da mal nachgucken? 

cheers.

----------

## Vortex375

Nur so eine Vermutung:

Übergebt ihr beim booten dem kernel einen "video=" parameter?

Bei mir steht da z.B.

```

video=vesafb-tng:1024x768-32@100,mtrr,ywrap

```

Falls nicht einfach mal der grub.conf hinzufügen und schauen was passiert (mit den richtigen Parametern für euren Monitor natürlich).

----------

## smg

Ja, zumindest ich gebe dies so an.

P.S. Ein Tipp noch, dein video=vesafb-tng ist falsch, es sollte nur vesafb heissen.

Cheers.

----------

## Fracoon

hmm... bin ja schonmal froh das ich mit diesem problem nicht alleine bin =)

@ hagbard_

genau die gleichen einträge in /var/log/messages gibt es bei mir auch..... hat das was damit zu tun?? was kann man dagegen tun?

----------

## smg

 *Fracoon wrote:*   

> hmm... bin ja schonmal froh das ich mit diesem problem nicht alleine bin =)
> 
> @ hagbard_
> 
> genau die gleichen einträge in /var/log/messages gibt es bei mir auch..... hat das was damit zu tun?? was kann man dagegen tun?

 

Nunja normalerweise setzt der die Limits... Mit allen Kernels die bei mir mit vesa-tng problemlos liefen haben diese Limits gesetzt. Und bei allen Kernels die ich jetzt probiert habe, bei denen der vesa-tng nicht geht, hat er auch keine Limits gesetzt.. Denke irgendwie ist da nen Fehler im Patch, dass diese Limits nicht gesetzt werden.

Cheers.

----------

## Rawk

Na dann poste ich auch mal meine Probs:

Seit Kernel 2.6.13 wird in der Konsole die Wiederholfrequenz von 84,9 Hz benutzt, obwohl es eigentlich 85 Hz sein sollten.

Ist zwar nicht so tragisch, allerdings hatte ich mit den Versionen zuvor nie Probleme.

Als Kernel-Parameter habe ich folgendes stehen:

```
video=vesafb:ywrap,mtrr,1280x1024-32@85
```

----------

## nic0000

Ich blick jetzt nicht ganz durch ob es bei geholfen hat mit dem "video=" Parameter.

Bei mir hilft es nicht.

Was aber hilft ist, seltsame weise, ein switsch von Terminal 1 auf ein anderes bevor X gestartet wird.

ein

```
echo "chvt 2; chvt 1">>/etc/conf.d/local.start
```

macht bei mir die Konsolen erreichbar.

Ich habe ein LCD und der kann keine @85 hz, mit diesem workaround geht es aber

----------

## x1jmp

Hier ist genau dasselbe seit dem Update auf 2.6.14.

Die Meldung "no monitor limits have been set" kommt auch in meiner /var/log/messages vor.

Zur Zeit benutze ich aufgrund des Fehlers nur noch 1280x1024 antatt 1600x1200 da damit kein Fehler auftritt.

----------

## Mr_Maniac

Ich besitze zwar keinen TFT-Monitor, habe meinen CRT-Monitor mit folgenden Optionen zu 85 Hz bewegen können:

```
video=vesafb:1024x768-32@85,ywrap,mtrr,maxhf:70,maxvf:120,maxclk:100
```

Vielleicht kann man mit den maxhf- und maxvf-Werten da was "reißen"?

----------

## SinoTech

Ahja, interessant. Habe nämlich seit 6.14.X das selbe Problem. Werde es gleich mal ausprobieren.

Mfg

Sino

EDIT:

Bei mir hat sich leider nichts geändert  :Sad: 

----------

## tuxian

Ich hab auch so ein ähnliches Problem mit vesa-tng.

Seit Kernel 2.6.14x sehe ich überhaupt nichts bis kdm gestartet wird. 

Schaltet ich dann auf eine Konsole mit Ctrl+Alt+Fx um sehe ich meine Konsole wieder.

Daher bin ich wieder auf vesa zurückgewechselt!

----------

## py-ro

Hi tuxian,

hatte das selbe Problem, wiess nciht merh welches von beiden die Lösung war also beides:

keinen anderen FB Treiber als den vesa

und kein Modus der nicht in /proc/fb0/modes steht

MfG

Py

----------

## ConiKost

Hi!

Ich habe auch vesatng in benutztung

Ich habe einen CRT.

Wenn ich aber 1024x786-16@100 mache werden trotzdem nur 60 Hz aktiviert.

Warum gehen keine 100? JA, mein CRT kann 100Hz!!!

----------

## tuxian

 *py-ro wrote:*   

> Hi tuxian,
> 
> keinen anderen FB Treiber als den vesa
> 
> Py

 

Hallo,

Was genau meinst du damit?

Nur vesa-tng oder nur vesa?

Werd mal schauen was in /proc/fb0/modes steht denn bevor ich auf vesa zurückgewechselt bin hab ich einige Kernelkonfigurationen ausprobiert, einmal sicher auch nur mit vesa-tng!

----------

## SinoTech

 *tuxian wrote:*   

>  *py-ro wrote:*   Hi tuxian,
> 
> keinen anderen FB Treiber als den vesa
> 
> Py 
> ...

 

Na, denke mal er meint du sollst nur "vesa" benutzen und nicht "vesafb-tng".

Komme heute und morgen leider nicht zum testen (Bin mal wieder bisserl im Stress) aber am WE helf ich dann wieder bei der Lösungssuche  :Smile: .

Mfg

Sino

----------

## py-ro

OK, missdeutig geb ich zu.

Meinte damit vesatng aber keinen riva, nvidia oder sonst einen.

Py

----------

## tuxian

 *py-ro wrote:*   

> OK, missdeutig geb ich zu.
> 
> Meinte damit vesatng aber keinen riva, nvidia oder sonst einen.
> 
> Py

 

Danke, werd ich später probieren.

Die Datei /proc/fb0/modes wird aber nur bei vesa-tng angelegt und nicht bei vesa oder?

----------

## nic0000

 *x1jmp wrote:*   

> Die Meldung "no monitor limits have been set" kommt auch in meiner /var/log/messages vor.

 

Bei mir nicht.... vielleicht geht deshalb bei mir dieser Trick mit dem umschalten der Konsole?

----------

## tuxian

@py-ro:

Danke für den Tipp /proc/fb0/modes !

bei mir steht da folgendes drinnen:

```
640x400-8

640x480-8

800x600-8

1024x768-8

320x200-16

320x200-32

640x480-16

640x480-32

800x600-16

800x600-32

1024x768-16

1024x768-0
```

Also hab ich jetzt in der Kernelconfig CONFIG_FB_VESA_DEFAULT_MODE="1024x768-16" gesetzt und siehe da es funktioniert wieder.

Früher hatte ich es auf "1024x768@60" gesetzt und da hatte es damit funktioniert!

----------

## SinoTech

Tja, bei mir hat es das ganze nur verschlimmert  :Sad: . Jetzt flimmert schon beim booten der screen  :Sad: 

```

$ cat /proc/fb0/modes

1024x768-8

1024x768-16

1024x768-32

640x480-32

800x600-16

800x600-32

640x480-8

800x600-8

640x480-0

```

```

$ grep CONFIG_FB_VESA

CONFIG_FB_VESA=y

# CONFIG_FB_VESA_STD is not set

CONFIG_FB_VESA_TNG=y

CONFIG_FB_VESA_DEFAULT_MODE="1024x768-16"

```

Mein Eintrag in der "grub.conf"

```

title=Gentoo Linux 2.6.14-r5 (Vesafb-tng)

root (hd0,1)

kernel (hd0,1)/vmlinuz root=/dev/hda4 video=vesafb-tng:1024x768-16@60,ywrap,mtrr,maxhf:60,maxvf:60 splash=verbose,theme:e

mergence elevator=cfq 

initrd (hd0,1)/fbsplash-emergence-1024x768

```

Kernel: gentoo-sources-2.6.14-r5

Sonst noch wer einen Tip?

Mfg

Sino

Sonst irgendwer einen Tip?

----------

## smg

Dieses Vesatng ist seit neuestem sehr verbuggt wie ich finde.

Ich benutze nun das alte VESA, dies ist aber auch eher eine suboptimale Lösung...

Cheers.

----------

## tobiasbeil

bei mir erkennt er angeblich das kommando "mtrr" nicht.

er fährt zwar normal in der angegebenen res+hz hoch samt splash,

jedoch, wenn ich meinem xdm sage bitte neustarten, und der

xserver runterfährt und wieder zurück in die console soll, sehe

ich böse anzeigefehler und das system hängt sich auf. ich benutze

übrigends suspend2-2.6.14-r7.

meine cpu ist ein PIV meine graka ne 9800PRO.

wenn ich statt vesafb, radeonfb nehme, dann brabbelt er irgendwas von

no config files found for 8bpp und kommt garnicht erst in die hohe auflösung.

----------

## p4ddY

Hab das selbe Problem..

Bei mir hats geholfen, indem ich "nocrtc" an den video-tag angehängt hab. Problem dabei ist: Ich kann die Wiederholrate nichtmehr bestimmen.. Aber wenigstens gehts.

----------

## der.gecko

mal nebenbei:

wenn ihr vesafb-tng benutzt, muss in der grub.conf trotzdem nur ein "video=vesafb..." stehen.

----------

## UTgamer

Ähm, die Antworten kommen rund 1,5 Jahre zu spät.  :Wink: 

----------

## Max Steel

Jetz konnt ich mir nen Lacher nich verkneifen, hast recht,

aber immerhin wurde es beantwortet.

----------

## der.gecko

ich beantworte grundsätzlich alles und das hat seinen grund.

wenn jemand so anständig ist und zb zuerst die forumssuche benutzt, dann sollte er auch vollständige threads erwarten können^^

----------

## musv

 *der.gecko wrote:*   

> ich beantworte grundsätzlich alles und das hat seinen grund. wenn jemand so anständig ist und zb zuerst die forumssuche benutzt, dann sollte er auch vollständige threads erwarten können^^

 

Sehr vorbildlich. Leider wurde hier bisher eine Frage (aus dem Jahre 2005) noch nicht beantwortet:

 *ConiKost wrote:*   

> Hi!
> 
> Ich habe auch vesatng in benutztung
> 
> Ich habe einen CRT.
> ...

 

Und das Problem hab ich nämlich auch. 

Im Kernel ist eingestellt:

```
CONFIG_FB_VESA_TNG=y

CONFIG_FB_VESA_DEFAULT_MODE="1280x1024-16@85"
```

In der grub.conf steht:

```
kernel /boot/bzImage-2622-r4 video=vesafb:ywrap,1280x1024-16@85 splash=verbose,fadein,theme:alley root=/dev/sda3 snd-emu10k1.index=0 snd-intel8x0.index=1 snd-bt87x.index=2 CONSOLE=/dev/tty1 rw
```

Und sobald ich im Kernelverzeichnis ein "make menuconfig" eingeb, flimmert mir eine Bilderfolge entgegen, was eher an einen Diavortrag erinnert als an einen Monitor.

/var/log/messages schreibt mir folgendes:

```

Aug 20 01:26:18 Blechkasten vesafb: NVIDIA Corporation, NV34 Board - p162-1n , Chip Rev    (OEM: NVIDIA)

Aug 20 01:26:18 Blechkasten vesafb: VBE version: 3.0

Aug 20 01:26:18 Blechkasten vesafb: protected mode interface info at c000:dcd0

Aug 20 01:26:18 Blechkasten vesafb: pmi: set display start = c00cdd06, set palette = c00cdd70

Aug 20 01:26:18 Blechkasten vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da 

Aug 20 01:26:18 Blechkasten vesafb: VBIOS/hardware doesn't support DDC transfers

Aug 20 01:26:18 Blechkasten vesafb: no monitor limits have been set

Aug 20 01:26:18 Blechkasten vesafb: scrolling: ywrap using protected mode interface, yres_virtual=9830

Aug 20 01:26:18 Blechkasten Console: switching to colour frame buffer device 160x64

Aug 20 01:26:18 Blechkasten fbsplash: console 0 using theme 'alley'

Aug 20 01:26:18 Blechkasten fbsplash: switched splash state to 'on' on console 0

Aug 20 01:26:18 Blechkasten vesafb: framebuffer at 0xc0000000, mapped to 0xf8d00000, using 24576k, total 131072k

Aug 20 01:26:18 Blechkasten fb0: VESA VGA frame buffer device

```

Hat jemand 'ne Idee?

----------

## der.gecko

ich denke, dass vesafb-tng einfach noch nicht reif genug ist... bei manchen usern funktioniert es ohne ersichtlichen grund nicht (ich kann das nicht programmieren und kann das deshalb auch nicht nachvollziehen)...

leider wird die vga= anweisung von vesafb-tng ignoriert... 

 *Quote:*   

> Aug 20 01:26:18 Blechkasten vesafb: VBIOS/hardware doesn't support DDC transfers
> 
> Aug 20 01:26:18 Blechkasten vesafb: no monitor limits have been set 

 

sagt ja, dass der monitor, bzw. die graka kein ddc benutzen können, aber das ist ja weiter nicht schlimm, denn du weisst ja, was dein monitor leisten kann und setzt das im kernel und der grub.conf fest.

hier gibt es allerdings eine ausführliche diskussion (ist schon ein wenig älter) zu dem thema, vielleicht bringt dich das weiter, sofern du das nicht schon kennst.

im inet hab ich noch herausgefunden, dass manche biose fehlerhaft sind und die horizontale frequenzen von vesafb-tng ignorieren...

im zweifel musst du vielleicht das "alte" vesafb wieder benutzen, wobei ich da kaum nachteile erkennen kann  :Very Happy: 

----------

## musv

Danke für den Link. Bin dadurch auf: 

http://dev.gentoo.org/~spock/projects/vesafb-tng/

gelandet. Und da steht dann ganz oben:

 *Quote:*   

> WARNING: This project is deprecated. Please use uvesafb instead.

 

Wenn ich mir allerdings die Installationsoptionen von uvesafb durchles, frag ich mich, ob das alles nötig ist. Noch 'nen Daemon im Hintergrund laufen lassen, will ich eigentlich nicht unbedingt. Mal sehen, wenn ich viel Lust hab, werd ich das mal ausprobieren.

----------

