# [UPDATE] Getting higher refresh rates using vesafb driver

## spock_

Getting higher refresh rates using vesafb driver

For quite some time I have seen people posting questions about getting higher-than-standard refresh rates on their vesafb consoles. The usual answer was: 'this is impossible'. While I was installing Gentoo during the last few days, I started to get really angry with my 1024x756@60Hz. It was at this time that I realized 'impossible' isn't exactly the right word here. I came up with a solution - a kernel patch that allows you to change the refresh rate of any VESA graphic mode. 

Here is what you will need to get your console up and running at a high refresh rate:a VBE 3.0 compliant graphic card (most modern cards seem to be VBE 3.0 compatible - my GeForce 2 MX 400 is, and other nVidia cards are too, AFAIK)

Linux Kernel v2.6.x source tree located at /usr/src/linux

some data about your monitor - its maximal vertical/horizontal refresh rate and its bandwidth (pixel clock)

a few minutes to setup everything

and of course the patch (old version here) itself..

UPDATE: The old rrc patch is now obsolete! Please go to http://dev.gentoo.org/~spock/#vesafb-tng for info about the new patch and its capabilites. Please test and report your results to my e-mail. Thanks in advance!

vesafb-tng troubleshooting

vesafb-tng fails with 'vesafb: abort, cannot ioremap video memory ...'

Add vram:16 to your video boot options. If you had: 

```
video=vesafb:ywrap,1024x768-16@85
```

 change it to read: 

```
video=vesafb:ywrap,vram:16,1024x768-16@85
```

 ioremapping problems are caused by large amounts of video RAM. Standard vesafb automatically limits used memory to 16MB. vesafb-tng doesn't, that's why it's necessary to specify the vram option.

I can't find a mode that works properly.

Try specifying both noedid and nocrtc video options at the same time. This should make vesafb-tng use a VBE mode with standard refresh rate (60Hz). It's not nice, but it's a good starting point in checking that everything works. And you can always correct it with fbset  :Smile: 

How do I use fbset to increase my refresh rate?

You have to download the modeline2fb.pl  script and call it while in X, in a graphic mode you want to have on the console:

```
xvidtune -show | ./modeline2fb.pl >> /etc/fb.modes
```

This will add a mode to the fb.modes database. You can then use this mode:

```
fbset <horiz_res>x<vert_res>
```

 for example 

```
fbset 1024x768
```

UPDATE: The patch has been updated to work on x86_64 arch.

And here is what to do:Download the patch.

Unpack it somewhere and make sure you have a look at the README file.

```
tar -jxvf vesafb-rrc-0.1.6-2.6.x.tar.bz2
```

Copy the actual patchfile to /usr/src/linux.

```
cp vesafb-rrc-0.1.6-2.6.x.bz2 /usr/src/linux
```

Patch your kernel tree.

```
cd /usr/src/linux

bzip2 -dc vesafb-rrc-0.1.6-2.6.x.bz2 | patch -p1
```

Run a script to set the CRTC data (this an equivalent of XFree86 Modelines).

```
chmod u+x /usr/src/linux/scripts/vesa_modeline_gen.pl

/usr/src/linux/scripts/vesa_modeline_gen.pl
```

Enter the data you are asked for (maximum vertical and horizontal refresh rate and monitor/graphic card max bandwidth). You should be able to find these values in your monitor and graphic card documentation or in the Internet [remember: Google is your best friend!  :Smile: ]. If you do everything properly, you will be informed that the generated data has been written to /usr/src/linux/arch/i386/boot/vesafb_modes.h

Recompile your kernel now. If you have everything else configured, you will only need to make bzImage. When the recompilation is finished, move the kernel image to your /boot partition.

```
make bzImage

mount /boot

mv /boot/bzImage /boot/bzImage.old

cp /usr/src/linux/arch/i386/boot/bzImage /boot
```

Find a new mode number. You can use the following table:

```
    | 320x200  640x480  800x600  1024x768  1280x1024

----+-----------------------------------------------

256 |   N/A     0x501    0x503    0x505      0x507

32k |  0x50D    0x510    0x513    0x516      0x519

64k |  0x50E    0x511    0x514    0x517      0x51A

16M |  0x50F    0x512    0x515    0x518      0x51B
```

Modify your /boot/grub/grub.conf by putting your chosen mode number as the vga= kernel parameter. Here is an example:

```
title=Gentoo Linux 2004.0

root=(hd0,0)

kernel=(hd0,0)/boot/bzImage root=/dev/hda3 vga=0x518 

```

Note: You can still use all these modes with their standard refresh rates - just change the leading '5' to '3' in the mode number.

Unmount /boot, reboot and enjoy your framebuffer console at a high refresh rate. Mine is running perfectly in 1024x756 @ 85Hz  :Smile: 

Note that so far I haven't had the opportunity to test it on boxes other than my own. Your feedback will be welcomed. Have fun!Last edited by spock_ on Mon Jun 21, 2004 4:09 pm; edited 5 times in total

----------

## Moled

how are the mode numbers calculated btw?

my monitor can do 1600x1200 @ 85 Hz which would be nice

----------

## floam

How about a patch for 2.[56] kernels?  :Smile: 

----------

## lucida

I just tried this on 2.6.0-test2-mm2

patch, run the script and compile fine, but I still get 1024x768@60 even I pass vga=0x517(instead of 0x317) to kernel.

My video card is a radeon8500 which should be vbe 3.0 compatible  :Sad: 

----------

## spock_

To answer all your questions:

Mode numbers are calculated by adding 0x400 to the original VESA mode number or adding 0x200 to the Linux mode number. As far as I know there is no standard 1600x1200 VESA mode, so this probably won't work. However, if your monitor can do 85Hz at 1600x1000 you should be able to get ~100Hz at 1280x1024 (which would be quite nice as well  :Smile: ).

I just checked it with 2.6.0-test2. Works perfectly for me. I think it's safe to assume that it will work with 2.5.x, too.

I don't know if Radeon 8500 is VBE3.0 compatible (I wasn't able to find anything on Google either). You may want to have a look at this patch. Just download it, put in /usr/src/linux and do:

```
bzip2 -dc patch-2.4.x-vesafb-rrc-2.bz2 | patch -p1
```

on your already-patched source tree. This will add some info about VBE version at boot time. If you have VBE < 3.0 you should get a message about it. Your VBE version will be shown too. If after applying this patch there is still no info about the VBE version, please post your /usr/src/linux/arch/i386/boot/vesafb_modes.h.

----------

## Eediot

 :Very Happy: 

thank you!!  I got this to work on a GF ti4200,  linux-2.4.20-gentoo-r5.  Well worth the reboots. I get 85hz at 1024x768.  the tough part was getting the vesafb_modes.h set right, the default was off center by an inch, eventually  I ran  xvidtune  and copied the settings into vesafb_modes.h using the discription there. 

There is an error in the readme included with the patch, 

 *Quote:*   

> ModeLine "resolution" RefreshRate
> 
>                          x HorizontalSyncStart HorizSyncEnd HorizSyncTotal
> 
>                          y VerticalSyncStart VertSyncEnd VertSyncTotal

 

as compared to  vesafb_modes.h. which works.

 *Quote:*   

> # Format:     HorizontalSyncTotal, HorizontalSyncStart, HorizontalSyncEnd
> 
> #             VerticalSyncTotal, VerticalSyncStart, VerticalSyndEnd
> 
> #             Flags (0 = hsync+, vsync+; 12 = hsync-, vsync-; 8 = hsync-, vsync+, 4 = hsync+, vsync-)
> ...

 

on my laptop (ati rage mobility) the script failed with:   Invalid maximal vertical refresh rate. 

I will copy and edit the good modes.h  to try and get it to work...

thanks again.

----------

## spock_

I'm glad it works for someone, I was just starting to get afraid I did smth wrong  :Wink:  vesafb_modes.h can be pretty annoying, but as far as I know there is no way to set it up 100% correcly using a fully automated method.

The error in readme is actually not an error  :Smile:  Readme describes format of an X modeline as compared to vesafb_modes.h own, similar, but different format. I deliberately put the X modeline desc into the readme so that people could compare it with vesafb_modes.h format. I guess I'll have to clear this up a bit  :Smile: 

The script fails when you enter VR > 300 or < 56 or if you enter something that is not recognized as a number by Perl. There was a small bug in it, though (one that I have just corrected). The error msgs from dialog were redirected to stdout, so even if you entered a valid value an error would be reported in case of any dialog error/warning.

----------

## Peaceable Frood

I'm getting that error, and I don't know what to do. 

My max vert is 160

My max horiz is 70

My bandwidth is 110

----------

## Config

Hmmm.... after running the perl script, I get "Invalid maximal vertical refresh rate".  I'm sure that my monitor can do it without problems (It can do 50-160hz, and even default values don't work)... may be a bug   :Question: 

----------

## Config

I just had a closer look at the script (but I'm not familiar with perl!), and the lines producing the errors are:

die "Invalid maximal vertical refresh rate.\n" if ($max_vf > 300 || $max_vf < 56);

die "Invalid maximal horizontal refresh rate.\n" if ($max_hf > 300 || $max_hf < 30);

die "Invalid maximal bandwidth.\n" if ($max_bw > 300 || $max_bw < 30);

Since I don't know perl, I don't know what's wrong with it.... I just commented them out and tried it again (Vertical: 160, Hor: 96, band: 85). The resulting vesaftb_modes.h is:

```

# The contents of this file were generated automatically.

# Please do not modify them, unless you are sure what you're doing.

# Format:     HorizontalSyncTotal, HorizontalSyncStart, HorizontalSyncEnd

#             VerticalSyncTotal, VerticalSyncStart, VerticalSyndEnd

#             Flags (0 = hsync+, vsync+; 12 = hsync-, vsync-; 8 = hsync-, vsync+, 4 = hsync+, vsync-)

#             Pixel Clock Rate (Hz)

#             Vertical Refresh Rate (in units of 0.01 Hz)

#define VIDEO_VESAFB_CRTC_DATA

# 320x200 @ 0Hz

        .word   456, 344, 424

        .word   240, 214, 214

        .byte   0

        .long   0

        .word   0

        .space  40

# 640x400 @ 0Hz

        .word   904, 680, 840

        .word   440, 414, 414

        .byte   4

        .long   0

        .word   0

        .space  40

# 640x480 @ 0Hz

        .word   904, 680, 840

        .word   520, 494, 494

        .byte   12

        .long   0

        .word   0

        .space  40

# 800x600 @ 0Hz

        .word   1128, 848, 1048

        .word   640, 614, 614

        .byte   0

        .long   0

        .word   0

        .space  40

# 1024x768 @ 0Hz

        .word   1416, 1080, 1320

        .word   808, 782, 782

        .byte   0

        .long   0

        .word   0

        .space  40

# 1280x1024 @ 0Hz

        .word   1736, 1344, 1624

        .word   1064, 1038, 1038

        .byte   0

        .long   0

        .word   0

        .space  40

```

Does this look correct? I fear trying it out, since the regular script didn't work without tweaking....

[Edit]

Sorry for this one - this surely looks very bad. I better didn't try it... I added 3 lines to the script:

```
$max_vf = 160;

$max_hf = 96;

$max_bw = 85;
```

The above then creates a rather valid file, but under 1280*1024, it calculated only 46.01hz? That's very odd, since it can do 89hz on that resolution....

[/edit]

----------

## spock_

Yes, there was a bug in the script. I introduced it after Eediot's post. I have now corrected it. You can either unpatch your current source tree (or start with a new one) and redownload the patch or change this lines in scripts/vesa_modeline_gen.pl [(...) are the messages dialog displays]:

```

$max_vf =`dialog (...) 8 40 100`;

$max_hf =`dialog (...) 8 43 70`;

$max_bw =`dialog (...) 13 70 100`;

```

to:

```

$max_vf =`dialog (...) 8 40 100 2>&1`;

$max_hf =`dialog (...) 8 43 70 2>&1`;

$max_bw =`dialog (...) 13 70 100 2>&1`;

```

(Simply add 2>&1 just before `; )

If you are not satisfied with the results of this script, you may wish to input CRTC data by hand. First set your X to the desired resolution (which would be 1280x1024 in your case) and start xvidtune program from a terminal. Click the 'show' button in xvidtune and look at your terminal for the modeline data it outputs. Then have a look at the README attached to the patch for info about modeline and vesafb_modes.h format and put your data in vesafb_modes.h. Shall you have any doubts, you can simply put the modeline from xvidtune in this thread and I'll reformat it for you  :Smile: 

----------

## Config

Wow, thanks for that... well I just tried to do it manually, but i haven't been able to figure everything   :Embarassed: 

Here is my xvidtune output:

```
 "1280x1024" 157.50 1280 1344 1504 1728    1024 1025 1028 1072 +hsync +vsync

```

What I came up so far is:

```
# 1280x1024 @ 86.62Hz

        .word   1728, 1344, 1504

        .word   1072, 1025, 1028

        .byte   0

        .long   160000000

        .word   8662

        .space  40

```

The first two lines are easy... then it gets tuff   :Embarassed: 

Thanks a LOT!! I hope I can get it work. I tried already with my "patched script", but it didn't work. On starting, my screen made the noise,  it always does when changing resolution/refreh rate, but the sound never stopped and I didn't get any output....

----------

## spock_

OK, here is a 'translation'  :Wink:  for you:

```

# 1280x1024 @ 86.62Hz

        .word   1728, 1344, 1504

        .word   1072, 1025, 1028

        .byte   0

        .long   157500000

        .word   8662

        .space  40 

```

You have done it quite well yourself  :Smile:  Try it now. If it works in X, it should work with framebuffer as well.

----------

## Config

Wohooo!!! It's working! I just changed one line: 

```
.word 8662 
```

to

```
.word 8502 
```

May be, this did the trick. Anyhow, this patch is great, and if you (I would be willing to help   :Very Happy: ) I hope it would get included in the mainstream kernel

----------

## spock_

It seems that putting a slightly lower values than the best monitor/video card can do could be helpful. I found than I can get best results using 97 MHz as the bandwidth limit, while my monitor can actually do 108 MHz (according to the specs).

It's nice to see that it works for someone.. So far we have.. mhm.. 3 happy users (including myself  :Wink: ). It's something.. for the start  :Wink:  I have serious doubts whether anyone would be interested in including this to main kernel tree (and certainly noone would want to do so if there were 3 users interested in it  :Wink:  But in time - who knows..  :Wink: ). However - maybe one day someone would think it's useful enough to be included in gentoo-sources or somewhere else where people could make use of it.

Anyway - thanks for your feedback and support  :Smile: 

----------

## Config

Hey! MANY people said, that they were unhappy with the 60hz provided... and when I think of it: What about a SuSE Linux installation with these 80hz? I'm sure SuSE would love it! I'm asking myself, which distro doesn't use the framebuffer per default - so any nvidia user will be too happy, uncluding me   :Very Happy: 

I'll have a look at the patch now. May be I can figure how it works (I don't really know assembler, just a little, so there is a problem  :Rolling Eyes:  )

----------

## lucida

 *spock_ wrote:*   

> To answer all your questions:
> 
> I don't know if Radeon 8500 is VBE3.0 compatible (I wasn't able to find anything on Google either). 
> 
> 

 

Thanks for the new patch, it indicates that radeon8500 is only VBE 2.0 compatible. I still can't believe this though.  :Rolling Eyes: 

----------

## Config

But doesn't the radeon have its own framebuffer driver - a hardware accelerated one?

----------

## Eediot

the script still  doesn't work  on the laptop. I never see a dialog just the result of the die line, I added a line to print out the varibles and got:

```
thinker linux # ./scripts/vesa_modeline_gen.pl

max_vf = sh: line 1: dialog: command not found

     max_hf = sh: line 1: dialog: command not found

     max_bw= sh: line 1: dialog: command not found

Invalid maximal vertical refresh rate.

```

is my perl setup broken?

inserted at line 19 of the  updated patch:

```
print "max_vf = $max_vf     max_hf = $max_hf     max_bw= $max_bw \n";
```

----------

## Config

You can do 

```
 emerge dialog 
```

 and the error will be gone   :Wink: 

----------

## Eediot

thanks, gentoo's too obvious for me  :Wink: 

----------

## lucida

 *Config wrote:*   

> But doesn't the radeon have its own framebuffer driver - a hardware accelerated one?

 

but...

1. On 2.6, I can't make it work. I always get 640x480@60 with radeonfb.

2. On 2.4, I can't make it work with mplayer.

not mentioning the crappy cursor.  :Sad: 

----------

## dberkholz

If y'all like it and haven't run into any problems, post it to LKML as a patch.

----------

## spock_

Ok, enough is enough. I have just decided to get rid of this stupid dialog which seems to cause more problems than it solves. I have put an updated version of the patch on my site. The Perl script now has only a simple STDIN/STDOUT based interface, but it's fully functional and just as easy to use as it was before  :Wink: 

Since some people found this patch useful, if no new problems/bugs are reported today, I'll post this patch to LKML, as suggested by spyderous.

----------

## pYrania

going to try it in some hours (currently recompiling complete portage tree)

but should be nice, if it's working.

```

# 1024x768 @ 120Hz

        .word   1416, 1080, 1320

        .word   808, 782, 782

        .byte   0

        .long   137295360

        .word   12000

        .space  40

# 1280x1024 @ 92.1Hz

        .word   1736, 1344, 1624

        .word   1064, 1038, 1038

        .byte   0

        .long   170128000

        .word   9210

        .space  40

```

----------

## Config

 *lucida wrote:*   

>  *Config wrote:*   But doesn't the radeon have its own framebuffer driver - a hardware accelerated one? 
> 
> but...
> 
> 1. On 2.6, I can't make it work. I always get 640x480@60 with radeonfb.
> ...

 

I can't make it work under 2.6 either (well, I can use the framebuffer, but bootsplash doesn't work. 

mplayer? I compiled it with svga and directb, fbcon, and I can run any movie with mplayer -vo svga <filename>....

----------

## viperlin

ok just feedback:

kernel: 2.4.20 vanilla with bootsplash patches and loopAES.

graphics card: Geforce 4 MX440

Monitor: Compaq MV920

works fine.

and thanks for bringing this to my attention, the flickering was annoying.

----------

## Config

I just looked at the 2.6.0-test2 kernel vesafb.c, and it looks a lot different - so I don't think the patch would work  :Sad: 

----------

## FormerSlacker

Another success story. I've got my bootsplashed vesafb console running at 1024x768 @ 80hz!

Kernel: 2.4.21 vanilla with bootsplash and i2c patches

Video Card: Geforce 2 GTS

I had to use the output of xvidtune to configure the vesa header file. The supplied perl script worked, but the picture was shifted to the left side of the monitor (I probably put in the wrong values  :Wink: ).

Aside from that, it works perfectly it seems

Thanks alot spock!      :Surprised: 

----------

## spock_

As to 2.6.0-test2, there is nothing to think about, since the patch has already been tested with this kernel and has proven to work as well as it does with 2.4.x  :Smile:  The thing is - the patch itself has actually nothing to do with vesafb.c. While vesafb.c is the main part of VESA framebuffer driver, the switch from standard 80x25 text mode to selected VESA graphic mode takes place at boot time, while the CPU is still in real mode. My patch alters video.S code, allowing the user to select a "modified" mode with the refresh rate he/she chooses.

----------

## Config

Uh... I'm stupid   :Laughing: 

I didn't even check which file gets patched - I'll try it out as soon as possibel  :Very Happy: 

----------

## spock_

Have fun with it  :Smile:  Just patch the kernel-tree and copy your vesafb_modes.h file to make it as painless as possible  :Wink: 

----------

## pYrania

my monitor gets out of sync when trying it. I'm pretty sure the bandwith documented in the monitors manual is wrong.

max. horizontal: 98 kHz

max. vertical: 120 Hz

Bandwith: 202,5 MHz

any idea?

----------

## spock_

Try setting the bandwidth to lower values - smth like 150MHz or even 125 or 100 MHz. Making max. vert. 115 Hz and max. horiz. 95 won't hurt either. If nothing helps, forget about the script, start X with the resolution you use on console, run xvidtune and copy the values to /usr/src/linux/arch/i386/boot/vesafb_modes.h as described in README and earlier in this thread.

----------

## LinuxDolt

is the file linked to in the beginning of the thread being kept recent?  maybe you ought to start using some form of versioning and make an ebuild for it too...  it sure wouldn't hurt  :Razz: 

i am just wondering because i've noticed you've been patching the patch so to speak during the duration of this threads life...

----------

## spock_

The only thing that was changed during this thread's existence is the configuration script. The old version used dialog and at some point I came to the conclusion that it's not really necessary - and so I changed it. The core assembly code hasn't changed a bit. So - the link at the beginning of the thread still points to the current version. Shall there be any non-trivial modifications to the patch - I will make sure versioning is included  :Smile: 

As to the ebulld - I'm not sure it would make any sense since what its function would be just to download the patch and patch /usr/src/linux. However, if you think having an ebuild for it would be nice, I can and will make one and submit it to the bugzilla system as soon as I finish a few other ebuilds I wish to contribute  :Smile: 

----------

## schlehmil

thanks a lot spock_

this patch is working well for me with 1024x768@100hz.

----------

## Cicero

 *Eediot wrote:*   

> 
> 
> thank you!!  I got this to work on a GF ti4200,  linux-2.4.20-gentoo-r5.  Well worth the reboots. I get 85hz at 1024x768.  the tough part was getting the vesafb_modes.h set right, the default was off center by an inch, eventually  I ran  xvidtune  and copied the settings into vesafb_modes.h using the discription there. 
> 
> 

 

Exact same experience here. Possibly a bug in the script's calculations? It's something small, as the numbers were not off by much, but none of them exactly matched xvidtune's output. I don't know how everything is calculated, so I can't help  :Sad: .

Except for that, everything went flawlessly. I can stare at my purty bootsplash now (thanks to the >1GB patch) and not have my eyes bleed. Thanks!

----------

## Blurpy

This is great! I'm now running a vesa framebuffer at 1024x768@90hz. I tried to get 85hz, and it somehow became 90hz. It doesn't matter as my monitor can handle it.

I did it the manual way with xvidtune, on a vanilla kernel. Finally no more 60hz and headache  :Very Happy: 

----------

## spock_

Hmm.. it seems the script really needs some 'adjustments'. I'll try to do something about it. If you wish to help, please send me (in a PM or to my e-mail account) the correct ModeLine from xvidtune/XFree86 config file and input data you used (max. vert., max. horiz., max. band.) or vesafb_modes.h the script generated.

I will also delay posting the patch to LKML until I'm able to find a better CRTC calculation routine or determine that one cannot be written  :Smile: 

----------

## LinuxDolt

spock:

i personally do not know anything about doing the actual code, however, you may want to take a look at the following page, i find that it's routine is quite accurate for finding x modelines...  i'm not sure about the conversion to svga fields however...  this is just my attempt at being helpful for a project that looks VERY promising to me, if i am completely off, then may the powers that be correct me for it (namely you obviously)...

http://koala.ilog.fr/cgi-bin/nph-colas-modelines

----------

## spock_

The modeline counting part of my script is almost a direct 'fscking Lisp' to Perl  conversion of the routine you pointed to (yeah, I know, Lisp might be great when it comes to AI, but doing some VESA calculations is nothing like AI and Perl is just great for almost everything  :Wink: ). So not only you are completely off, you are very accurate.

If Colas' routine does work for you and my script doesn't, please let me know (an error in conversion?).

----------

## LinuxDolt

 *spock_ wrote:*   

> If Colas' routine does work for you and my script doesn't, please let me know (an error in conversion?).

 well... i haven't exactly gotten around to using yours with the full capabilities of my hardware (i am capable of 90 rr at 1280x1024 but only targeted 85 in yours)

maybe i'll give my kernel another recompilation and see if feeding it some more stressing/less conservative data does ok...  i'll leave ya know my findings...  i just spend a heck of a lot more time in x than in console, so my x rr matters a little more than my console rr, and i didn't want to risk borking my vesa support...

----------

## Blurpy

I just noticed that my cdroms doesn't work anymore when using the patched kernel. There is no /dev/cdroms/cdrom[0,1] anymore, and /dev/scsi is also gone. But if I boot an unpatched kernel they are back. I have not changed anything in the kernel config, so the only difference is the refresh rate patch.

Have anyone else noticed this?

----------

## spock_

It's very improbable that the patch changes devfs behaviour in any way. Any modifications that are being made do not even come close to the devfs code. Try reversing the patch on an already patched tree and then compile the kernel without making any changes to your configuration. If this makes cdrom and scsi reappear, please tell me what kernel version are you using and what your hardware is (cpu, video card, cdrom).

----------

## Blurpy

How do I reverse the patch?

----------

## spock_

The same way you applied it  :Smile:  Just do:

```
bzip2 -dc patch-2.4.x-vesafb-rrc.bz2 | patch -p1
```

 and patch should ask if you want to reverse the patch. If somehow this doesn't work, you could enforce it, by adding '-R':

```
bzip2 -dc patch-2.4.x-vesafb-rrc.bz2 | patch -p1 -R
```

----------

## Blurpy

I did a make mrproper, and it seemed to fix it. It's working now.

----------

## spock_

Nice, I knew the patch have nothing to do with it  :Wink: 

If you can, please msg me with your proper modelines and result from vesafb_mode_gen,pl. So far only Cicero has sent me some data. Without more info I will probably not be able to make any corrections. Come on, don't be too egoistic, you might have had to configure everything by hand, but let's just make it a little easier for the ones who will be using this in the future  :Wink: 

----------

## b3rT

another tip: if you are using lilo it could be nessesary to write the vga-value not as hex but as decimal (espectially with older lilo-versions).

btw: works great...thx  :Very Happy: 

----------

## grzewho

will the patch get into official gentoo-sources ?

----------

## spock_

Thx for the tip b3rT. Someone having lilo as his bootloader might find it useful  :Smile:  I use grub so hex values are no problem for me.

As to whether this patch will get into gentoo-sources - that's a question you need to ask a developer, not me  :Smile:  I'll probably post it to bugzilla sooner or later. It will be posted sooner if I get more data about the modelines  :Smile:  So far the script has been downloaded more than 1000 times and yet only two people PM'ed me with some info (thx Cicero & Blurpy).

----------

## lurid

Ok, excuse me if I'm a bit slow here..  but I'm a little confused as to what numbers to put in here.  The manual for my moniter gives me numbers that only allow 60hz as the max for 1280x1024..  and thats what I've used for awhile but the America's Army LiveCD detected something or other and bumped the monitor up to 75hz at that resolution.  Much nicer.   :Wink:   Anyhow, I've copied the Vert/Horiz sync rates from the temp XF86Config file on the LiveCD to my real one and it works fine. But heres the problem.  I'm not sure what the max rates are, because my manual apparently isn't correct.  Either that or I'm really pushing my monitor.  :Wink: 

If I run xvidtune I get

```
"1280x1024"   135.00   1280 1296 1440 1688   1024 1025 1028 1066 +hsync +vsync
```

How does that translate to what I should be entering in the script or manually in vesafb_modes.h?

----------

## spock_

First you should generate vesafb_modes.h using the script. Then change the last section so that it would look just like this:

```

# 1280x1024 @ 135Hz

        .word   1688, 1296, 1440

        .word   1066, 1025, 1028

        .byte   0

        .long   135000000

        .word   7500

        .space  40 

```

----------

## lurid

Oh thats beautiful.  Works perfectly on 2.6.0-test2-mm1.  I'm curious how you got those numbers for the vesafb_modes.h file.  It'd be nice to know in case I ever reinstall I'd know what to do.

----------

## spock_

Have a look at README included with the patch, it's all described there  :Smile:  Actually, the whole thing is pretty easy and you'll find that the vesafb_modes.h data is just a modeline written in a slightly different format.

----------

## grzewho

the patch works perfectly for me! i`m running gentoo-sources-2.4.20-r6 with bootsplash and the console looks fresh`n`funky  :Very Happy: 

thanks a lot for your great work!!!

dobra robota  :Smile: 

----------

## spock_

Well, I just wanted to tell you that a new version of the patch will be coming in the near future (sooner or later - it might be later as I'll be AFK for a week or so) and that I would really, really very much appreciate input from users of non-nvidia video adapters (modelines and any other useful info you can provide).

----------

## thadk

 *spock_ wrote:*   

> To answer all your questions:
> 
> Mode numbers are calculated by adding 0x400 to the original VESA mode number or adding 0x200 to the Linux mode number. As far as I know there is no standard 1600x1200 VESA mode, so this probably won't work. However, if your monitor can do 85Hz at 1600x1000 you should be able to get ~100Hz at 1280x1024 (which would be quite nice as well ).

 

So the  VGA=838 (0x346? or maybe 0x546 following the differences in charts between patched/unpatched) I pass to the kernel for 1600x1200 is nonstandard then I suppose  :Confused: . Sorry to pester ya but unfortunately my monitor isn't nearly as logical as you suggest and only runs at the slightly tiny 1024x768 for a crystal 120hz, while leaving 1280x1024 at the average 85, same as 1600x1200. Much thanks for the fix though even if I can't run it quite as perfect as I'd wish  :Very Happy:  !

Edit: Well it looks like it proved me wrong and pulled SXGA at 100hz and beautifully, eye gogglingly beautifully. No idea why it refuses to do it under Windows or (afaik) X--"Out of Scan Range". I had to work myself upto starting X again. I did try using 0x546 but all it did was load at 1280x1024@100Hz with a 640x480ish (or smaller) region of console. Probably from the hard coded bits. Also anyone else have consistent problems getting in with the 0x51B setting? I had to use 0x51A.

BTW, is there any way to have a dual-headed console? When I'm in my XFCE4 WM my second display flashes all kinds of gibberish rectangular characters all over it and it's sort of annoying, no idea why and pretty much only in XFCE I think.

----------

## spock_

Yes, 1600x1200 is definitely non-standard. VESA VBE 3.0 specification defines only the modes I mentioned in the table in my first post in this thread. It's up to the display vendor to define any other modes and so the mode numbers may vary from one video adapter to another. I have no way of checking anything higher than 1280x1024 out as my monitor doesn't support these :/

But since the non-standard modes are already there, it would be nice to have them supported in the patch, now wouldn't it?  :Wink:  I guess I will add support for them in the next version, which, as I said will be coming soon. It seems it would also be necessary to add a special option to list all available VESA modes at bootup.

As for the refresh rate at 1280x1024 - if you can get 85Hz at 1600x1200 you just have to be able to run at a higher refresh rate at at 1280x1024 - it's the maths, you can't cheat it  :Wink:  Please post the data from 1280x1024 part from /usr/src/linux/arch/i386/boot/vesafb_modes.h and I'll try to tweak it for you a bit  :Smile:  You might also want to check one more or less crazy idea - get modeline data about 1600x1200 from xvidtune -show and then put this data in 1280x1024 section. With luck, next time you use, say 0x51A, you will get a nice 1600x1200 mode (unfortunately the console won't cover all screen - it will stay at 1280x1024 so part of the screen will remain unused.

----------

## thadk

Yep, got 1280x1024@100Hz against my prior experiences, check my edit: I wrote the original before I excecuted your patch.

As to the other stuff: Not tonight--slumping over in my chair, will try tommorow though, thanks for the response too.

Edit Of course I couldn't wait. Heh, but no didn't seem to work--nothing changed. You might want to check my conversion though. Or maybe it was a kernel compile mistake. All I did was add the edits, do another `make bzImage` and transfer the images around.

```
"1600x1200"   229.50   1600 1664 1856 2160   1200 1201 1204 1250 +hsync +vsync
```

to

```

# 1280x1024 @ 100.56Hz

        .word   1736, 1344, 1624

        .word   1064, 1038, 1038

        .byte   0

        .long   185752000

        .word   10056

        .space  40

#"1600x1200" @ 85Hz

#   "1600x1200"   229.50   1600 1664 1856 2160   1200 1201 1204 1250

        .word   2160, 1664, 1856

        .word   1250, 1202, 1201

        .byte   0

        .long   229500000

        .word   8500

        .space  40
```

According to my specs the monitors is 30-107KHz, 50 to 120 Hz and 261MHz.

----------

## spock_

Here is a corrected version:

```

#"1600x1200" @ 85Hz

        .word   2160, 1664, 1856

        .word   1250, 1200, 1201

        .byte   0

        .long   229500000

        .word   8500

        .space  40

```

You had 1202 instead of 1200 in the third line. Note that you will need to delete the 1280x1024 settings from above. Getting 1600x1200 is not like adding yet another mode, it's like overwriting 1280x1024 (or any other mode) settings. It's a dirty trick but it has been reported to work. Good luck with it  :Smile: 

As for the dual-headed displays, I have no experience with it, perhaps someone else will be able to help.

----------

## thadk

Not sure how that 1202 got to 1200 when I cut/pasted but amazingly I translated it right. After commenting out the 1280x1024 entry I can now switch between the framebuffer and X without the lengthy monitor modeswitching.

Thanks yet again. good luck on getting it into the kernels  :Smile: .

----------

## aLEczapKA

Kernel: 2.4.20-gentoo-r5

GC: GeForce2 Ultra

I did everything like written here, got vesa_modeline_gen.pl run well, /usr/src/linux/arch/i386/boot/vesafb_modes.h  also got as I far I could tell proper entries, recompiled the kernel add boot option and this was exacly the problem.

When I try to pass vga=0xSOMETING from the table about resolution I got error - unsupported vesa mode (or something like this).

I have vesa frame buffer compiled into the kernel.

What could be a problem here?

----------

## spock_

And did the framebuffer work with an vga=0x<num> option before applying the patch? If it did, you could try patching an already patched kernel tree with this patch (as described earlier in this thread) to check your VBE version. If it didn't, you'll have to wait till the next version of this patch is out.

----------

## aLEczapKA

Yes, it worked before and as it seems it works now also - I tried with some different number and recompiled the kernel with the patch2... 

There is also one issue still.. I have some strange lines on the top of the screen... could it be because the script only allows bandwith from 30-300 and my monitor has bandwith of 340Mhz?

I try to increase the range and try again.

I really would like to fix it cause this rox!!!

----------

## aLEczapKA

Oki I reversed patch2 and it works also. So the problem was I tried to pass wrong numbers from the res table.. but the issue with strange lines is still there.. 

I lowered my monitor settings: is better now but still some lines on the very top of the screen are messed up.. it's like 5-10 lines...

will keep on trying..

----------

## FileZilla

I tried to use the patch on my system, I'm using a Radeon 9600 Pro. Unfortunately it didn't work. The 2nd patch reports that the VBE version of my card is just 2.0

Is there any way to get this patch working with VBE 2.0 cards?

----------

## cripwalk

Thank you spoc! This works perfect with my Geforce Ti4600.

----------

## Malice

Another happy customer here.

Running 1280x1024@85 on Nvidia Gf4 Ti.

The numbers generated by your perl script weren't identical to the ones output by xvidtune (only slightly different), so I changed them to match the xvidtune ones.

My aim was to get it so that my monitor didn't have to change anything when switching between X and console windows.  Mission accomplished.

Thanks for the good work Spock!

----------

## tom.barbeau

This is all very exciting but somehow I cannot make it work better than 60Hz  :Sad: 

I have an Asus A7N8X mobo with GeForce4 MX440 on a D1025TM (DELL) monitor. 

I tried the manual way with xvidtune and also the script way. Everytime it comes up with 60Hz. Another strange thing I noticed is that I cannot get 1024x768 in fb mode, getting the message:

(using vga=0x517) 

```
You passed an undefined mode number ... 
```

I can get the bootsplash in 800x600 or 640x480, but always with 60Hz.

Any idea?

Thx

----------

## Angrybob

My motherboard is an asus A7V600, my gfx card is a GeforceFX 5900 and my monitor is a dell P991 which i run at 1280x1024@85Hz in X and Windows. I'm using gs-sources version 2.4.22_pre2-gss.

I've applied both of your patches and have vga=0x51A in my lilo.conf but i cant get 85Hz! i still get 1280x1024 with a background picture but its only 60Hz.

The output of the script using the values 120, 107, 157.50 is this:-

```

# 1280x1024 @ 85.26Hz

        .word   1736, 1344, 1624

        .word   1064, 1038, 1038

        .byte   0

        .long   157500000

        .word   8526

        .space  40

```

After looking at the output of xvidtune I've changed it to this:-

```

# My mode :)

        .word   1728, 1344, 1504

        .word   1072, 1025, 1028

        .byte   0

        .long   157500000

        .word   8502

        .space  40

```

However neither of them work!

btw, something i didnt quite understand..,. does the second patch allways print out info about your version of VBE or only if it isnt v3...and will it show up in dmesg either way? as i said i applied both patches but i cant see anything from my dmesg output about VBE... maybe i just didnt recompile the kernel properly  :Smile: 

here's my dmesg output

```

Linux version 2.4.22_pre2-gss (root@alex) (gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, propolice)) #12 Sat Aug 23 19:46:26 BST 2003

BIOS-provided physical RAM map:

 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)

 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)

 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)

 BIOS-e820: 0000000000100000 - 000000002fffc000 (usable)

 BIOS-e820: 000000002fffc000 - 000000002ffff000 (ACPI data)

 BIOS-e820: 000000002ffff000 - 0000000030000000 (ACPI NVS)

 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)

 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)

 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)

767MB LOWMEM available.

ACPI: have wakeup address 0xc0001000

On node 0 totalpages: 196604

zone(0): 4096 pages.

zone(1): 192508 pages.

zone(2): 0 pages.

ACPI: RSDP (v000 ASUS                       ) @ 0x000f62b0

ACPI: RSDT (v001 ASUS   A7V600   16944.11825) @ 0x2fffc000

ACPI: FADT (v001 ASUS   A7V600   16944.11825) @ 0x2fffc0b2

ACPI: BOOT (v001 ASUS   A7V600   16944.11825) @ 0x2fffc030

ACPI: MADT (v001 ASUS   A7V600   16944.11825) @ 0x2fffc058

ACPI: DSDT (v001   ASUS A7V600   00000.04096) @ 0x00000000

ACPI: BIOS passes blacklist

ACPI: Local APIC address 0xfee00000

ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)

Processor #0 Pentium(tm) Pro APIC version 16

ACPI: LAPIC_NMI (acpi_id[0x00] polarity[0x1] trigger[0x1] lint[0x1])

ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0])

IOAPIC[0]: Assigned apic_id 2

IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, IRQ 0-23

ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x1])

ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x3] trigger[0x3])

Using ACPI (MADT) for SMP configuration information

Kernel command line: BOOT_IMAGE=Gentoo-Old ro root=305

Initializing CPU#0

Detected 1400.084 MHz processor.

Console: colour dummy device 80x25

Calibrating delay loop... 2791.83 BogoMIPS

Memory: 774288k/786416k available (2028k kernel code, 11740k reserved, 705k data, 128k init, 0k highmem)

Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)

Inode cache hash table entries: 65536 (order: 7, 524288 bytes)

Mount cache hash table entries: 512 (order: 0, 4096 bytes)

Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)

Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)

CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)

CPU: L2 Cache: 256K (64 bytes/line)

Intel machine check architecture supported.

Intel machine check reporting enabled on CPU#0.

CPU:     After generic, caps: 0383fbff c1cbfbff 00000000 00000000

CPU:             Common caps: 0383fbff c1cbfbff 00000000 00000000

CPU: AMD Athlon(TM) MP 1600+ stepping 02

Enabling fast FPU save and restore... done.

Enabling unmasked SIMD FPU exception support... done.

Checking 'hlt' instruction... OK.

POSIX conformance testing by UNIFIX

enabled ExtINT on CPU#0

ESR value before enabling vector: 00000000

ESR value after enabling vector: 00000000

ENABLING IO-APIC IRQs

init IO_APIC IRQs

 IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.

..TIMER: vector=0x31 pin1=2 pin2=0

number of MP IRQ sources: 16.

number of IO-APIC #2 registers: 24.

testing the IO APIC.......................

 

IO APIC #2......

.... register #00: 02000000

.......    : physical APIC id: 02

.......    : Delivery Type: 0

.......    : LTS          : 0

.... register #01: 00178003

.......     : max redirection entries: 0017

.......     : PRQ implemented: 1

.......     : IO APIC version: 0003

.... IRQ redirection table:

 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:

 00 000 00  1    0    0   0   0    0    0    00

 01 001 01  0    0    0   0   0    1    1    39

 02 001 01  0    0    0   0   0    1    1    31

 03 001 01  0    0    0   0   0    1    1    41

 04 001 01  0    0    0   0   0    1    1    49

 05 001 01  0    0    0   0   0    1    1    51

 06 001 01  0    0    0   0   0    1    1    59

 07 001 01  0    0    0   0   0    1    1    61

 08 001 01  0    0    0   0   0    1    1    69

 09 001 01  1    1    0   1   0    1    1    71

 0a 001 01  0    0    0   0   0    1    1    79

 0b 001 01  0    0    0   0   0    1    1    81

 0c 001 01  0    0    0   0   0    1    1    89

 0d 001 01  0    0    0   0   0    1    1    91

 0e 001 01  0    0    0   0   0    1    1    99

 0f 001 01  0    0    0   0   0    1    1    A1

 10 000 00  1    0    0   0   0    0    0    00

 11 000 00  1    0    0   0   0    0    0    00

 12 000 00  1    0    0   0   0    0    0    00

 13 000 00  1    0    0   0   0    0    0    00

 14 000 00  1    0    0   0   0    0    0    00

 15 000 00  1    0    0   0   0    0    0    00

 16 000 00  1    0    0   0   0    0    0    00

 17 000 00  1    0    0   0   0    0    0    00

IRQ to pin mappings:

IRQ0 -> 0:2

IRQ1 -> 0:1

IRQ3 -> 0:3

IRQ4 -> 0:4

IRQ5 -> 0:5

IRQ6 -> 0:6

IRQ7 -> 0:7

IRQ8 -> 0:8

IRQ9 -> 0:9

IRQ10 -> 0:10

IRQ11 -> 0:11

IRQ12 -> 0:12

IRQ13 -> 0:13

IRQ14 -> 0:14

IRQ15 -> 0:15

.................................... done.

Using local APIC timer interrupts.

calibrating APIC timer ...

..... CPU clock speed is 1399.9910 MHz.

..... host bus clock speed is 266.6649 MHz.

cpu: 0, clocks: 2666649, slice: 1333324

CPU0<T0:2666640,T1:1333312,D:4,S:1333324,C:2666649>

mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)

mtrr: detected mtrr type: Intel

ACPI: Subsystem revision 20030619

PCI: PCI BIOS revision 2.10 entry at 0xf1970, last bus=1

PCI: Using configuration type 1

ACPI: Interpreter enabled

ACPI: Using IOAPIC for interrupt routing

ACPI: System [ACPI] (supports S0 S1 S4 S5)

ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)

ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled)

ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled)

ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled)

ACPI: PCI Interrupt Link [LNKE] (IRQs *3 4 5 6 7 9 10 11 12 14 15)

ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 9 10 11 12 14 15)

ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)

ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 *15)

ACPI: PCI Root Bridge [PCI0] (00:00)

PCI: Probing PCI hardware (bus 00)

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]

PCI: Probing PCI hardware

ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10

ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5

ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11

IOAPIC[0]: Set PCI routing entry (2-18 -> 0xa9 -> IRQ 18)

00:00:09[A] -> 2-18 -> IRQ 18

IOAPIC[0]: Set PCI routing entry (2-19 -> 0xb1 -> IRQ 19)

00:00:0c[A] -> 2-19 -> IRQ 19

IOAPIC[0]: Set PCI routing entry (2-16 -> 0xb9 -> IRQ 16)

00:00:0c[B] -> 2-16 -> IRQ 16

IOAPIC[0]: Set PCI routing entry (2-17 -> 0xc1 -> IRQ 17)

00:00:0c[C] -> 2-17 -> IRQ 17

Pin 2-18 already programmed

Pin 2-16 already programmed

Pin 2-17 already programmed

Pin 2-18 already programmed

Pin 2-19 already programmed

Pin 2-17 already programmed

Pin 2-18 already programmed

Pin 2-19 already programmed

Pin 2-16 already programmed

Pin 2-18 already programmed

Pin 2-19 already programmed

Pin 2-16 already programmed

Pin 2-17 already programmed

Pin 2-19 already programmed

Pin 2-16 already programmed

Pin 2-17 already programmed

Pin 2-18 already programmed

Pin 2-16 already programmed

Pin 2-17 already programmed

Pin 2-18 already programmed

Pin 2-19 already programmed

IOAPIC[0]: Set PCI routing entry (2-20 -> 0xc9 -> IRQ 20)

00:00:0f[A] -> 2-20 -> IRQ 20

Pin 2-20 already programmed

IOAPIC[0]: Set PCI routing entry (2-21 -> 0xd1 -> IRQ 21)

00:00:10[A] -> 2-21 -> IRQ 21

Pin 2-21 already programmed

Pin 2-21 already programmed

Pin 2-21 already programmed

IOAPIC[0]: Set PCI routing entry (2-22 -> 0xd9 -> IRQ 22)

00:00:11[C] -> 2-22 -> IRQ 22

Pin 2-22 already programmed

Pin 2-16 already programmed

Pin 2-17 already programmed

PCI: Using ACPI for IRQ routing

PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'

PCI: Via IRQ fixup for 00:10.0, from 3 to 5

PCI: Via IRQ fixup for 00:10.1, from 3 to 5

PCI: Via IRQ fixup for 00:10.2, from 7 to 5

PCI: Via IRQ fixup for 00:10.3, from 7 to 5

Linux NET4.0 for Linux 2.4

Based upon Swansea University Computer Society NET3.039

Initializing RT netlink socket

Starting kswapd

imon (inode monitor), $Revision: $

devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)

devfs: boot_options: 0x1

NTFS driver v1.1.22 [Flags: R/O]

ACPI: Power Button (FF) [PWRF]

ACPI: Processor [CPU0] (supports C1)

vesafb: framebuffer at 0xe8000000, mapped to 0xf080a000, size 20480k

vesafb: mode is 1280x1024x16, linelength=2560, pages=1

vesafb: protected mode interface info at c000:e140

vesafb: scrolling: redraw

vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0

Looking for splash picture.... silenjpeg size 75071 bytes, found (1280x1024, 26385 bytes, v3).

Console: switching to colour frame buffer device 153x54

fb0: VESA VGA frame buffer device

pty: 256 Unix98 ptys configured

Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled

Real Time Clock Driver v1.10e

Non-volatile memory driver v1.2

Floppy drive(s): fd0 is 1.44M

FDC 0 is a post-1991 82077

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

loop: loaded (max 8 devices)

Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)

PCI: Enabling device 00:0b.0 (0004 -> 0007)

tulip0:  MII transceiver #1 config 3100 status 7829 advertising 01e1.

eth0: Lite-On 82c168 PNIC rev 32 at 0xf1c13000, 00:C0:F0:4E:68:ED, IRQ 19.

PPP generic driver version 2.4.2

PPP Deflate Compression module registered

PPP BSD Compression module registered

Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx

VP_IDE: IDE controller at PCI slot 00:0f.1

VP_IDE: chipset revision 6

VP_IDE: not 100% native mode: will probe irqs later

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx

VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci00:0f.1

    ide0: BM-DMA at 0x9400-0x9407, BIOS settings: hda:DMA, hdb:pio

    ide1: BM-DMA at 0x9408-0x940f, BIOS settings: hdc:DMA, hdd:pio

hda: WDC WD1200JB-00DUA0, ATA DISK drive

blk: queue c03fc580, I/O limit 4095Mb (mask 0xffffffff)

hdc: SAMSUNG DVD-ROM SD-612, ATAPI CD/DVD-ROM drive

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

ide1 at 0x170-0x177,0x376 on irq 15

hda: attached ide-disk driver.

hda: host protected area => 1

hda: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=14593/255/63, UDMA(100)

hdc: attached ide-cdrom driver.

hdc: ATAPI 32X DVD-ROM drive, 512kB Cache, UDMA(33)

Uniform CD-ROM driver Revision: 3.12

Partition check:

 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 >

usb.c: registered new driver usbdevfs

usb.c: registered new driver hub

ehci_hcd 00:10.4: VIA Technologies, Inc. USB 2.0

ehci_hcd 00:10.4: irq 21, pci mem f1c19000

usb.c: new USB bus registered, assigned bus number 1

PCI: 00:10.4 PCI cache line size set incorrectly (32 bytes) by BIOS/FW.

PCI: 00:10.4 PCI cache line size corrected to 64.

ehci_hcd 00:10.4: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-19/2.4

hub.c: USB hub found

hub.c: 8 ports detected

host/uhci.c: USB Universal Host Controller Interface driver v1.1

host/uhci.c: USB UHCI at I/O 0x9000, IRQ 21

usb.c: new USB bus registered, assigned bus number 2

hub.c: USB hub found

hub.c: 2 ports detected

host/uhci.c: USB UHCI at I/O 0x8800, IRQ 21

usb.c: new USB bus registered, assigned bus number 3

hub.c: USB hub found

hub.c: 2 ports detected

host/uhci.c: USB UHCI at I/O 0x8400, IRQ 21

usb.c: new USB bus registered, assigned bus number 4

hub.c: USB hub found

hub.c: 2 ports detected

host/uhci.c: USB UHCI at I/O 0x8000, IRQ 21

usb.c: new USB bus registered, assigned bus number 5

hub.c: USB hub found

hub.c: 2 ports detected

usb.c: registered new driver hiddev

usb.c: registered new driver hid

hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>

hid-core.c: USB HID support drivers

mice: PS/2 mouse device common for all mice

NET4: Linux TCP/IP 1.0 for NET4.0

IP Protocols: ICMP, UDP, TCP

IP: routing cache hash table of 8192 buckets, 64Kbytes

TCP: Hash tables configured (established 262144 bind 65536)

klips_info:ipsec_init: KLIPS startup, FreeS/WAN IPSec version: super-freeswan-1.99.7.3

klips_info:ipsec_alg_init: KLIPS alg v=0.8.1-0 (EALG_MAX=255, AALG_MAX=15)

klips_info:ipsec_alg_init: calling ipsec_alg_static_init()

ipsec_aes_init(alg_type=15 alg_id=12 name=aes): ret=0

ipsec_aes_init(alg_type=14 alg_id=9 name=aes_mac): ret=0

ipsec_serpent_init(alg_type=15 alg_id=252 name=serpent): ret=0

ipsec_twofish_init(alg_type=15 alg_id=253 name=twofish): ret=0

NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.

RAMDISK: Couldn't find valid RAM disk image starting at 0.

Freeing initrd memory: 99k freed

reiserfs: checking transaction log (device 03:05) ...

reiserfs: replayed 1 transactions in 0 seconds

Using r5 hash to sort names

ReiserFS version 3.6.25

VFS: Mounted root (reiserfs filesystem) readonly.

Mounted devfs on /dev

Freeing unused kernel memory: 128k freed

hub.c: new USB device 00:10.0-1, assigned address 2

input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb2:2.0

hub.c: new USB device 00:10.0-2, assigned address 3

usb.c: USB device 3 (vend/prod 0x6b9/0x4061) is not claimed by any active driver.

Adding Swap: 819304k swap-space (priority -1)

reiserfs: checking transaction log (device 03:06) ...

Using r5 hash to sort names

ReiserFS version 3.6.25

eth0: Setting half-duplex based on MII#1 link partner capability of 0080.

HDLC line discipline: version $Revision: 3.3 $, maxframe=4096

N_HDLC line discipline registered.

ip_tables: (C) 2000-2002 Netfilter core team

ip_conntrack version 2.1 (6143 buckets, 49144 max) - 292 bytes per conntrack

Looking for splash picture.... silenjpeg size 75071 bytes, found (1280x1024, 26385 bytes, v3).

Splash status on console 0 changed to on

Looking for splash picture.... silenjpeg size 75071 bytes, found (1280x1024, 26385 bytes, v3).

Splash status on console 1 changed to on

Looking for splash picture.... silenjpeg size 75071 bytes, found (1280x1024, 26385 bytes, v3).

Splash status on console 2 changed to on

Looking for splash picture.... silenjpeg size 75071 bytes, found (1280x1024, 26385 bytes, v3).

Splash status on console 3 changed to on

Looking for splash picture.... silenjpeg size 75071 bytes, found (1280x1024, 26385 bytes, v3).

Splash status on console 4 changed to on

Looking for splash picture.... silenjpeg size 75071 bytes, found (1280x1024, 26385 bytes, v3).

Splash status on console 5 changed to on

0: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module  1.0-4496  Wed Jul 16 19:03:09 PDT 2003

IN= OUT=ppp0 SRC=192.168.1.1 DST=132.146.236.132 LEN=76 TOS=0x10 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=123 DPT=123 LEN=56

IN= OUT=ppp0 SRC=192.168.1.1 DST=132.146.236.132 LEN=76 TOS=0x10 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=123 DPT=123 LEN=56

IN= OUT=ppp0 SRC=192.168.1.1 DST=132.146.236.132 LEN=76 TOS=0x10 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=123 DPT=123 LEN=56

```

----------

## LinuxDolt

oh, i don't beleive i ever actually stated that mine works... i have mine working wonderfully now

1280x1024x16@90 working great on an nVidia GeForce4 TI 4200 w/ a Gateway VX920 Flatscreen CRT Monitor!

----------

## Ulukay

it does not work for me   :Sad:   :Sad:   :Sad: 

/me got a 5900ultra

and the 2.4.22-pre2-gss

i've tried everything ... 1024x768x16@85hz

dmesg:

vesafb: framebuffer at 0xd0000000, mapped to 0xf880d000, size 12288k

vesafb: mode is 1024x768x16, linelength=2048, pages=1

vesafb: protected mode interface info at c000:ea70

vesafb: scrolling: redraw

vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0

Looking for splash picture... no good signature found.

Console: switching to colour frame buffer device 128x48

fb0: VESA VGA frame buffer device

(with bootsplash or without - all the same - i geht 60hz)

sunnygentoo root # cat /usr/src/linux/arch/i386/boot/vesafb_modes.h

# The contents of this file were generated automatically.

# Please do not modify them, unless you are sure what you're doing.

# Format:     HorizontalSyncTotal, HorizontalSyncStart, HorizontalSyncEnd

#             VerticalSyncTotal, VerticalSyncStart, VerticalSyndEnd

#             Flags (0 = hsync+, vsync+; 12 = hsync-, vsync-; 8 = hsync-, vsync+, 4 = hsync+, vsync-)

#             Pixel Clock Rate (Hz)

#             Vertical Refresh Rate (in units of 0.01 Hz)

#define VIDEO_VESAFB_CRTC_DATA

# 320x200 @ 85Hz

        .word   456, 344, 424

        .word   240, 214, 214

        .byte   0

        .long   9302400

        .word   8500

        .space  40

# 640x400 @ 85Hz

        .word   904, 680, 840

        .word   440, 414, 414

        .byte   4

        .long   33809600

        .word   8500

        .space  40

# 640x480 @ 85Hz

        .word   904, 680, 840

        .word   520, 494, 494

        .byte   12

        .long   39956800

        .word   8500

        .space  40

# 800x600 @ 85Hz

        .word   1128, 848, 1048

        .word   640, 614, 614

        .byte   0

        .long   61363200

        .word   8500

        .space  40

# 1024x768 @ 85Hz

        .word   1416, 1080, 1320

        .word   808, 782, 782

        .byte   0

        .long   97250880

        .word   8500

        .space  40

# 1280x1024 @ 54.13Hz

        .word   1736, 1344, 1624

        .word   1064, 1038, 1038

        .byte   0

        .long   100000000

        .word   5413

        .space  40

and finally grub.conf: kernel=(hd0,1)/boot/bzImagefb root=/dev/sda5 hdc=ide-scsi hdd=ide-scsi vga=0x517 video=mtrr,vesa:1024x768@85

(i've also tried without the video=)

anyone knows what's wrong?

----------

## Angrybob

well you seem to have the same gfx card and kernel as me so maybe thats something to do with it.. i'm gonna try the gentoo-sources 2.4.20 kernel to see if thats the problem

----------

## Angrybob

just compiled the gentoo-sources-r6 kernel with both patches but still only get 60Hz !! maybe the geforceFX 5900 doesnt support VBE 3 ?! please say it aint so!!!!  :Sad: 

----------

## LinuxDolt

i have no clue... i myself run the gss sources for my kernel...

----------

## neenee

i just wanted to add my short story of success with this

patch to this thread.

though it took me a while to find out what to include in

the kernel, i now have my 2.6.0test3-mm3 kernel with a

nice high-resolution console.

now i can think about adding a bootplash and some

other eyecandy.

*update* kernel 2.6.0test4-mm1 works fine too w/ this.

----------

## chrisyu

Any one make it work on an ATI card?

I have a 8500LE card, and also follow this document.

Kernel is 2.4.20-gentoo-r6 with bootsplash.

I set vga=0x51A (1280x1024) in grub.conf, bootsplash still works but stays at 60Hz.

vesafb_modes.h  

```

# 1280x1024 @ 75.18Hz

        .word   1736, 1344, 1624

        .word   1064, 1038, 1038

        .byte   0

        .long   138880000

        .word   7518

        .space  40

```

----------

## tom.barbeau

I can't make it work either with my GeForce4 MX440. 

I wonder if this has to do with gentoo-sources-2.4.20-r6.  

Anybody successful with that kernel?

----------

## Vidar

For some positive feedback. I applied it without a hitch. Works perfectly. My info:

2.6.0-test4-mm1

Geforce FX 5200

Nvidia Kernel 4496-r1

CTL 910TF Monitor (basically relabeled Samsung 955DF, iirc)

Running at 1024x768 @ 96Hz (it's probably 100Hz. my monitor is probably screwy at reporting it)

edit: Aparently I put the bandwidth in wrong. Now it really is 100Hz. Only thing is everything is shifted up just about one line so the top line is not visable. I suppose I can live with it, but is there anything I can do? My xvidtune output: 

```
"1280x1024"   157.50   1280 1344 1504 1728   1024 1025 1028 1072 +hsync +vsync
```

and here's the relavent portion of the vesa_modes.h file

```
# 1024x768 @ 100Hz

        .word   1416, 1080, 1320

        .word   808, 782, 782

        .byte   0

        .long   114412800

        .word   10000

        .space  40

# 1280x1024 @ 89.28Hz

        .word   1736, 1344, 1624

        .word   1064, 1038, 1038

        .byte   0

        .long   164920000

        .word   8928

        .space  40
```

I'm trying to go 1024x768@100Hz, btw.

----------

## tom.barbeau

 *Quote:*   

> 
> 
> edit: Aparently I put the bandwidth in wrong. Now it really is 100Hz. Only thing is everything is shifted up just about one line so the top line is not visable. I suppose I can live with it, but is there anything I can do? My xvidtune output:
> 
> ```
> ...

 

I don't have the readme file with me, but i thought the format of vesa_modes.h was:

```

        .word   max, start, end

         ...

        .long   clock * 1000000

        .word   vert sync * 100

         ...

```

which would give you for 1280x1024:

```

# 1280x1024 @ 89.28Hz

        .word   1728, 1344, 1504

        .word   1072, 1025, 1028

        .byte   0

        .long   157500000

        .word   8928

        .space  40

```

or am I mistaken?

----------

## spock_

Hmm.. I was away for a while and it seems we have quite a few problem to solve here. Let's deal with them in the chronological order  :Smile: 

aLEczapKA: you could try doing it the xvidtune way, as explained in the README and earlier in this thread.

FileZilla: there probably will not be VBE 2.0 support.  The thing is - only in VBE 3.0 there is a function that allows one to change the refresh rate. VBE 2.0 doesn't support this. It is of course possible to write some kind of extension (which would work like old DOS UNIVBE worked for VBE 1.2 cards). However, it would be necessary to write a special extension for all VBE 2.0 we would like to support. It seems to me that a more efficient solution would be writing special framebuffer drivers for all these cards (this way we could use some adapter-specific features that aren't accessible via the VESA interface).

tom.barberau: does 0x317 work for you? have you tried applying the second patch (the one that shows you VBE version)

AngryBob: the second patch shows VBE version only if it's lower than 3.0 (it will stop the bootup and you to press a key). No info is recorded in dmesg as all these refresh rate and video mode change operations in vesafb are performed before the kernel is actually loaded. If you tried the second patch, what was the result?

Ulukay: did you mean that you can't get higher than 60Hz when you said it didn't work? Have you tried the second patch?

chrisyu: most likely your ATI card is not VBE3.0 compliant. Check the second patch to be sure.

Vidar: you could use this: 

```

# 1280x1024 @ 89.28Hz

        .word   1728, 1344, 1504

        .word   1072, 1025, 1028

        .byte   0

        .long   157500000

        .word   8502

        .space  40

```

----------

## tom.barbeau

spock_,

I tried the second patch and it seems my card is VBE3.0 compatible (I have a GeForce4 Mx440). Included is the relevant dmesg section:

```

vesafb: framebuffer at 0xd0000000, mapped to 0xe080d000, size 937k

vesafb: mode is 800x600x16, linelength=1600, pages=2

vesafb: protected mode interface info at c000:f880

vesafb: pmi: set display start = c00cf8c5, set palette = c00cf94a

vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03

vesafb: scrolling: redraw

vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0

Looking for splash picture.... silenjpeg size 10586 bytes, found (800x600, 17995 bytes, v3).

Console: switching to colour frame buffer device 93x31

fb0: VESA VGA frame buffer device

```

Currently, I have set it up at 800x600 16 bits, that's the best I can get, but still at 60Hz. Somehow, 1024x768 won't work, and it's the same when I used the Gentoo Live-CD, so it's not a new issue. I don't know why though. Maybe a video card bios or mobo bios setting or problem?

So I can boot at 800x600 no problem, get the splash screen, nice console, but at 60Hz   :Confused: 

What do you think? My hardware is A7N8X athlon XP 1800Mhz, GeForce4 MX440, DELL 1025TM, and I use gentoo-sources-2.4.20-r6.

Thanks.

----------

## minimizebeefgoo

It worked for me with 2.6.0-test4-mm1, but I had to manually put the results of xvidtune into the header file.  My monitor didn't seem to like a weird refresh rate like 80.6 Hz (85 was fine).

The weird thing about this is that the specs I got off the web indicate that my monitor can't do 1280x1024 at 85 Hz.  I don't know where my manual went :), but I do know that 1280x1024 at 85 Hz is one of the pre-programmed settings.  Does anyone with a Viewsonic A90 know more about this?

----------

## tom.barbeau

spock_,

As for the question - which I didn't answer   :Embarassed: , I can't get 0x317, which is 1024x768. The best I can get is 0x314. But whether 0x314 or 0x514, I don't get more than 60Hz. My monitor can handle 1024x768 at 100MHz on windows, I can set at at that rate and it works, as displayed on the OSD of the monitor. On Linux, I can't get X to set that refresh rate, though. It seems that it's not a progammed setting of the monitor, or something like that.

----------

## Angrybob

 *Quote:*   

> 
> 
> AngryBob: the second patch shows VBE version only if it's lower than 3.0 (it will stop the bootup and you to press a key). No info is recorded in dmesg as all these refresh rate and video mode change operations in vesafb are performed before the kernel is actually loaded. If you tried the second patch, what was the result?
> 
> 

 

well i've applied both patches and it doesnt stop during bootup, so i guess that means my card (GeforceFX5900 not ultra) does support VBE 3.0.

xvidtune -show gives this

```

"1280x1024"   157.50   1280 1344 1504 1728   1024 1025 1028 1072 +hsync +vsync

```

and I've edited the last one in my vesafb_modes.h file to be this (tried it with your script and that didnt work either)

```

# my mode

        .word   1736, 1344, 1624

        .word   1064, 1038, 1038

        .byte   0

        .long   157500000

        .word   8526

        .space  40

```

but i'm stuck in 60hz  :Sad: 

another thing to note, in my lil.conf I'm using 0x51A, but if I try 0x519 lilo guves me a "that isnt a valid mode" prompt... same if i convert the numbers to decimal.

<rant>

I cant try grub since the grub-install script stopped working with sed version 4 and higher and the sed v3 ebuilds have disappeard. this has been b0rked for months! the bug is in the bug database but no one seems to want to fix it! ARGHRHRHR

</rant>

i've just tried tha latest cvs of grub which fixes the above issue, but still no luck  :Sad: 

----------

## spock_

tom.barbeau: most monitors should support any mode that is within their display capabilities (and 1024x768 certainly is if it works with Windows). I'm temporarily out of ideas here - your card seems to be VBE 3.0 compliant yet it looks like as if the function for changing refresh rate simply didn't exist. I guess you'll have to wait until the next version of the patch (a few weeks at most) which should bring a few more ways to test things in this case. 

Angrybob: your situation seems to be the same as tom.barbeau's. So I'm sorry - but I can't help (yet). As for the grub-install, perhaps you should some info about it to gentoo-dev / try to talk with someone on IRC / use another way of attracting people's attention. The bug was fixed by grub devs some 6 months ago. It's high time someone fix it in Portage  :Smile: 

----------

## tom.barbeau

Just to make things clear - not sure my post was,

X works at 1024x768 with 16M colors at 85MHz but no more, although I can get 100MHz under Windows. But the framebuffer doesn't like more than 800x600 with 65K colors and only at 60Hz.

----------

## rtwick

Just to say another happy user  :Smile: 

2.4.22 ac-sources

DELL P991 monitor

PIII 600MHz

NVidia RIVA TNT2 32Mb

No problem installing the patch ... now running at 1280x1024@85Hz

----------

## Angrybob

 *rtwick wrote:*   

> Just to say another happy user 
> 
> 2.4.22 ac-sources
> 
> DELL P991 monitor
> ...

 

You've got the same monitor as me, can you post the contents of your vesafb_modes.h file so i can check it against what I'm using

----------

## rtwick

here's a link to the dell documentation on this monitor http://docs.us.dell.com/docs/monitors/p991/en/spec.htm

and here's my vesafb_modes.h file

 *Quote:*   

> 
> 
> gentoo linux # cat ./arch/i386/boot/vesafb_modes.h
> 
> # The contents of this file were generated automatically.
> ...

 [url][/url]

----------

## kriz

wow! really nice! great work!

1024x768@119Hz   :Cool: 

wft is xfree  :Wink: 

mfg

----------

## phlashback

All I can say is.... VVoVV

just took the plunge and am happy to report that under 2.6.0-test5 I have 

a revived console running at 1280x1024@80. Ahh two happy penguins  :Cool:  at boot, and mplayer never looked so good  :Twisted Evil: 

Thanks

----------

## tom.barbeau

Some people are still unable to run the fb at more than 60Hz. I wonder if this is related to the kernel version. I want to do a quick poll to see what is the best kernel version to use for that.

We have some guys that have been successful with the 2.6 kernel series.  I personally was *not* successful with gentoo-sources-2.4.20-r6. 

Any other examples of successful as well as unsuccessful kernels?

Thanks

----------

## tom.barbeau

Some people are still unable to run the fb at more than 60Hz. I wonder if this is related to the kernel version. I want to do a quick poll to see what is the best kernel version to use for that.

We have some guys that have been successful with the 2.6 kernel series.  I personally was *not* successful with gentoo-sources-2.4.20-r6. 

Any other examples of successful as well as unsuccessful kernels?

Thanks

----------

## Angrybob

I've tried unsuccessfully with

2.4.22_pre2-gss

2.4.20-gentoo-r6

2.6.0-test4-mm

I think its more likely a motherboard / gfx card problem

----------

## lurid

I've had this working since 2.6.0-test2-mm1.  I'm currently on 2.6.0-test5-love1.  Thats been at least 3 kernels (probably more since the -mm series is updated quickly.  i can't keep track of them all).  What problems exactly are you having?  All I do is:

```
cd /usr/src/some_kernel

bzcat /path/to/patch | patch -p1

cp /path/to/old/vesafb_modes.h /usr/src/some_kernel/arch/i386/boot/
```

I've edited my vesafb_modes.h file and saved it on my backup drive, so I mearly copy it to the right place with each new kernel.  Then compile.  If the problem is not the patch process, but with having the right modelines in vesafb_modes.h then take a look at the README included with the patch.  Its very well documented.

Good luck.

----------

## chrisyu

Applied the second patch and it told me ATI8500 was a VBE2.0 card...  :Crying or Very sad: 

Anyone make this work on an ATI card??

----------

## Cicero

You don't need to use the vesa framebuffer driver for ATI cards. Use radeonfb instead. It takes an argument for the refresh rate.

----------

## lucida

For radeon users:

Use radedit to modify the bios, set default refresh rate of corresponding resolution directly, flash it back to your video card. Boot with standard vesafb parameters(mine: vga=0x318 video=vesafb:ywrap,mtrr).

No patch necessary at all, you might need MS-Windoz/Dos to do this though.Last edited by lucida on Fri Sep 12, 2003 10:06 pm; edited 2 times in total

----------

## Lovechild

I threw this patch in my love-sources for those interested - who do I credit for it in the changelog btw?

----------

## tom.barbeau

 *Quote:*   

> 
> 
> For radeon users:
> 
> Use radedit to modify the bios, set default refresh rate of corresponding resolution directly, flash it back to your video card. Boot with standard vesafb parameters(mine: vga=0x318 video=vesafb:ywrap,mtrr).
> ...

 

Is there such a way for Nvidia cards (GeForce4 Mx440)? I still cannot get more than 800x600 in the console, and at 60Hz.   :Evil or Very Mad: 

----------

## hakan

It works for me in 1024x768 with 111Hz, but I want to run 1280x1042@85. But when I do that (with 0x051B in my grub.conf) then I get the error message that this mode doesn't exist when I reboot.

----------

## minimizebeefgoo

0x51B didn't work for me, either.  0x51A did, though.  I had a similar issue with the normal 0x3** framebuffers.

----------

## hakan

Ok, tried 0x51A, my screen is black then but it is booting! With 0x31A (normal vesa fb) it works fine.   :Shocked: 

I have a nVidia GeForce4 ti.

----------

## krunk

After two days of trying to get the patch to work with no luck. (and, yes, I used the script and used the settings from X as well as following all the useful advice in this thread) Without out a doubt the route of radedit is the least trouble of all if you have an ati card. I'm sure something similar exists for other cards as well. Took me only 5 minutes to dump my vid bios set 1280x1024 to 85Hz default and reboot.........wooot!

*edit* oh, if you want any specific info on my setup, etc. let me know. I'd be glad to send it to you.

----------

## Joffer

What is my max bandwith? I got a Samtron 19" 96P. Specs: http://www.samtron.com/product/96p_spec.html

Is this correct?

```
Horizontal = 30-96KHz

Vertical = 50-160Hz

Max bandwith = 205MHz   (Pixel Frequency)
```

----------

## morsafr

@ hakan

I have exactly the same problem : 

-> works nicely in 1024x768 (119 Hz) 

-> boot with a black screen in 1280x1024

I follow the guide with the xvidtune method (X running 1280x1024@85) but no go. By the way, I also have a GeForce4 Ti 4200.

Maybe it is hardware related ?

Any successful experience with this card ?

----------

## morsafr

Surprisingly, it is working now !   :Shocked: 

I recompiled my kernel to disable ACPI and enable APM instead. After reboot I chose my high-res line in grub just in case it would work... And behold ! It is working : 1280x1024@85Hz with a nice bootsplash and progress bar  :Very Happy: 

I DO suggest to disable ACPI for people having troubles.

----------

## hakan

hm, ok, i am going to disable acpi and try again.

----------

## hakan

@morsafr

I rebuild my kernel without acpi and still have a black screen when booting with the 0x51A option.

Do you changed anything elese in your kernel config?

----------

## morsafr

@ hakan

I changed few things according to my new system :

-> disable ACPI

-> enable APM as a module

-> enable APIC for single processor (not in the BIOS)

-> disable I2C

-> disable Video4Linux and sound module for TV

-> disable SCSI emulation and other SCSI stuff

-> disable ACM Modem

and remove my module folder just before compiling my new kernel and modules by typing :

```
make dep && make clean bzImage modules modules_install install
```

in grub I have the following options passed to the kernel :

```
video=ywrap,mtrr,vesa=1280x1024 vga=0x51A splash=silent
```

Give it a new try and let me know about the result   :Wink: 

----------

## hakan

@morsafr

Ok, I need SCSI emulation because I want to burn some CD's  :Wink: . So I will not change this (I build all scsi stuff as modules). I will try to build APM as module.

I have exactly the same grubs options.

----------

## morsafr

@ hakan

You've got a point I tried ATAPI burning but it gave me little success.   :Confused: 

So I turned back to the good old SCSI IDE emulation...   :Smile: 

I hope it will work for you this time !   :Razz: 

----------

## ikaro

Hi.

I think i need some help with this one.

I cant get over 60hz.

Bottsplash and framebuffer works allright. the only annoying thing is the 60hz.

Sources:

```

2.4.22-ck2

```

My hardware:

GFX:

```

CLABS Gforce 2GTS 32DDR

```

Monitor:

```

Sony MultiScan G420 19" - Trinitron 

```

Specs:

```

Max resolution: 1920x1440@60hz

Recomended: 1280x1024@100hz

'the one i use' 1600x1200@85hz

```

Frequency:

```

Horizontal: 30 - 110 kHz

Vertical: 48 - 170 Hz

```

Output from xvidTune on 1280x1024@85hz:

 dono how to get it to run over 85hz  :Sad:  it supports up to 100hz on that freq

```

Num hsync: 1, Num vsync: 1

hsync range 0:  40.00 - 110.00

vsync range 0:  58.00 - 170.00

"1280x1024"   157.50   1280 1344 1504 1728   1024 1025 1028 1072 +hsync +vsync

```

vesafb_modes.h

```

# 1280x1024 @ 103.38Hz

        .word   1728, 1344, 1504

        .word   1072, 1025, 1028

        .byte   0

        .long   157500000

        .word   8662

        .space  40

```

Grub.conf

```

splashimage=(hd0,0)/boot/grub/splash.xpm.gz

title=Gentoo GNU/Linux 1.4

root=(hd0,0)

kernel /Gentoo-GNU1 root=/dev/hda3 video=ywrap,mtrr,vesa:1280x1024@100 vga=0x31A

initrd=/boot/initrd-1280x1024

```

Anyone can help me ? 

Thx .

----------

## morsafr

@ ikaro

Instead of your parameters :

```
video=ywrap,mtrr,vesa:1280x1024@100 vga=0x31A
```

Try to pass the following parameters to your kernel :

```
video=ywrap,mtrr,vesa=1280x1024 vga=0x51A
```

-> You don't need @100 as it is for radeonfb

-> Most important you must tell your kernel to you use high refresh rate vesafb with vga=0x51A instead of normal refresh rate with vga=0x31A

Tell me if it works !   :Smile: 

----------

## ikaro

hi,

Thank you. it works 1280x1024 @85 hz  :Smile: 

----------

## ikaro

anyone running 1600x1200@(85hz)  ? 

how is with the vesa patch ? i only see up to 1280x1024 ..

----------

## ikaro

```

/usr/src/linux/scripts/vesa_modeline_gen.pl

1) Maximal vertical refresh rate [Hz]

   [100]: 170

2) Maximal horizontal refresh rate [kHz]

   [70]: 110

3) Monitor's maximal bandwidth (aka pixel clock) [MHz]

   [100]: 350

Invalid bandwidth. Please enter a number from range 30 - 300.

New value: 300 

```

my monitor can use 350MHz at 16bits, why does it say its invalid ? 

then i could, prolly, use 1280x1024 @ 100Hz

----------

## Neelix

I'm here to report I'm one happy camper as well with this new vesafb driver!

However, I used the xvidtune method to create a vesafb "modeline" and I think that they can't be matched one on one.

For one thing, the top line of my screen is a bit scrambled (like it's folded in on itself), which is not the case with my X configuration. And besides that, there's also the fact that the refresh rate is somehow different.

I'll try to look into this as wel when I have some time.

----------

## Cuchulainn

Flashing the video bios using radedit worked like a charm! Thanks for the tip!

Cheers, Cuchu

----------

## sburnett

Does anybody have a copy of the patch? The site appears to be down and I am very eager to try this patch. If someone can either post it or email it, I'd really appreciate it. Thanks.

----------

## ikaro

Hi.

There ya go:

http://ikaro.homepage.dk/vesa-patch/patch-2.4.x-vesafb-rrc.tar.gz

 :Razz: 

----------

## sburnett

Thanks!

----------

## Brazil

I have a widescreen (16:10) monitor that can do 1920x1200 (1600x1200 normal monitor).  Well it go higher, but my video card cant...

Anyway, I notice people are still to figure how to get 1600x1200 to work, but would it be possible to get 1600x1024?  It's another 16:10 mode....

I have the modelines for X for both 1920x1200 and 1600x1024 modes...

There are black bars on the side in the console.... I alwasys hated the wasted space.

Any ideas?

----------

## alshain

Has anyone managed this with a Radeon 9600? I've patched everything and used the new hex code in grub but my refresh rate stays resolutely at 60Hz which is fine for a black background but migraine-inducing with a fancy bootsplash background! I get the feeling that the 9600 may not be VESA 3.0 compliant, in which case I'll have to lump it.

This is with 2.6.0-test9 by the way.

I'm resorting to vesafb because:

a) radeonfb doesn't &^%*& work with a 9600 and I can't find a patch to version 0.1.8 that might work.

b) bootsplash doesn't ^**^% work with radeonfb as it depends on vesafb!!!!!

<Sigh> It's enough to turn someone to Windows.   :Shocked: 

        Andrew

----------

## barlad

Hey there,

I have got a wierd problem. I used your patch to have VBE information displayed but no output came in dmesg.

Here is my vesafb_modes.h:

 *Quote:*   

> 
> 
> # 320x200 @ 160Hz
> 
>         .word   456, 344, 424
> ...

 

I am using a SONY GDM FW900: 

Vertical max: 160

Hor max: 121

Bandwidth: 400mhz.

----------

## barlad

Guess what I got in my mailbox today:

 *Quote:*   

> 
> 
> --- leadtekservice <services@leadtek.com.tw 
> 
> > thank you for your inquiry
> ...

 

that's a 500 bucks card... it's not VBE 3.0 compliant...

----------

## Ventrue

This is so cool!!!!!!!

Thank you for writing this code, I really hope, that this patch will be included in the future kernels. I would LOVE that!

BTW Setting up the modes wasn't very simple, but it's worth it. I have a console looking exacxtly like under X   :Laughing:   :Laughing:   :Laughing: 

Thanks again...

PS.: Could someone tell me in PM(because I can't visit the forums regularly), if the new kernels are include the patch???

----------

## boris64

hi mrspock, nice idea to tune the framebuffer console  :Wink: 

now here comes my problem,

i got a modeline from xvidtune, which gives me

EXACTLY 85hz in X. i would like to use the same

resolution in my fb-console.

using your script didn't really work for me, because

it always gave me something with 86.xxxhz etc.

please, i want exactly 85hz, no one wants to recalibrate

his monitor after leaving x for a highres-terminal session .)

my x-modeline:

"1024x768"     94.50   1024 1072 1168 1376    768  769  772  808 +hsync +vsync

can someone help me? thx buddies

ps: if only there was some kind of tool, in which you could

change framebuffer resolution on the fly instead of everytime

patching and recompiling the kernel after changing a monitor...

well, some day... perhaps...err

----------

## boris64

well, i found the solution by myself  :Wink: 

i thought it would be very difficult,

but, guess what, it wasn't!

well, thanx to mr.spock for giving me the

idea of tuning my  fb-con. 

 :Very Happy: 

----------

## neenee

would you mind posting your solution here?

----------

## boris64

from my file /usr/src/linux/arch/i386/boot/vesafb_modes.h

```
line1 # 1024x768 @ 85.00Hz

line2        .word   1376, 1072, 1168

line3        .word   808, 769, 772

line4        .byte   0

line5        .long   94500000

line6        .word   8500

line7        .space  40
```

1.) i started xvidtune

2.) had a look at the information xvidtune gave me.

HSyncStart: 1072

HSyncEnd: 1168

HTotal: 1376

...

VSyncStart: 769

VSyncEnd: 772

VTotal: 808

...

Pixel Clock (MHz): 94.50

...

Vertical Sync (Hz): 85.00

now take a look at these variables for HSyncStart etc. and you

should see that they are the same as listed from line 2-3

(in a different order, have a look at the README-file from mrspock)).

3.) in line5 after ".long" you write down the variable for your pixel clock without a comma and add some 00.

(for example: 94.50MHz-> .long   94500000)

4.) .in line6 after ".word" write down the var for your Vertical Sync the way

i did (no comma, for example: 85.00 hz -> .word 8500)

5.) i dont know what the other variables are for (line4+7),

but they seem to be ok.

6.) go on and edit your /usr/src/linux/arch/i386/boot/vesafb_modes.h

(i edited only the 1024x768 resolution, because i don't switch so often, well, i... err... never switch resolutions)

7.) do what mr.spock told you to do (recompile kernel, edit grub.conf etc.)

and you should be done.

-> now when i am in X and i change to console via [CTRL]+[ALT]+[F1],

i have a resolution of 1024x768@85hz, and it's exactly the same as in X.

it even DOES NOT flicker anymore while changing to console,

'cause there is no need to change frequenzies for my monitor...

hope this crappy try of a help can be useful for some poor lost souls...

good luck!

----------

## neenee

i'm trying it now. thanks for your prompt reply  :Wink: 

*update* though i could not find a way to use the

1152x864 resolution, 1024x768 works fine now.

thanks again.

----------

## boris64

are you sure, that is this resolution

(1152x864) part of the vesa-3.0-standart?

----------

## neenee

i am not sure. it might not be.

----------

## barlad

Anyone got this working with a Radeon 9000 or Mobility Radeon 9000?

----------

## spock_

 *borisdigital wrote:*   

> ps: if only there was some kind of tool, in which you could change framebuffer resolution on the fly instead of everytime

 

The tool you're talking about is already being developed  :Smile:  It should be a matter of days before it's finished (assuming nothing unexpected pops up..).

----------

## boris64

 *Quote:*   

> ...using your script didn't really work for me, because
> 
> ...

 

didn't mean to blame you...

using your patches DID work of course  :Wink: 

-> can't wait to see that upcoming tool  :Wink: 

----------

## neenee

hm.. the patch can not be downloaded due

to some sql database problem  :Neutral: 

----------

## spock_

 *neenee wrote:*   

> hm.. the patch can not be downloaded due
> 
> to some sql database problem 

 

Have a look at http://www.spock.mga.com.pl/public/gentoo/.

----------

## neenee

thank you kindly  :Wink: 

----------

## ikaro

anyone knows if the mm sources have these patches in place ? 

i cant get 2.6. going with a decent framebuffer.

----------

## malloc

neither mm-sources or love-sources have this patch AFAIK.

Love-sources used to have it but i think they lost the patch or something, they're planning on bring it back on.

Ok now for my question...Is it possible to use vfb at resolutions higher than 1280x1024? I've seen a site (can't remember wich one) that had some guy's grub.conf file and he had something like 1600x1200?? Is this possible to do?

----------

## ikaro

I think ive read somewhere in these forums that someone made it...

how I dont remember so well to explain in detail, but its something about just passing his own  vesa line in grub like you do with 1280x1024 .. but for 1600x1200 ... something like that ..

there was also a url for some website when a description about it ..

maybe at ldntl or something .

too many "somethings" sorry .

----------

## ikaro

Finally I got MM sources ( 2.6.0-mm1 ) running at 1280x1024 @ 85Hz !

I was trying to get it on 1600x1200 but ended up with 85hz, so iam happy for now  ... and tired , iI must have rebooted the box at least 20 times trying and trying ....

Still on boot, After every service start, i get wierd /sbin/splash error messages .. like if you do "splash --help" comes the usage modes ... its wierd that it pops up when the system is starting the services, if anyone knows whats going on with it, I would like very much to know.

a snapshot of the console is here : http://ikaro.homepage.dk/1280-mm1.jpg

also if anyone got it on 1600x1200 please post  :Smile: 

----------

## spock_

 *ikaro wrote:*   

> Still on boot, After every service start, i get wierd /sbin/splash error messages .. like if you do "splash --help" comes the usage modes ... its wierd that it pops up when the system is starting the services, if anyone knows whats going on with it, I would like very much to know.

 

I had a similar problem a few months ago. It appears there is an error in baselayout. To fix this, one has to edit /sbin/functions.sh. Find function splash_update() in it and change all '/bin/splash "${myscript}" "${action}"' to '/bin/splash -u "${myscript}" -n "${action}"' or add >/dev/null 2>/dev/null after them  :Wink: 

----------

## ikaro

Ok thx for the reply.

iam atm compiling 2.6.0-mm1 ive changed that file now and will let you know what happens after i reboot.

----------

## ikaro

Thanks alot  :Smile:  it boot clean now  :Smile: 

image: http://perworm.dk/fine.jpg

now only missing the 0 sized ramdisk wierd message ...

but thats on another tread  :Smile: 

anyway, I dont know If anyone else got the -mm sources to work with a nice framebuffer, The script didnt worked for me, so i had to do the vesa line manually with help from some posts in this forum and with xvidtune.

I can post my config if anyone thinks it might be helpfull for anyone.

----------

## neenee

love-sources had this patch in place, and i

have suggested adding it again in the love1

thread, but so far no dice it seems.

time shall tell  :Wink: 

*update* it's back in.. and there was much rejoicing  :Wink: 

----------

## d3vlin

hello all, I am trying to get my linux-2.6.1-r1 (gentoo-dev-sources) 1280x1024@60Hz framebuffer/bootsplash to run at a higher refresh rate. I installed the patch according to the howto and that went just fine.

I am running a Geforce3Ti500 on a iiyama A901HT (19') monitor. 

According to the specs it can do:

hsync: 27-115 kHz

vrefresh: 50-160 kHz

bandwith: 230

The ergonomic resolution of this monitor is 1280 x 1024 @ 107Hz, according to the manual. This would be a very nice framebuffer res. I think  :Smile: 

I have been trying around with the script to set these values, but somehow it always messes up and comes up with inapropriate monitor settings.

I am booting the patched kernel with vga=0x51A in lilo.

I run my Xfree (kde powered) in 1600x1200@85 Hz (fH=106KHz, fV=85kHz).

I tried to run xvidtune, but when I run 1280x1024 in Xfree, I have a screen that is not aligned with the borders of the physical screen, i.e. the desktop scrolls (because it is larger than the physical area). According to the OSD menu of the monitor it then runs 1280x1024@86Hz.

I wonder if someone has the same config or problem, after rebooting about 40 times, any help is appreciated. Thanks.

----------

## ikaro

try this modeline for your 1280x1024@85Hz Xfree setting.

```
Modeline "1280x1024"  159.36  1280 1376 1512 1744  1024 1025 1028 1075  -HSync +Vsync
```

this for 1600x1200@85:

```

 Modeline "1600x1200"  234.76  1600 1720 1896 2192  1200 1201 1204 1260  -HSync +Vsync
```

For your vesafb_modes.h file put this one:

```

# 1280x1024 @ 100.00Hz

        .word   1760, 1376, 1520

        .word   1085, 1025, 1028

        .byte   0

        .long   190960000

        .word   10000

        .space  40

```

make bzImage and try again.

Btw, is these patches working again on =>2.6.1 again ? 

Last time i tried was on 2.6.0 and there it didnt work anymore.

 :Rolling Eyes: 

Hope it Helps-

----------

## d3vlin

flawless!!!  :Smile: 

running 1280x1024@100Hz SXGA now

(fH=108 kHz fV=100 kHz)

on a (gentoo-dev-sources) 2.6.1-gentoo-r1 kernel

looks awesome. I wonder how you got these values.

Is it also possible to stretch the display to 1600x1200 as mentioned in a post somewhere earlier? (i.e. override 1280x1024 as a 1600x1200 mode)

----------

## ikaro

Ive tried 1600x1200  but didnt work out so well.

Now I havent been using framebufer because it stop working some time ago, but since you say it works on 2.6.1 i might try again at some time... dont fell like rebooting now .

maybe i wait until 2.6.2  :Smile: 

I just made those lines using  that xvidconfig tool , used 1280x1024 @ 100hz on the X server and then made my own vesa_rates.h file.

----------

## d3vlin

thanks a lot.

actually I saw that there are config files and images provided for 1600x1200 already in /etc/bootsplash/gentoo.

quite strange if there's no default 1600x1200 vesa framebuffer mode?

----------

## ikaro

I think thats because, like someone else pointed out somewhere in this tread, that 1600x1200 isnt a vesa standard resolution.

But you can try to trick it, just delete the 1280x1024 block and insert a 1600x1200 one.

then it might work.. that was what I was trying to do.

----------

## d3vlin

btw, I had some very strange results on my 15" UXGA (1600x1200 capable, radeon M9000 driven) laptop screen when using bootsplash. While framebuffer has always worked there (1280x1024), the screen turns all white and blurry when using bootsplash. Could it be that that's todo with the bootsplash refresh rate opposed to just framebuffer or something? Looking for solutions here.

----------

## danone

The patch also works at my 2.6.1 kernel gentoo-dev-sources-r1

i use 1280x1024 @ 85hz

My monitor specs are

Hsync max:42~97khz

Vsync:max 40-160hz

Bandwith: 156.50Mhz

and use the GeForce T4200@64MB

so far it works fine but when i start xdm i must go of OSD an must correct position and gemometrie and if i do so i must do it on boot again my video_modes.h settinge are:

```
# 800x600 @ 150Hz

        .word   1128, 848, 1048

        .word   640, 614, 614

        .byte   0

        .long   108288000

        .word   15000

        .space  40

# 1024x768 @ 118.81Hz

        .word   1416, 1080, 1320

        .word   808, 782, 782

        .byte   0

        .long   135936000

        .word   11881

        .space  40

# 1280x1024 @ 85.26Hz

        .word   1736, 1344, 1624

        .word   1064, 1038, 1038

        .byte   0

        .long   157500000

        .word   8526

        .space  40

```

Also when i set to grub.conf vga=0x51B does not work but why? 0x51 works 

 well will try now this on X11

"1280x1024"   157.50   1280 1344 1504 1728   1024 1025 1028 1072 +hsync +vsync

----------

## Cossins

How do I figure out the proper numbers for vesafb_modes.h if I want 1600x1200@85Hz?

- Simon

----------

## ikaro

Hejza.

Thats described somewhere in this tread or one of the others treads about framebuffer.

i cant remember off hand, let me see if i can find it before you do.

----------

## ikaro

[edit]

nevermind ....

didnt pay attention you mean 1600x1200 .. Good Luck , let me know when you did it.

I want also .

----------

## ikaro

well .. try the following.

 :twisted: 

```

# 800x600 @ 170Hz

        .word   1128, 848, 1048

        .word   640, 614, 614

        .byte   0

        .long   122726400

        .word   17000

        .space  40

# 1024x768 @ 136.13Hz

        .word   1416, 1080, 1320

        .word   808, 782, 782

        .byte   0

        .long   155760000

        .word   13613

        .space  40

# 1600 x 1200 @ 85.00Hz

        .word   2160, 1664, 1856

        .word   1250, 1201, 1204

        .byte   0

        .long   22950000

        .word   8500

        .space  40 

```

template:

From Xvidtune you get a Modeline like this:

```
"1600x1200"   229.50   1600 1664 1856 2160   1200 1201 1204 1250 +hsync +vsync

```

That translates to:

```

"1600x1200" Clock 1 2 3 4   5 6 7 8 +hsync +vsync

```

so

```

# 1600X1200 @ XX.00Hz

        .word   4, 2, 3  <-  replace each char with the numbers from the modeline.

        .word   8, 6, 7 <- same thing here

        .byte   0

        .long   229500000  <--Pixel clock

        .word   85000   <--- Refresh rate

        .space  40 

```

Thats it.

----------

## Cossins

ikaro: Thanks!

Actually, my output from xvidtune is exactly the same as yours...

So am I just supposed to set the vga-argument in grub.conf to the 1280x1024 setting?

- Simon

----------

## ikaro

no . the 1600x1200 one.

----------

## Cossins

 *ikaro wrote:*   

> no . the 1600x1200 one.

 

...yes, which would be on 0x51B, where 1280x1024 used to be, right?

- Simon

----------

## Cossins

Argh, I'm having problems.

I can't set vga=0x51B, because then the kernel complains that that setting isn't supported. The I tried replacing the 800x600 values with the 1600x1200 values in video.S - when I boot the kernel (after of course recompiling), I get a black screen. The kernel boots, and I can log in to X and fetch this dmesg output:

```
vesafb: framebuffer at 0xd0000000, mapped to 0xf0807000, size 16384k

vesafb: mode is 800x600x32, linelength=3200, pages=1

vesafb: protected mode interface info at c000:f290

vesafb: scrolling: redraw

vesafb: directcolor: size=8:8:8:8, shift=24:16:8:0

fb0: VESA VGA frame buffer device
```

My graphics card is a GeForce4 MX440 with 64 Mb RAM - maybe it isn't VESA (or whatsitcalled) 3.0 compatible?

- Simon

----------

## ikaro

should be, mine is Gforce 2GTS.

But 1600x1200 isn't a VESA standard Resolution ( someone else mentioned this before )

----------

## neenee

though i do get 1024x768 resolution, my refresh rate

is back to 60Hz, even though i did not modify my mode-

file for this hack.

perhaps someone can tell me what i am doing wrong?

my modeline, as provided by xvidtune:

```
"1024x768"     98.97   1024 1072 1312 1408    768  770  782  808
```

what i have in my vesafb_modes.h file:

```
# 1024x768 @ 86.99Hz

       .word   1408, 1072, 1312

       .word   808, 770, 782

       .byte   0

       .long   98970000

       .word   86990

       .space  40
```

thanks in advance.

----------

## ikaro

 *neenee wrote:*   

> though i do get 1024x768 resolution, my refresh rate
> 
> is back to 60Hz, even though i did not modify my mode-
> 
> file for this hack.
> ...

 

try this:

```
# 1024x768 @ 86.99Hz

       .word   1408, 1072, 1312

       .word   808, 770, 782

       .byte   0

       .long   989700000  <- was missing a 0

       .word   86990

       .space  40
```

if it doesnt work, you can try setting the clock a bit down, and roudup the refresh rate to 85.00 ( .word 85000 )

----------

## neenee

i tried lowering the pixel clock and

lowering the refresh rate to 85Hz.

i also tried loweing the bitdepth

using the kernel line option.

my framebuffer stays at 60Hz  :Neutral: 

suggestions are welcome.

----------

## ikaro

which kernel ?

and I assume you have patched the kernel with the bootsplash and the his-res patches and everything applied clean.

and that you configured your kernel to use framebuffer using the VESA driver and not using any RIVA and not using 16 bit Frammebuffer.

some more details please.

----------

## neenee

i use love-sources which includes the vesafb patch.

i do not use bootsplash, even though i can enable

it in love-sources.

i have my kernel configured properly, as described

at the start of this thread.

i have used this configuration with previous kernels,

and somewhere along the line i had and lost a proper

refresh rate with the framebuffer.

i have added "video=ywrap,mttr vga=0x517" to

my kernel line in grub.conf

----------

## neenee

*shameless bump*

----------

## Proton

I can't seem to get it working  :Sad: 

My xvidtune reports the same exact settings as Borisdigital back one page, I use the exact same settings as him in the .h file and nothing...

I'm using love-sources, so it should work...

----------

## hardcampa

How about making this patch compatible with the latest stable kernel 2.6.3 as of this writing (especially since the bootsplash patch now is out).

----------

## spock_

 *hardcampa wrote:*   

> How about making this patch compatible with the latest stable kernel 2.6.3 as of this writing (especially since the bootsplash patch now is out).

 

The patch is as compatible with 2.6 kernels as it was with 2.4  :Smile:  Just download it and have your 2.6 sources patched. I had no problems with getting it to work with any of 2.6.{0,1,2,3}.

----------

## ikaro

indeed i had no problem with this patch but the bootsplash doesnt apply anymore.

I think the authors of the pathces should _REally_ send them upstream to include in the ****** kernels.

This happens too often that now it works, now it doesnt ...

the code they have in the kernel doesnt "work" anyways ...

who cares about a fat ugly pingvin in a 60hz console .?

we want 85hz and over and the screen looking nice.

 :evil:

----------

## spock_

 *ikaro wrote:*   

> indeed i had no problem with this patch but the bootsplash doesnt apply anymore.
> 
> I think the authors of the pathces should _REally_ send them upstream to include in the ****** kernels.
> 
> 

 

Well, not everything can be included in the main kernel tree. As for Bootsplash, what kernel version are we talking about? There should be no problems with any 2.6 kernel (development-sources or gentoo-dev-sources) with media-gfx/bootsplash-0.6-r8. If there are any issues, please file a bug a bugs.gentoo.org  :Smile: 

----------

## eGore911

You are right, Spock. Not everything should get into kernel. But this patch definitly should. But its not for me to decide. Just submit it to their list and see if it gets in. It's worth a try  :Smile: 

----------

## monolin

spock I visited your site recently and the patch name still has 2.4 in it. Why not change it into 2.4/2.6 as you did in your gentoo about me page?

Also, the modeline layout is different from that of vesa patch, I believe it is a good idea to make it compitable with XFree86Config-4 modeline so that people can just copy it.

----------

## RealGeizt

hello there!

can somebody please set up my vesafb_modes.h?!

```
chris@cKy : 7 files 2.4Mb $ gtf 1400 1050 85 

  # 1400x1050 @ 85.00 Hz (GTF) hsync: 93.76 kHz; pclk: 179.26 MHz

  Modeline "1400x1050_85.00"  179.26  1400 1504 1656 1912  1050 1051 1054 1103 -HSync +Vsync
```

what vga=? should i use for this resolution whit 64k colors?!

is there anybody whit a bootsplash config for this resolution?!

thank you, christian

----------

## riis

Can you have this patch working and still have your bootsplash? My new bzImage contains no bootsplash. (and only works with 1024x768 and not in 1280x1024)

----------

## Malketh

Well to answer your question riis: Yes. I have it working on three machines right now with 2.6.1, 2.6.2, 2.6.3-rc2 kernels, and I'm right now compiling with 2.6.3-r1, but I expect it should work out fine. I haven't had any problems with bootsplash and higher than default refresh rates since the 2.4.20 days.  :Smile: 

Also for the record, the machines in question contain a GF2 GTS, V3 3500, and a V3 3000. The GF2 is running at 1280x1024@85hz (if I remember right), and the V3s are running at 1024x768@105hz

----------

## neenee

i am still unable to get anything higher than 60Hz.

----------

## riis

 *Malketh wrote:*   

> Well to answer your question riis: Yes.....

 

In what order do you apply the patches then? I applied the bootsplash first and then then the vesafb patch. And the new bzImage doesn't seem to work with the bootsplash. At least it doesn't display any. What order did you do it in? And what are your grub-conf settings?

----------

## Icer

Affirmative Sir! It works! 1280x1024@85Hz 

Here's my hw specs and what I did:

Graphics board: Leadtek Winfast Titanium 200 i.e Nvidia Geforce3Ti200

Monitor: Nokia 446Xpro

The monitor specs are: 30-107kHz vertical freq. 50-150Hz horiz. freq and <230MHz

I configured the vesafb_modes.h like this:

# 1280x1024 @ 85.00Hz

.word 1736, 1344, 1624

.word 1064, 1038, 1038

.byte 0

.long 157003840

.word 8500

.space 40

But I think that the critical change was in grub.conf:

kernel /boot/bzImage root=/dev/md/0 video=ywrap,mtrr,vesa=1280x1024 vga=0x51A splash=verbose

I changed vesafb to vesa and it seemed to do the trick.

ps. Anyone know why xvidtune wont work? It just says; Error: Can't open display:

----------

## sibov

 :Laughing:   :Laughing: 

Nice Patch !!!!

My CRT Data:      

H: 30-95

V: 50-160

P: 210

My Inputs:

H: 81

V: 130

P: 160

My Result:   1024x768 at 101Hz

THX for the great patch 

 :Wink:   :Wink:   :Wink:   :Laughing: 

----------

## Hazel

That truly is great job! Followed the README info to convert X Modelines to vesafb_modes.h and now I got a beautiful 1024x768 @ 89.04 console. Everything went without a glitch  :Smile: 

However, in X I use 1152x864 and wanted to get the exact same configuration for the console (so I could switch X<->console without mode switching). I replaced the 1024x768 mode definition in vesafb_modes.h with this 1152x864 mode data, and after the reboot the console uses only a part of the screen (probably 1024x768 pixels of the 1152x864 screen). 0x517 and 0x518 give the same result.

From the previous posts, I understand someone managed to get a 1600x1200 console by replacing the 1280x1024 mode. Is that correct?

So what can I do to have my non-vesa-standard mode running? I'd be grateful for suggestions

I'll probably try replacing the 1280x1024 mode now, I wonder what I'll get? A console bigger than the screen size? Cool  :Wink: 

I'm using gentoo 2004.0 with gentoo-dev-sources (that's 2.6.3-gentoo-r1), GF4 Ti4200 and a Sony CPD-G200.

----------

## Hazel

Okay so I tried replacing the 1280x1024 mode with my 1152x768 definition but no luck.

with vga=0x51b, it said I provided a wrong mode number,

with vga=0x51a the screen went all black with some tiny little white dots running on the left side of the screen  :Smile: 

Anyway, I'm more than happy with the 1024x768 console.

But is there a sligthest chance to get these non-standard modes working?

----------

## spock_

 *Hazel wrote:*   

> Anyway, I'm more than happy with the 1024x768 console.
> 
> But is there a sligthest chance to get these non-standard modes working?

 

There is - when the new version of the patch (which I'm currently working on) is released. I know I've been talking about it for quite a while, but it's finally reaching completion, so stay tuned  :Wink: 

----------

## TecHunter

how to check out which refresh rate i am using?

i type fbset, the output is

```
mode "1024x768-76"

    # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz

    geometry 1024 768 1024 768 32

    timings 12714 128 32 16 4 128 4

    rgba 8/16,8/8,8/0,8/24

endmode

```

the refresh rate in the output is the real one i am using?

----------

## Proton

I still can't get past 60Hz... -sigh-

My vesafb_modes.h:

```
# 1024x768 @ 85.00Hz

       .word   1376, 1072, 1168

       .word   808, 769, 772

       .byte   0

       .long   94500000

       .word   8500

       .space  40
```

My modeline in X:

```
"1024x768"     94.50   1024 1072 1168 1376    768  769  772  808
```

My kernel version: Love-sources 2.6.5-r3

My grub boot line:

```
kernel (hd0,0)/boot/bzImage root=/dev/hda3 vga=0x517 splash=silent
```

(I've tried some others as well, especially with video=vesa and such)

Can anyone help?

----------

## akiral

Terrific ~!  :Laughing: 

My monitor is MAG 796FDII, and the CRT data :

V : 50.0 - 160.0

H : 30.0 - 96.0 

W: 203

Now , I input 

V : 150

H : 90 

W: 185

at the last , the resolution 1280x1024--84.5Hz work very well~!

I use kernel-2.6.5 ~!  :Very Happy:    Thanks anyway ~!

----------

## Ard Righ

I have a problem with this patch, and I need some help.

First, I got an "execution error" due to a typo in the patch I downloaded today. The 2nd to last line where is has

```
`ln -s $path/arch/i386/boot/vesafb_modes.h $path/arch/x86_64/boot/vesagb_modes.h`
```

Needs a semi-colon at the end of it  :Smile: 

Now, can someone help me with the editing of my vesafb_modes.h please ?

When in Gnome, I ran xvidtune, and got the following settings

HDisplay 1280

HSyncStart 1344

HSyncEnd 1504

HTotal 1728

VDisplay 1024

VSyncStart 1025

VSyncEnd 1028

VTotal 1072

Pixel Clock 157.50

Horiz Sync 91.14kHz

Vert Sync 85.02kHz

Flags (hex): 005

I didn't see any display for a +/- of either vsync or hsync ?

I want to keep my vesafb the same as Gnome, as I have the position just perfect  :Smile: 

----------

## yeoman

 *Quote:*   

> The 2nd to last line where is has
> 
> Code:
> 
> `ln -s $path/arch/i386/boot/vesafb_modes.h $path/arch/x86_64/boot/vesagb_modes.h`
> ...

 

same problem here, luckily easy to fix ....

 *Quote:*   

> I want to keep my vesafb the same as Gnome, as I have the position just perfect 

 

i also didn't manage to get the same settings for the framebuffer as in gnome. as a workaround, i choosed another resolution for the framebuffer so it won't touch my monitors settings with the resolution i use in gnome.

otherwise, if it's only the "+/- issue", why don't you just convert your xvidtune output as described in the patches readme. afaik there are only four possible settings for hsync/vsnc/+/-, so trial and error would lead to a quick solution ....

----------

## Ard Righ

I actually have it working now. I wasn't sure why it didn't work the first time, but I regenerated the vesafb_modes.h, recompiled the kernel with the generated list, rebooted to the out-of-place vesafb to make sure the higher refresh rate worked, then went back to edit in my xvidtune settings, and voila it decided to work.

 I think I may have edited too much the first time I tried it   :Embarassed: 

 In regards to the +/- sync modes, I just left the flags at "0" which according to the docs means vsync and hsync both on.

----------

## skibbi

Dosn't work with my Radeon 9800 Pro. Still 60Hz.

I think the Radeons are only VBE 2.0 like the 8000 series.

I'll try the video BIOS hack next.  :Smile: 

----------

## Regor

I've been having fits with the 0x5 modes and the nvidia kernel drivers.

Normally I use 0x51A and get 86Hz out of my monitor, but if I use nvidia drivers >4496 the console is unusable. The monitor displays nothing and goes into power-save mode.

I'm currently using nvidia 5336 because the newer versions fix another problem I was having. But that means I have to back down to mode 0x31A and 60Hz refresh.   :Crying or Very sad: 

I figure it's really a fault with nvidia's driver and nothing anyone here can do, but I needed to vent my frustration.

EDIT:

Wouldn't you know that as soon as I started whining, I'd be proven a liar. It's all working fine now. I think it was because I was missing an option to my "video=" kernel parameter.   :Embarassed: 

----------

## EMac

When I run 

```
scripts/vesa_modeline_gen.pl 
```

I got following messages:

```
syntax error at scripts/vesa_modeline_gen.pl line 152, near "print"

Execution of scripts/vesa_modeline_gen.pl aborted due to compilation errors.
```

Did anyone met it?

----------

## linP

EMac

I to    :Sad: 

I have a  Gentoo, with gentoo-dev-sources ( kernel 2.6.6-rc1 &  LILO),Nvidia GeForce 2 MX 100/200 32 MB , Samsung 765 MB khz 30-85; hz 50-160 ! 

My Monitor can do  a 1024*786*110HZ , but i have a trouble with : 

```
 

* chmod u+x /usr/src/linux/scripts/vesa_modeline_gen.pl

* /usr/src/linux/scripts/vesa_modeline_gen.pl

* Syntax errrot at  /usr/src/linux/scripts/vesa_modeline_gen.pl line 152 near "print" 

* execution  /usr/src/linux/scripts/vesa_modeline_gen.pl  aborted due to  compiliaton errors ! 

```

----------

## spock_

 *linP wrote:*   

> 
> 
> ```
>  
> 
> ...

 

Right, there was a syntax error in the Perl script. I'm sorry I wasn't able to fix it earlier, but I was away from home for two weeks. I've just uploaded an updated version of the patch, just redownload the tar.bz2 file and everything should be fine  :Smile: 

----------

## blue.sca

weird, getting a non-vesa 1600x1200 fb to work perfectly, but changing to vesa, the display is a little darker than normal and the whole screen is a little shifted, so i cant see the command prompt (nothing to do with my monitor settings, i can move them along, but no prompt).

im using iiyama provision 454, the same xvidtune-output as ikaro and and same result with any setting in vesa_modelines.h...

did anybody get a 1600x1200 vesafb to work with this settings, or does anybody know a solution? thx in advance...

----------

## Ard Righ

 *linP wrote:*   

> 
> 
> ```
> * chmod u+x /usr/src/linux/scripts/vesa_modeline_gen.pl
> 
> ...

 

 *Ard Righ wrote:*   

> First, I got an "execution error" due to a typo in the patch I downloaded today. The 2nd to last line where is has
> 
> ```
> `ln -s $path/arch/i386/boot/vesafb_modes.h $path/arch/x86_64/boot/vesagb_modes.h`
> ```
> ...

 

 I hate quoting myself, but that the error you ran into is fixed by my note above.

----------

## Assgier

thanks for this nice howto, at first i had some trouble getting the good modes (i wanted to put the monitor on 100Hz @ 1280x1024, because it can handle that, but X will not go any further as 85Hz (85.02 to be exact))...

Well anyways, at some time i decided to let the 100Hz thing go for now and just try to get this "hack" running on 85Hz... It worked out great, i now have bootsplash running together with this "hack"  :Very Happy: 

Before i start explaining what steps i have run trough, i will list my hardware:

Screen: IIyama HM903DT (Vision Master Pro 454)

Videocard: Asus V8440 (GeForce 4 Ti4400, 128 MB)

Should anyone have a good ModeLine for X (for getting the monitor to run @ 100Hz on 1280x1024) or a good vesafb_modes.h entry, please let me know, thanks in advance  :Very Happy: 

Ok so here's what i have done to make it work, all this on vanilla kernel 2.6.6 (ACCEPT_KEYWORDS="~x86" emerge development-sources).

After making bootsplash to work, i toke a look into xvidtune:

http://members1.chello.nl/~p.pieters6/pics/xvidtune.png

After that i used the red circled information with the perl script provided by the patch where this topic is all about so that i would get the exact same refreshrate as i have in X so that the monitor doesn't have to recalibrate each time i switch from X to a tty.

Then i checked if it worked, and it did  :Smile: 

 *Quote:*   

> 
> 
> # 1280x1024 @ 85.02Hz
> 
>         .word   1736, 1344, 1624
> ...

 

as you can see, exactly 85.02Hz, just like X  :Wink: 

After that i compiled the kernel (make), which gave a few errors (ignored lines in the vesafb_modes.h file), i decided to ignore them for now, "i'll have a look on those should it not work as it is now"... Put the bzImage file in it's correct place, and editted grub.conf as following:

 *Quote:*   

> 
> 
> title=Linux Gentoo 2.6.6 met vesahack
> 
> root (hd0,1)
> ...

 

I rebooted and... voila, it just worked, a nice bootsplash at 85.02Hz  :Very Happy: 

Thanks once again for this great patch  :Cool: 

----------

## garo

 *spock_ wrote:*   

> Unmount /boot, reboot and enjoy your framebuffer console at a high refresh rate. Mine is running perfectly in 1024x756 @ 85Hz 

 

756 ? strange resolution...   :Wink: 

Btw, i have a problem.I tried the patch and used the xvidtune output:

```
"1024x768"     94.50   1024 1072 1168 1376    768  769  772  808 +hsync +vsync
```

to make this "/usr/src/linux/arch/i386/boot/vesafb_modes.h":

```
#define VIDEO_VESAFB_CRTC_DATA

# 1024x768 @ 85.00Hz

        .word   1376, 1072, 1168

        .word   808, 769, 772

        .byte   0

        .long   94500000

        .word   8500

        .space  40

```

I work in X with 1024x768 at 85hz. But if i recompile my kernel and reboot (i changed the grub settings from 0x317 to 0x517) then i get 1024x768 at 83 and a bit hertz in the framebuffer and a very narrow screen.

----------

## `VL

I have ViewSonic PF775 monitor with such capabilities:

VertRefresh 50-180Hz

HorizSync   30-97kHz

Bandwidth 200MHz

When entering this parameters to script,it loops forever and so doesn`t generate file with modelines..

i tested with 2.4 kernels and 2.6,result is the same..

----------

## Assgier

 *garo wrote:*   

>  *spock_ wrote:*   Unmount /boot, reboot and enjoy your framebuffer console at a high refresh rate. Mine is running perfectly in 1024x756 @ 85Hz  
> 
> 756 ? strange resolution...  
> 
> Btw, i have a problem.I tried the patch and used the xvidtune output:
> ...

 

try your xvidtune output on the perl script coming with this patch, i couldn't use the xvidtune output directly with the vesafb_modes.h file as well, but when i used it with the perl script, it worked fine  :Smile: 

----------

## spock_

Ok people, vesafb-tng has just been released!  :Smile:  Forget the modeline_gen script, forget the recompilations and forget manual editing of the the code!

I encourage all of you who had problems with the vesafb-rrc patch to try  vesafb-tng (more info on http://dev.gentoo.org/~spock/#vesafb-tng).

Even if you didn't have any problems with the old patch - please test the new one, as the old one has just become obsolete and as the new one has a lot more features and is much easier to use.

I've tested the code on my system and it works fine. Other than that - it's untested. Your help in finding the bugs and making it better will be greatly appreciated.

----------

## dec

Any reports on how this new code works?  :Smile: 

-dec

----------

## spock_

 *dec wrote:*   

> Any reports on how this new code works? 

 

So far I've heard from about 10 happy users and from 1 user for whom vesafb-tng doesn't work (he has a Voodoo 3 gfx board). The problem he experiences is being worked on now and it'll hopefully be gone in a few days. All in all, it seems it's pretty safe to use vesafb-tng. Please remember to let me know about your results if you decide to give it a try  :Smile: 

----------

## Zaqh

Working nice here. I have some problems with patch because of bootsplash patch, but i could solve it. Runing at 1024x768-16@70 (bootsplash doesn't work with 24 or 32  :Confused:  )

----------

## boris64

seems to work nice here.

just one thing, that looks kind of funny.

when the kernel boots and loads the vesafb-driver,

everything before the vesafb driver output lines

```
...

vesafb: NVIDIA Corporation, NV28 Board, Chip Rev A0 (OEM: NVIDIA)

...

fb0: VESA VGA frame buffer device
```

is shown as white blocks and the text becomes unreadable

(is anyone here able to read white text on white background  :Smile: )

i wish i had a digicam, so i could take a picture ;P

----------

## spock_

 *borisdigital wrote:*   

> when the kernel boots and loads the vesafb-driver,
> 
> everything before the vesafb driver output lines
> 
> is shown as white blocks and the text becomes unreadable
> ...

 

Quote from my page:

NOTE: The white rectangle that appears after loading the driver is not a vesafb bug. Please do not report it to me. This is a known bug in the fbcon code, a fix for it already exists and it will hopefully be included in the future versions of the Linux kernel.

 *borisdigital wrote:*   

> i wish i had a digicam, so i could take a picture ;P

 

No need to, everyone will be able to see it when they install vesafb-tng  :Wink: 

Anyway, thanks for the it-works report  :Smile: 

----------

## boris64

lol,  :Razz: 

sorry for not reading your manual hard enough  :Embarassed: 

of course your patch works fine here  :Smile: 

----------

## Brazil

Can I finnaly put 1920x1200@85Hz for my nvidia card, or is this just probing and preparing the modes available for the fb driver?

I want my widescreen monitor to work in vesa damnit!

-Brazil

----------

## spock_

 *Brazil wrote:*   

> Can I finnaly put 1920x1200@85Hz for my nvidia card, or is this just probing and preparing the modes available for the fb driver?
> 
> I want my widescreen monitor to work in vesa damnit!

 

The driver gets a mode list (you can then see a list of all available modes in /proc/fb0/modes) from the VESA BIOS. If your BIOS provides a 1920x1200 mode - then sure, you can. If it doesn't - well, there's not much that can be done with vesa. It might be better to switch to a driver made specifically for your type of graphic board (rivafb for example, if you're using a nVidia board).

----------

## Pubare

Vesafb-tng doesn't seem to be working for me...  I'm using ck-sources 2.6.7-r1 on a Via MVP3 motherboard with a Geforce2MX-200.  Same basic kernel config as used with the vesafb-rrc patch on kernel 2.6.4-ck2, which works wonderfully (thanks for the great patches) - agpgart is built as module with no other fb devices.  Kernel command line in grub is:

kernel /kernel-2.6.7-ck1 root=/dev/ram0 init=/linuxrc real_root=/dev/hdg3 theme=NewTux splash=silent video=vesa:ywrap,mtrr,1280x1024-16@85  reboot=w

This is the same mode I use (via the vga=0x51A  parameter) with the -rrc without issue.  I've tried stepping it down to 1024x768-16@60 and even eliminating the modeline all together without luck.  It displays the following, then the boot process stops:

vesafb: NVidia Corporation, NV11 Board, Chip Rev B2

vesafb: VBE version: 3.0

vesafb: pmi: set display start = c00cc355, set palette = c00cc3da

vesafb: pmi: ports = [long range of ports I didn't feel like writing down]

vesafb: hardware supports DCC2 transfers

At this point I have to powercycle the PC, as it just stays there indefinitely.  Thoughts, suggestions, or fixes?

...and thanks for the great work on the patches.  I _like_ having a readable console without eye-strain.

----------

## bobby p rajan

 *Quote:*   

> 
> 
> Vesafb-tng doesn't seem to be working for me... I'm using ck-sources 2.6.7-r1 on a Via MVP3 motherboard with a Geforce2MX-200. Same basic kernel config as used with the vesafb-rrc patch on kernel 2.6.4-ck2, which works wonderfully (thanks for the great patches) 
> 
> 

 

i am having exactly the same problem, the rrc patch is working fine with 2.6.7-rc3-mm1 on my pc. i am using mm-sources-2.6.7-rc3-mm2. the card is a ge-force-4 mx-440 with 64 mb.

i am willing to do any testing to make this work

bobby

----------

## spock_

 *Pubare wrote:*   

> 
> 
> vesafb: NVidia Corporation, NV11 Board, Chip Rev B2
> 
> vesafb: VBE version: 3.0
> ...

 

It seems it hangs while trying to get EDID data. You can try the 'noedid' option - edit your kernel param line to: 

```
kernel /kernel-2.6.7-ck1 root=/dev/ram0 init=/linuxrc real_root=/dev/hdg3 theme=NewTux splash=silent video=vesa:ywrap,mtrr,noedid,1280x1024-16@85  reboot=w
```

 and see if this changes anything. 

BTW, it would be best to test vesafb-tng on vanilla kernel sources (ie. sys-kernel/development-sources) - one can never be sure if there isn't something in -ck or -mm that affects how vesafb-tng works.

----------

## rc

Hi,

this maybe kinda OT but i want to give some feedback.

Im running Archlinux rightnow and your patch is working well with selfcompiled 2.6.4 and 2.6.7 Kernels.

Im using 1024x768@85Hz for my console.

To calculate apropriate settings with the script i used my regular monitor timings, but for the horizontal frequence i used 68khz.

Why 68khz ?

My X resolution is 1280x1024@85Hz wich results in 91khz horizontal frequency (i can check this in my monitors osd).

So i divided 91khz by 1024 and multiplied the result with 768. The result was 68250Hz.

I rounded this down to 68khz.

And with these settings my console runs fine at the desired resolution.

Maybe a bit complicated, but for me it was the easiest solution (didn't want to edit some files).

greetings,

rc

----------

## zidour

I run gentoo with framebuffer console support. Recently I upgraded kernel to version 2.6.7 and tried to patch kernel with vesafb-tng patch. 

Here is the code:

```

[19:13 root@fagot /usr/src/linux]# bzip2 -dc /usr/src/linux/vesafb-tng-0.9-rc1-2.6.7.patch.bz2 | patch -p1

patching file arch/i386/boot/video.S

patching file Documentation/fb/vesafb.txt

patching file drivers/video/fbmem.c

patching file drivers/video/Kconfig

patching file drivers/video/Makefile

Hunk #1 succeeded at 44 (offset 1 line).

patching file drivers/video/vesafb.c

Hunk #6 FAILED at 245.

Hunk #7 succeeded at 471 (offset 3 lines).

Hunk #8 succeeded at 498 (offset 3 lines).

Hunk #9 succeeded at 519 (offset 3 lines).

Hunk #10 succeeded at 813 (offset 3 lines).

Hunk #11 succeeded at 852 (offset 3 lines).

Hunk #12 succeeded at 882 (offset 3 lines).

Hunk #13 succeeded at 1122 (offset 3 lines).

1 out of 13 hunks FAILED -- saving rejects to file drivers/video/vesafb.c.rej

patching file drivers/video/vesafb-thread.c

patching file include/video/vesa.h

```

It means that patching the vesafb.c file failed, resulting in kernel that I cannot compile.

```

  CC      drivers/video/vesafb.o

drivers/video/vesafb.c:260: error: `vesafb_check_var' undeclared here (not in a function)

drivers/video/vesafb.c:260: error: initializer element is not constant

drivers/video/vesafb.c:260: error: (near initialization for `vesafb_ops.fb_check_var')

drivers/video/vesafb.c:263: error: `vesafb_set_par' undeclared here (not in a function)

drivers/video/vesafb.c:263: error: initializer element is not constant

drivers/video/vesafb.c:263: error: (near initialization for `vesafb_ops.fb_set_par')

drivers/video/vesafb.c:268: error: `vesafb_probe' undeclared here (not in a function)

drivers/video/vesafb.c:268: error: initializer element is not constant

drivers/video/vesafb.c:268: error: (near initialization for `vesafb_driver.probe')

drivers/video/vesafb.c:274: error: `vesafb_platform_release' undeclared here (not in a function)

drivers/video/vesafb.c:274: error: initializer element is not constant

drivers/video/vesafb.c:274: error: (near initialization for `vesafb_device.dev.release')

drivers/video/vesafb.c:275: error: initializer element is not constant

drivers/video/vesafb.c:275: error: (near initialization for `vesafb_device.dev')

drivers/video/vesafb.c: In function `vesafb_probe':

drivers/video/vesafb.c:754: warning: implicit declaration of function `vesafb_find_vbe_mode'

drivers/video/vesafb.c:772: warning: implicit declaration of function `vesafb_setup_var'

drivers/video/vesafb.c: At top level:

drivers/video/vesafb.c:558: warning: `vesafb_probe' defined but not used

make[2]: *** [drivers/video/vesafb.o] Error 1

make[1]: *** [drivers/video] Error 2

make: *** [drivers] Error 2

```

I'm not a linux expert, may be I am doing something completely wrong.

Can anybody help?

----------

## Mr_Maniac

I cannot use the vesafb_tng-Patch, too...

But the vesavb-rrc Patch works fine for the kernel 2.6.7!

----------

## spock_

 *zidour wrote:*   

> I run gentoo with framebuffer console support. Recently I upgraded kernel to version 2.6.7 and tried to patch kernel with vesafb-tng patch. 

 

Please send me drivers/video/vesafb.c.rej and I'll tell you what to do  :Smile: 

Are you experiencing this problem with a vanilla (ie. development-sources) kernel?

----------

## rc

Hi again,

tried the tng patch now and it works fine for me.

It even solved some minor problems i had.

For example it seems like i dont need that 

```
Option      "IgnoreDisplayDevices" "TV"
```

 in my X config file.

I installed the patch by running 

```
bzip2 -dc vesafb-tng-0.9-rc1-2.6.7.patch.bz2 | patch -p1
```

 in /usr/src/linux. I also copied the patch file to this position.

greetings,

rc

----------

## danone

Well the vesafb_tng also does not work here have a Leadtek NVidia GeforceFX 5900 and it only goes in 320x320 video mode and that at a 19"..my kernelboot params are video=vesa:ywrap,mtrr,1280x1024-16@85

tried with ypan and also no success

VGA BIOS is VBE 2/3 compatible

----------

## zidour

 *spock_ wrote:*   

> 
> 
> Please send me drivers/video/vesafb.c.rej and I'll tell you what to do :)
> 
> Are you experiencing this problem with a vanilla (ie. development-sources) kernel?

 

I am sorry, I can't send you the file at the moment. May be tomorrow.

I am experiencing this problem with gentoo-dev-sources.

----------

## spock_

 *zidour wrote:*   

> I am experiencing this problem with gentoo-dev-sources.

 

That explains everything. For all of you, who want to test vesafb-tng on g-d-s I've just made a special patch: http://dev.gentoo.org/~spock/projects/vesafb-tng/vesafb-tng-0.9-rc1-r1-2.6.7-gentoo.patch.bz2.

Have fun  :Smile: 

----------

## spock_

For those of you, for whom vesafb-tng doesn't work at all (you get some weird errors and a kernel hand during boot-up) - please use http://dev.gentoo.org/~spock/projects/vesafb-tng/vesafb-tng-test-20040620.patch.bz2.

This patch will increase vesafb-tng's verbosity. Please save your dmesg if possible and send it to me. I'll try to find out what's wrong and fix it.

----------

## s4n

 *spock_ wrote:*   

>  *zidour wrote:*   I am experiencing this problem with gentoo-dev-sources. 
> 
> That explains everything. For all of you, who want to test vesafb-tng on g-d-s I've just made a special patch: http://dev.gentoo.org/~spock/projects/vesafb-tng/vesafb-tng-0.9-rc1-r1-2.6.7-gentoo.patch.bz2.
> 
> Have fun 

 

i applied the patch and compiled kernel without errors, system rebooted but i have still 60hz

dmesg seems fine:

vesafb: NVIDIA Corporation, NV35 Board - p177h-1n, Chip Rev (OEM:NVIDIA)

vesafb: VBE version: 3.0

vesafb: protected mode interface info at c000:f510

vesafb: pmi: set display start = c00cf546, set palette = c00cf5b0

vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c2 3c3 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da

vesafb: hardware supports DCC2 transfers

vesafb: EDID vendor sign: GSM

vesafb: monitor limits: vf = 200 Hz, hf = 107 Khz, clk = 230 Mhz

vesafb: total memory: 134217728

vesafb: scrolling: wrap using protected mode interface, yres_virtual=52428

vesafb: framebuffer at 0xf0000000, mapped to 0xe0808000, size 131072k

fb0: VESA VGA frame buffer device

while grub.conf is like this:

kernel /kernel-2.6.7-gentoo root=/dev/hda6 video=vesafb:ywrap,mtrr,1280x1024-16@85 splash=silent

i tried some other combinations but result didn't change

any ideas?

----------

## spock_

Did vesafb-rrc work for you in the past (if you used it)? Have you tried adding 'gtf' to kernel parameters? Have you tried other modes (eg. 800x600-16@85)? Have you tried to set a mode with a higher refresh using fbset (instructions on how to do it can be found in the first post in this topic)?

----------

## s4n

 *spock_ wrote:*   

> Did vesafb-rrc work for you in the past (if you used it)? Have you tried adding 'gtf' to kernel parameters? Have you tried other modes (eg. 800x600-16@85)? Have you tried to set a mode with a higher refresh using fbset (instructions on how to do it can be found in the first post in this topic)?

 

yes i  tried first the vesafb-rrc but it gava errors while patching  :Sad: 

yes i have tried 800 and 1024 modes without any result

fbset tell me that mode is 1280x1024-85, when i start X it goes effectively to 85hz

didn't try the 'gtf' option, where do i have to put it exactly?

thx  :Very Happy: 

----------

## spock_

 *s4n wrote:*   

> yes i  tried first the vesafb-rrc but it gava errors while patching 
> 
> yes i have tried 800 and 1024 modes without any result
> 
> fbset tell me that mode is 1280x1024-85, when i start X it goes effectively to 85hz
> ...

 

You have to change your kernel parameters line to:

```
kernel /kernel-2.6.7-gentoo root=/dev/hda6 video=vesafb:ywrap,mtrr,gtf,1280x1024-16@85 splash=silent
```

As for fbset, you can try to get a framebuffer console @ 85Hz in the following way:

- boot and get a console @ 60Hz

- start X and switch to the mode you'd like to have on console

- do xvidtune -show | ./modeline2fb.pl >> /etc/fb.modes

- then, on console, execute fbset 1280x1024 - this should switch framebuffer to 1280x1024 with a higher refresh rate.

This is described in detail in the first post in this thread.

----------

## s4n

 *spock_ wrote:*   

> You have to change your kernel parameters line to:
> 
> ```
> kernel /kernel-2.6.7-gentoo root=/dev/hda6 video=vesafb:ywrap,mtrr,gtf,1280x1024-16@85 splash=silent
> ```
> ...

 

i did the change but no improvement in refresh rate  :Sad: 

 *spock_ wrote:*   

> As for fbset, you can try to get a framebuffer console @ 85Hz in the following way:
> 
> - boot and get a console @ 60Hz
> 
> - start X and switch to the mode you'd like to have on console
> ...

 

i tried 1280 and 1024, in both cases the screen becomes a mixture of colors, i must use 'clear' to clean the console (still 60hz btw)

----------

## ixogn

 *Quote:*   

> # Run a script to set the CRTC data (this an equivalent of XFree86 Modelines).
> 
> Code:
> 
> chmod u+x /usr/src/linux/scripts/vesa_modeline_gen.pl
> ...

 

i've got no vesa_modeline_gen.pl in /usr/src/linux/scripts/  :Embarassed: 

----------

## spock_

 *ixogn wrote:*   

> i've got no vesa_modeline_gen.pl in /usr/src/linux/scripts/ 

 

This script is only necessary if you're using vesafb-rrc. With vesafb-tng it's not longer needed. In case you're using vesafb-tng, please follow the instructions on http://dev.gentoo.org/~spock/#vesafb-tng.

----------

## s4n

 *spock_ wrote:*   

> Did vesafb-rrc work for you in the past (if you used it)?

 

i retried and i successfully patched the kernel, but i still get 60hz...  :Sad: 

----------

## zidour

 *spock_ wrote:*   

> 
> 
> That explains everything. For all of you, who want to test vesafb-tng on g-d-s I've just made a special patch: http://dev.gentoo.org/~spock/projects/vesafb-tng/vesafb-tng-0.9-rc1-r1-2.6.7-gentoo.patch.bz2.
> 
> Have fun :)

 

Thank you. Now everything works fine.

----------

## SuSEQ

I'm trying to get vesafb-tng to work, but as of now, I'm not very succesful...  It hangs just after the VBE detection.  The verbosity patch fails when applying hunk #6; the other patch, however, apllied successfully

I have the 2.6.7-r5 gentoo-dev sources, and an nVidia Ti 4600-core quadro.  The used append line in lilo: "video=vesafb:124x768-24@85,mtrr,ywwrap,vram:16".  The specification of vram:16 doesn't do much to the problem; also, the kernel complains about an incorrect videomode...

Gr,  SuSEQ

----------

## ikaro

runs cool here at 1600x1200@85  :Smile: 

thanks for the update

----------

## deNniZ

Works nice on my box with gentoo-dev-sources at 1280x1024-16@85!

I have only a small problem with my splashscreen, vesafb semms to get loaded too late so there's some white gfx error on a grey bootsplash looks weird, but goes away after scrolling!

any help would be appreciatet!

keep up the nice work!

----------

## ikaro

spock:

little problem with the screen geometry.

I get the framebuffer about 10 mm outside of the screen to the left.

so when i get back to X the image is 10mm ouside the screen to the right.

1600x1200@85 both Fb and X

----------

## spock_

 *Quote:*   

> I have only a small problem with my splashscreen, vesafb semms to get loaded too late so there's some white gfx error on a grey bootsplash looks weird, but goes away after scrolling! 

 

This sounds like the white rectangle problem, a known bug in fbcon code, which will hopefully be fixed soon. It hasn't really anything to do with vesafb-tng. You will get it when using other non-vesafb drivers (rivafb for example), too.

 *ikaro wrote:*   

> spock:
> 
> little problem with the screen geometry.
> 
> I get the framebuffer about 10 mm outside of the screen to the left.
> ...

 

You can use fbset to correct it (have your X modeline converted to fb.modes format) or you can try the 'gtf' kernel parameter, but I doubt the results of the latter one will be as good as you expect of it. Still, it might be worth a try  :Smile: 

----------

## nojon

I have also tried your vesafb-tng patch - I have not ever tried the previous one. However it does not seem to work here ( nVidia GeForce 4 MX 440 SE ). I've sent the output to you per eMail. Reading threw the thread I have a feeling that the patch does not work for (m)any nVidia graphics cards. If I can help you debug it please tell me how.

----------

## Pubare

Sorry I didn't post back sooner, been a hectic week...  The noedid option did the trick for me (suspected it was something along these lines), works just fine.  Thanks for the patch and the fix.

----------

## ikaro

[quote="spock_"] *Quote:*   

> 
> 
> You can use fbset to correct it (have your X modeline converted to fb.modes format) or you can try the 'gtf' kernel parameter, but I doubt the results of the latter one will be as good as you expect of it. Still, it might be worth a try 

 

right. but then it kinda defeats the pourpose of using this new patch instead of the 'old one' where it just worked.

oh well ....

----------

## ennservogt

I just can't believe that my Radeon 9500 does not support the

required VBE standard...  :Sad:  But I just can't get the framebuffer device to work at the desired refresh rates and resolutions.

I have tried the vanilla sources, the gentoo development sources, the rcc version and the latest tng version of the patch. Neither of them worked  :Sad: 

So is anyone out there who can confirm that the Radeon 9500 does not or does work with the rcc or tng refresh rate fix?

PS: It would help a lot if anybody posting a report in the future also writes which video card he uses.

Thanks in advance...

EnnserVogt

----------

## spock_

I'm happy to announce the availability of a new version of vesa-tng (0.9-rc2). If the previous versions didn't work for you, please give this one a try and let me know about your results. Links to the new patch can be found on my devsite http://dev.gentoo.org/~spock/.

 *ennservogt wrote:*   

> I just can't believe that my Radeon 9500 does not support the required VBE standard...  But I just can't get the framebuffer device to work at the desired refresh rates and resolutions.

 

As strange as it seems, AFAIK Radeons only support VBE2.0, which is not enough to change the refresh rate. You can check you board's VBE version in /proc/fb0/vbe_info or in dmesg.

 *ikaro wrote:*   

> right. but then it kinda defeats the purpose of using this new patch instead of the 'old one' where it just worked.

 

Well, it's for users to decide which one to use. vesafb-tng is far more advanced than vesafb-rrc and it gives you options you'd never have with the old patch (like setting/adjusting mode after bootup is complete). The modes you get with vesafb-tng may not be perfect, but they should be good enough. Even board-specific drivers like rivafb don't always give you the perfect mode you'd want. Sometimes things just have to be adjusted manually  :Wink: 

----------

## nojon

Hurray - with rc2 it works for my GeFroce 4 MX 440, too - thanks for a great patch.

----------

## SuSEQ

I'm having trouble patching the gentoo-dev-2.6.7-rc6 sources; the previous patch patched OK, but it didn't work like it should.

```
patching file drivers/video/vesafb.c

Hunk #6 FAILED at 246.

Hunk #7 succeeded at 474 (offset 3 lines).

Hunk #8 succeeded at 501 (offset 3 lines).

Hunk #9 succeeded at 522 (offset 3 lines).

Hunk #10 succeeded at 824 (offset 3 lines).

Hunk #11 succeeded at 863 (offset 3 lines).

Hunk #12 succeeded at 893 (offset 3 lines).

Hunk #13 succeeded at 1159 (offset 3 lines).

1 out of 13 hunks FAILED -- saving rejects to file drivers/video/vesafb.c.rej
```

As I'm no C guru, I'm not exactly confident to patch the file by hand...

//edit: but I did it - new kernel is now compiling... Fingers crosed!

Greets,  SuSEQ

----------

## spock_

 *SuSEQ wrote:*   

> I'm having trouble patching the gentoo-dev-2.6.7-rc6 sources; the previous patch patched OK, but it didn't work like it should.

 

You can use this patch if you want to try vesafb-tng on gentoo-dev-sources-2.6.7-r6.

----------

## Dolio

Hi.

I'm running a slightly modified version of the 2.6.7-ck2 kernel. It comes with the bootsplash patch, and I was using vesafb-rrc with it. However, with your latest patch, I decided to switch to tng, and it works great except that bootsplash no longer works.

To apply the tng patch (after I unpatched rrc), I had to temporarily modify drivers/video/vesafb.c, changing

```
#ifndef CONFIG_BOOTSPLASH

static

#endif

struct fb_ops vesafb_ops {
```

to

```
static struct fb_ops vesafb_ops {
```

Then the patch applied without failure and I modified it back. Could I have screwed up here? Just eliminating the check for CONFIG_BOOTSPLASH fails, of course.

Do I need a bootsplash patch newer than 3.1.4? I noticed there's a newer one that runs on any framebuffer (which will be useful once switching between rivafb and X doesn't lock my machine.  :Smile:  Good work).

I noticed that /proc/splash is gone, if that helps any. I've triple checked my kernel config, compiling and rebooting in between. I've reinstalled bootsplash. But now I'm stuck.

Thanks for any help you can give.

----------

## Cicero

I was coming to post the same thing as Dolio. I have the "white rectangle problem" and no bootsplash. I noticed that there's another version of bootsplash that's modified by you. Should I try that, or is the lack of bootsplash related to the fbcon problem?

Another thing, it takes quite a while from the time that grub starts booting the kernel to the time that it actually switches modes, whereas with the previous patch, it switched modes immediately (but the bootsplash didn't come up for a while). Is that just a side effect of something or what? It wouldn't be as much of a problem if 2.6 didn't have so much trouble starting to boot...

----------

## spock_

 *Dolio wrote:*   

> Do I need a bootsplash patch newer than 3.1.4? I noticed there's a newer one that runs on any framebuffer (which will be useful once switching between rivafb and X doesn't lock my machine.  Good work).

 

First of all, if you have a bootsplash-patched kernel, you can apply the vesafb-tng patch for gentoo-dev-sources.

You don't really need any specific version of bootsplash to get it working with vesafb-tng. With non-gentoo bootsplash patches it's necessary to make sure that the mode one is running has a depth of 16bpp (for example: 1024x768-16@85). With the bootsplash patch from Gentoo

it's possible to get it working in 24bpp and 32bpp modes, too.

 *Dolio wrote:*   

> I noticed that /proc/splash is gone, if that helps any. I've triple checked my kernel config, compiling and rebooting in between. I've reinstalled bootsplash. But now I'm stuck.

 

Do you run a 16bpp mode? If yes, please post /proc/cmdline and output of `fbset`.

----------

## spock_

 *Cicero wrote:*   

> I was coming to post the same thing as Dolio. I have the "white rectangle problem" and no bootsplash. I noticed that there's another version of bootsplash that's modified by you. Should I try that, or is the lack of bootsplash related to the fbcon problem?

 

The white rectangle problem has nothing to do bootsplash. It might be a good  idea to try the modified bootsplash, because it works with more modes.

 *Cicero wrote:*   

> Another thing, it takes quite a while from the time that grub starts booting the kernel to the time that it actually switches modes, whereas with the previous patch, it switched modes immediately (but the bootsplash didn't come up for a while). Is that just a side effect of something or what? It wouldn't be as much of a problem if 2.6 didn't have so much trouble starting to boot...

 

With the standard vesafb (patched with -rrc, or not), the mode switch happends before the kernel is actually loaded - ie. in the very first steps of the boot-up process. With vesafb-tng this has been changed and the fb driver is initialised like any other (try radeonfb or rivafb for comparison  :Smile: ).

You can't exactly call this a side effect - because this is how all fb drivers behave. It's only vesafb that was a little different and that's why the time of the mode switch might seem a little strange now.

----------

## Dolio

I thought I was running in 16 bpp mode, but it appears I'm not...

/proc/cmdline:

 *Quote:*   

> root=/dev/hde6 video=vesa:1280x1024-16@85,ywrap,mtrr splash=silent

 

fbset:

 *Quote:*   

> mode "1280x1024-85"
> 
>     # D: 157.505 MHz, H: 91.149 kHz, V: 85.027 Hz
> 
>     geometry 1280 1024 1280 1024 8
> ...

 

So it looks like it's running in 8 bpp?

I'm not at home right now, so I can't make changes.  Later I'll reverse my semi-hand-applied patch and try out the patch for gentoo-dev-sources and see if that makes a difference.  Thanks for your help.

----------

## spock_

 *Dolio wrote:*   

> So it looks like it's running in 8 bpp?

 

Check your /proc/fb0/modes for 1280x1024-16. It's possible that your VBE only supports 1280x1024 with 8bpp depth, in which case setting a 8bpp mode is expected behaviour.

----------

## Dolio

No, 1280x1024-16 is in there.

And I've been using 1280x1024-16@85 on vesafb-rrc for a while now.

----------

## SuSEQ

I tried to boot the kernel with the rc2 patch, but it halted right after the VBE3.0 line...

Gr,  SuSEQ

----------

## Cicero

Ok, I was running in 32bpp mode. I assume the gentoo bootsplash patch you are referring to is

/usr/share/bootsplash/bootsplash-3.1.4-sp-2.6.7.patch.bz2     :Question: 

I'll give it a try and see if it works with 32bpp mode.

[edit: working now. Great patch, as usual  :Smile:  ]Last edited by Cicero on Wed Jun 30, 2004 4:19 am; edited 1 time in total

----------

## Dolio

FYI: I reversed the plain fbtng patch, and applied the gentoo-dev patch.

However, it doesn't work for me. I get the same error as when I first patched it myself:

 *Quote:*   

> drivers/built-in.o(.text+0xa8b06): In function `splash_getraw':
> 
> : undefined reference to `vesafb_ops'

 

My C keywords are a little rusty, but the cause of this is that vesafb_ops is declared static, like so:

```
static struct fb_ops vesafb_ops
```

Rather than depending on whether bootsplash support is compiled in:

```
#ifndef CONFIG_BOOTSPLASH

static

#endif

struct fb_ops vesafb_ops
```

So apparently in my bootsplash patch (3.1.4 from ck2 sources) vesafb_ops needs to be visible outside vesafb.c (not totally surprising considering the two are tied together), but it isn't.

I assume the fix to this is the framebuffer-independant bootsplash patch, which I'll try presently.

----------

## Dolio

No luck.

The 3.1.4-sp1 bootsplash patch compiles with the latest tng patch. But I still get 8 bpp at bootup.

I can use fbset to reset my framebuffer to 1280x1024-16@85 after I boot in, and bootsplash will work then. But during the boot process, it goes into 1280x1024-8@85 and bootsplash doesn't work.

----------

## spock_

 *Dolio wrote:*   

> I can use fbset to reset my framebuffer to 1280x1024-16@85 after I boot in, and bootsplash will work then. But during the boot process, it goes into 1280x1024-8@85 and bootsplash doesn't work.

 

Please try changing 'vesa:' to 'vesafb:' on your kernel parameter line. If this doesn't work, pm me with the contents of /proc/fb0/vbe_info, /proc/fb0/modes and `dmesg` output.

----------

## Dolio

I'm not there to see the console right now, but that appears to have made it boot into 16 bpp mode.

Apparently the problem is that I just can't read.  :Smile:  I apologize.

----------

## MoreCoffeePlease

Hi,

Ummmmm... Not for the first time, and I'm sure not for the last either, I'm a bit confused.

To date I've got a working bootsplash and fancy consoles on a 2.4.25 kernel that are currently at the dreaded 60hz at 1024x768, with nvidia-kernel working great when 'startx'ing running at 1024x768 at 85hz.

The relevant bits (I think) of my current lilo.conf are..

vga=791

append"video=vesa:ywrap,mtrr"

Whoo-hoo. So far.   :Razz: 

But the dreaded 60hz for the console.....  

Questions:

A) Do I need to install the vesafb-tng patch to fix this, or can I alter my lilo.conf and also use the current nvidia-kernel settings for the console?

B) Will the patch work on a 2.4.25 kernel?  The link only mentions 2.6 kernels.

C) If I do patch, after I rebulid the new kernel, I also need to re-emerge the nvidia-kernel, right?

Thanks for any help to clear this up.....

----------

## SuSEQ

nvidia-kernal is for X-windows support, not for console...  You'll have to use this patch, or the older one by the same author.

The older version (not vesafb-tng) ought to work on your 2.4 kernel, but I do think this one will, too.

Yes, you need to re-emerge nvidia-kernel.

Gr,  SuSEQ

----------

## MoreCoffeePlease

Ummm.

I think I broke something!

I tried the latest patch, and it gave me lots of patching errors, so I (hopefully) reversed it out, and applied the rrc patch.

Now when I try to build a new kernel, I either get an error 

```
fbmem.c:34:24: /video/vesa.h: no such file or directory
```

or if I copy the vesa.h from /usr/src/linux-2.4.25-gentoo-r4/fb/vesa.h I get 

```
video.S:677 error: Symbol 'check_vesa' is already defined

```

along with another symbol already defined error.

Help!  I broke it!  Anyone with any ideas?!   :Crying or Very sad: 

Thanks.

----------

## SuSEQ

Re-emerge your kernel sources and re-apply the rrc patch, if you want to use that one...

I'm afraid that 'll be the only thing you can do... :-/

Gr,  SuSEQ

----------

## Pubare

When trying new patches, it is always a good idea to -

"patch -p1 --dry-run<vesafb*"

Assuming of course you have the vesafb patch extracted to the kernel source directory...  If the dry-run option gives failures (for nearly any file, there are a few safe to ignore), _don't_ apply the patch unless you know what failed and why and how to fix it.  Even using the -R option afterwards can still leave you with a borked source tree.

----------

## MoreCoffeePlease

Yup, managed to emerge the sources, and I can build kernels again.

I think for now I'll live with 60hz....

Thanks.

----------

## Jazz

Ok i run the command but i get the error 

```
root@Matrix{/home/jazz}> /usr/X11R6/bin/xvidtune -show | ./modeline2fb.pl >> /etc/fb.modes

Illegal division by zero at ./modeline2fb.pl line 22, <STDIN> line 1.

```

Any ideas ?

BYe,

Jazz[/code]

----------

## redix

Im ATI R9700 PRO user and im prefer workin` from console. On X im usin` fglrx. Problem was that my visit to X ended up with frozen box after ending X session. No patch work for me, coz R300 boards r only VBE2.0 ??!!??. ATI seems to prefer other ways to work with signals  :Smile: . So my chance to cooperate with console and X with higher refresh rates was zero. Hard to decide if take 85Hz on console and run X without 3D (with radeon module) or run poor console and get 3D accel on X with fglrx.

Finaly, the only thing to do with ATI is reflash VGA BIOS.

howgh

----------

## nojon

This may be of interest to nVidia users :

As some of you may know nVidia graphics cards are a mess when it comes to switching between a MultiHead / Twinview display and the vesafb-console window - it simply gets corrupted. And now the good thing : vesafb-tng solves this bug - the vesa console does not get corrupted anymore when switching between X and framebuffer console !

Good news for nVidia users !!!

Considering the fact that the vesafb-tng patch solves a major bug for probably a huge number of linux boxes how good are the chances that this patch will be applied to vanilla linux ?

----------

## MaxDamage

 *nojon wrote:*   

> Considering the fact that the vesafb-tng patch solves a major bug for probably a huge number of linux boxes how good are the chances that this patch will be applied to vanilla linux ?

 

Or to the gentoo-dev-sources. I have an ATI 9600 Pro and also get a messed X when I switch from the framebuffer console, 1 of each 100 times. And this 60Hz annoyance is really stupid. Will try the patch to see if it works.

** EDIT **

The patch failed to apply so I used the vesafb-tng-0.9-rc2-2.6.7-gentoo.patch.bz2 one (compiling gentoo-dev-sources 2.6.7-r8 with genkernel). Patched cleanly

```
bzip2 -dc /home/marcos/Download/vesafb-tng-0.9-rc2-2.6.7-gentoo.patch.bz2 | patch -p1

 genkernel --menuconfig all

```

but the kernel didn't compile

```
  LD      .tmp_vmlinux1

drivers/built-in.o(.text+0x9cfc6): En la funci?n `splash_getraw':

: undefined reference to `vesafb_ops'

make: *** [.tmp_vmlinux1] Error 1

* ERROR: Failed to compile the "bzImage" target...

```

Any ideas?

----------

## MaxDamage

 *spock_ wrote:*   

>  *SuSEQ wrote:*   I'm having trouble patching the gentoo-dev-2.6.7-rc6 sources; the previous patch patched OK, but it didn't work like it should. 
> 
> You can use this patch if you want to try vesafb-tng on gentoo-dev-sources-2.6.7-r6.

 

Somebody got the 2.6.7 gentoo-dev-sources patched and working?

----------

## spock_

 *MaxDamage wrote:*   

> Somebody got the 2.6.7 gentoo-dev-sources patched and working?

 

You can manually find the line 'static struct fb_ops vesafb_ops (...)' in drivers/video/vesafb.c and remove the word 'static' to make it work.

----------

## MaxDamage

I applied the gentoo patch, made the change, and then genkernel worked smoothly. I will see if the patch works in the next reboot.

----------

## Dinini

 *Jazz wrote:*   

> 
> 
> ```
> root@Matrix{/home/jazz}> /usr/X11R6/bin/xvidtune -show | ./modeline2fb.pl >> /etc/fb.modes
> 
> ...

 

Are you sure you're running that command in an Xwindows terminal session? That's the error you'd receive if the "/usr/X11R6/bin/xvidtune -show" command produced an error message rather than a valid modeline.  Try it by itself first to verify output before piping the output to ./modeline2fb.pl

----------

## deNniZ

 *nojon wrote:*   

> This may be of interest to nVidia users :
> 
> As some of you may know nVidia graphics cards are a mess when it comes to switching between a MultiHead / Twinview display and the vesafb-console window - it simply gets corrupted. And now the good thing : vesafb-tng solves this bug - the vesa console does not get corrupted anymore when switching between X and framebuffer console !
> 
> Good news for nVidia users !!!
> ...

 

I can agree i tried it and my pc never crashed again when exiting XFree with twinview enabled, this is really really nice! Now i can use twinview! The only problem is, if i use a fbdevice higher than 800x600 everything is like before (my PC crashes when exiting X). Dunno why...

Ok for the stats:

I have a 

GF4ti4200 AGP 8x (NV28)

Gentoo-dev-sources 2.6.7 patched for fb-tng

If sumone needs more infos ask me!

Yeah twinview rocks FB-tng rocks u rock!

keep it up!

----------

## MaxDamage

I haven't been able to change the refresh rate. I must be doing something wrong, lot of resolution just corrupt the framebuffer ad the ones that work do at 60Hz. I have some questions:

Has some relation the parameter in the kernel line 

```
video=vesafb:ywrap,mtrr,1024x768-16@75
```

with the ones defined in /etc/fb.modes?

I may probably have messed the config files up. How could I regenerate fb.modes?

Could somebody post the grub line for the kernel and the fb.modes part that correspond?

When I try fbset 1152x864 with the config generated by the perl scrypt, I get this message: 

```
ioctl FBIOPUT_VSCREENINFO: Invalid argument
```

 The config is what I'm using in X.

```
mode "1152x864"

   # D: 108.30 MHz, H: 70.51 kHz, V: 78.00 Hz

   geometry 1152 864 1152 864 32

   timings 9233 88 56 26 2 240 12

endmode
```

 I don't know what's the problem.

Thanx a lot.

----------

## Rafje

Works great. Thanks Spock_!

Just wanted to let you know that the gentoo-dev-sources 2.6.7-r9 don't accept the vesafb-tng patch:

```
mokka linux-2.6.7-gentoo-r9 # pwd

/usr/src/linux-2.6.7-gentoo-r9

mokka linux-2.6.7-gentoo-r9 # bzip2 -dc /root/DL/vesafb-tng-0.9-rc2-2.6.7-gentoo.patch.bz2 | patch -p1

patching file arch/i386/boot/video.S

patching file Documentation/fb/vesafb.txt

patching file drivers/video/fbmem.c

patching file drivers/video/Kconfig

patching file drivers/video/Makefile

patching file drivers/video/vesafb.c

Hunk #6 FAILED at 246.

Hunk #7 succeeded at 468 (offset -3 lines).

Hunk #8 succeeded at 495 (offset -3 lines).

Hunk #9 succeeded at 516 (offset -3 lines).

Hunk #10 succeeded at 818 (offset -3 lines).

Hunk #11 succeeded at 857 (offset -3 lines).

Hunk #12 succeeded at 887 (offset -3 lines).

Hunk #13 succeeded at 1153 (offset -3 lines).

1 out of 13 hunks FAILED -- saving rejects to file drivers/video/vesafb.c.rej

patching file drivers/video/vesafb-thread.c

patching file include/video/vesa.h

mokka linux-2.6.7-gentoo-r9 #
```

The gentoo-dev-sources 2.6.7-r8 accepted the patch without problems.

Cheers

----------

## dec

```
tom@elmo tom $ dmesg | grep vesa

Kernel command line: root=/dev/hda3 video=vesafb:ywrap,vram:800x600-16@70

vesafb: Leadtek Research Inc., NV15 (GeForce4) Board, Chip Rev A0 (OEM: WinFast VGA BIOS.)

vesafb: VBE version: 3.0

vesafb: protected mode interface info at c000:bca0

vesafb: pmi: set display start = c00cbce5, set palette = c00cbd6a

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

vesafb: hardware doesn't support DCC transfers

vesafb: monitor limits: vf = 0 Hz, hf = 0 kHz, clk = 0 MHz

vesafb: total memory: 838860800

vesafb: scrolling: ywrap using protected mode interface, yres_virtual=1048576

vesafb: cannot reserve video memory at 0xd8000000

vesafb: abort, cannot ioremap video memory 0x32000000 @ 0xd8000000

vesafb: probe of vesafb0 failed with error -5

```

Any ideas?  :Smile:  this is on 2.6.7-cko6 (based on -ck5)

Thanks guys  :Smile: 

----------

## MaxDamage

I'm a bit lost. What I should do is

- Apply the patch to the source tree.

- Compile the kernel.

- Add the needed option to the grub.conf file.

I'm missing something? What about the /usr/src/linux/scripts/vesa_modeline_gen.pl script? Isn't needed anymore? The modes I use in the video option inside grub.conf has something to do with the names of the modes of /etc/fb.modes?

**EDIT**

Ok, I tested some resolutions and I got:

- 1152x864 and 1600x1200 don't work. Probably because they aren't standart vesa modes.

- All the other res work but at 60Hz. Cannot set the frequency neither in the kernel line, the "default" option into menuconfig nor the fbset command. Always default to 60Hz. Any idea?

**EDIT2**

fbset gives a funny output:

```
mode "1024x768-85"

    # D: 94.500 MHz, H: 68.677 kHz, V: 84.997 Hz

    geometry 1024 768 1024 768 8

    timings 10582 208 48 36 1 96 3

    hsync high

    vsync high

    rgba 6/0,6/0,6/0,0/0

endmode

```

1) 1024x768@85 (as suggested in the menuconfig default setting) will become 1024x768-85. I should then write 1024x768-16@85?

2) rgba 6/0,6/0,6/0,0/0 reminds me another post in this thread. Sorry spock_, I'm in the same case than Dojo, but he didn't come back to tell how the problem was solved (if solved).

----------

## phlashback

dec

Kernel command line: 

root=/dev/hda3 video=vesafb:ywrap,vram:800x600-16@70

should be:

root=/dev/hda3 video=vesafb:ywrap,vram:16,800x600-16@70

HTH

----------

## gjn

i have problmes applying the patch. here is what i get (on the gentoo-dev-sources-r :Cool: :

root@miles linux # bzip2 -dc /home/gjn/patch.bz2 | patch -p1

patching file arch/i386/boot/video.S

patching file Documentation/fb/vesafb.txt

patching file drivers/video/fbmem.c

patching file drivers/video/Kconfig

patching file drivers/video/Makefile

Hunk #1 succeeded at 44 (offset 1 line).

patching file drivers/video/vesafb.c

Hunk #6 FAILED at 246.

Hunk #7 succeeded at 474 (offset 3 lines).

Hunk #8 succeeded at 501 (offset 3 lines).

Hunk #9 succeeded at 522 (offset 3 lines).

Hunk #10 succeeded at 824 (offset 3 lines).

Hunk #11 succeeded at 863 (offset 3 lines).

Hunk #12 succeeded at 893 (offset 3 lines).

Hunk #13 succeeded at 1159 (offset 3 lines).

1 out of 13 hunks FAILED -- saving rejects to file drivers/video/vesafb.c.rej

patching file drivers/video/vesafb-thread.c

patching file include/video/vesa.h

i can't compile the kernel anymore. i will try to fix this myself.

edit: stupid things posted.

----------

## gjn

Update:

I was able to repatch the kernel. quite bizzare though. I copied the original files from the -r9 to the -r8 sources and then applied the patch again.

this time, it worked. hmm. I recompiled the kernel, and guess what:

I boot now at 1280x1024 with 85 kHz. That's what i wanted. Thanks spock_ for the patch.

Any idea when this patch will be included into the g-d-sources?

----------

## Neo_0815

Kernel Version ist g-d-2.6.7-r10, latest patch installed properly for tng.

But now i am getting:

Kernel command line: root=/dev/hde2 video=vesafb:1024x768-16@85,mttr splash=silent elevator=cfq gentoo=nodevfs

vesafb: NVidia Corporation, NV15 Reference Board, Chip Rev A0 (OEM: NVidia)

vesafb: VBE version: 3.0

vesafb: protected mode interface info at c000:0f03

vesafb: pmi: set display start = c00c0f3c, set palette = c00c0fb2

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

vesafb: hardware supports DCC2 transfers

vesafb: EDID vendor sign: STN

vesafb: monitor limits: vf = 160 Hz, hf = 70 kHz, clk = 110 MHz

vesafb: total memory: 67108864

vesafb: probe of vesafb0 failed with error -22

vram:16, ypan - all the same error.

Whats does -22 mean ? With rrc all is working right - but tng doesnt work for me at the moment.

Any help appreciated.

best regards

----------

## dec

 *phlashback wrote:*   

> dec
> 
> Kernel command line: 
> 
> root=/dev/hda3 video=vesafb:ywrap,vram:800x600-16@70
> ...

 

Thanks buddy, greatly appreciated.  :Smile: 

----------

## garo

Which patch should i use for a 32-bits system with a 2.6.5 kernel ?

EDIT: I found it.

It seams that the vesafb-rrc-0.1.6-2.6.x patch also works on 32-bits systems

----------

## Neocorp

I must admit im quite new to gentoo, so please excuse me if I asked something that has been answered already in a different way.

Im trying to patch gentoo-2.6.7-r11 sources, and it gives mit this error:

bash-2.05b# bzip2 -dc /home/neocorp/Downloads/vesafb-tng-0.9-rc2-2.6.7-gentoo.patch.bz2 | patch -p1

can't find file to patch at input line 4

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|diff -Naur linux-2.6.7-orig/arch/i386/boot/video.S linux-2.6.7-vesafb/arch/i386/boot/video.S

|--- linux-2.6.7-orig/arch/i386/boot/video.S    2004-06-22 21:56:34.000000000 +0200

|+++ linux-2.6.7-vesafb/arch/i386/boot/video.S  2004-06-27 16:04:59.000000000 +0200

--------------------------

File to patch:

The weird thing is, patching worked with the r9-sources i was using before, but compiling didnt. Im using the vesafb-tng-0.9-rc2-2.6.7.patch.bz2 patch. (Is this wrong?)

----------

## Neocorp

wow, it works better now, though CHUNK 6 fails at 246:

]

```
bash-2.05b# bzip2 -dc /home/neocorp/Downloads/vesafb-tng-0.9-rc2-2.6.7-gentoo.patch.bz2 | patch -p1

patching file arch/i386/boot/video.S

patching file Documentation/fb/vesafb.txt

patching file drivers/video/fbmem.c

patching file drivers/video/Kconfig

patching file drivers/video/Makefile

patching file drivers/video/vesafb.c

Hunk #6 FAILED at 246.

Hunk #7 succeeded at 468 (offset -3 lines).

Hunk #8 succeeded at 495 (offset -3 lines).

Hunk #9 succeeded at 516 (offset -3 lines).

Hunk #10 succeeded at 818 (offset -3 lines).

Hunk #11 succeeded at 857 (offset -3 lines).

Hunk #12 succeeded at 887 (offset -3 lines).

Hunk #13 succeeded at 1153 (offset -3 lines).

1 out of 13 hunks FAILED -- saving rejects to file drivers/video/vesafb.c.rej

patching file drivers/video/vesafb-thread.c

patching file include/video/vesa.h

```

----------

## snowracer

I have the same problem with gentoo-dev-source-2.6.7-r11, however the patch works fine with -r8. After editing the vesafb.c file it can even be compiled and work fine for me.

----------

## Sh4doW

hey ...

first of all ... thank you SOOOO VERY VERY MUCH!

a) (as deNniZ already mentioned) flickering screen is gone when returning from X!

b) 1024x768 @ 100Hz? YESSSSSS!

but ... there's a problem ... let's move on ...

i'm running gentoo-dev-sources-2.6.7-r11 patched with vesafb-tng-0.9-rc2-2.6.7-gentoo.patch.bz2 (i had some problems with vesafb.c but, everything worked out ok - at least kernel compiled without problems).

after reboot i get this message from kernel:

```

...

you passed an undefined mode number

...

```

... and that's about it ... no bootsplash, no 1024x768 ... no nothing. i can change mode, or press space/enter to move on ...

now for my lilo.conf :

```

...

vga=791

...

append = "notmpfs quiet video=vesafb:1024x768-32@100 splash=silent"

...

```

i've also thied different video settings like 1024x768-16(@100), and the one that kindow works is bare video=vesafb:1024x768 where i get 1024x768 interlaced @ 87 Hz ... but that's all. (i still get "undefined mode number" message at boot)

now for fb.modes :

```

...

mode "1024x768"

   # D: 113.31 MHz, H: 81.40 kHz, V: 100.00 Hz

   geometry 1024 768 1024 768 32

   timings 8825 184 72 42 1 112 3

endmode

...

```

i've also tried different combinations here  like 1024x768-32@100,1024x768-100,1024x768-32,... you name it ... nothing.

well ... anyway ... when my system is up&running  i can run

```

fbset 1024x768 (or some other mode like 800x600,...)

```

and my console is up to 1024x768 ... working like a charm @ 100Hz, but ... i can't get it to work at boot time.

any ideas? mostly i'm looking for some help around that append thing that you pass to kernel in lilo.conf ... can someone provide me with some other parameters that work for them on nvidia?

thanks in advance.

----------

## spock_

 *Sh4doW wrote:*   

> any ideas? mostly i'm looking for some help around that append thing that you pass to kernel in lilo.conf ... can someone provide me with some other parameters that work for them on nvidia?

 

First of all, get rid of the vga= option. vesafb-tng supports only the video= parameter, vga= is irrelevant and will only cause problems. If after removing  vga= and setting video to video=vesafb:1024x768-32@100 you still won't get 100 Hz during boot-time, please post/send me the output of `dmesg | grep vesa`.

----------

## Sh4doW

removed vga line from lilo.conf and got rid of "you passed an undefined mode number" message.

it's not that i don't get 100hz at boot-time i don't even get 1024x768 ...

anyway here's my dmesg for vesa :

```

Kernel command line: auto BOOT_IMAGE=Gentoo ro root=307 notmpfs quiet video=vesafb:1024x768-32@100 splash=silent

vesafb: Leadtek Research Inc., NV25 Board, Chip Rev    (OEM: WinFast VGA BIOS.)

vesafb: VBE version: 3.0

vesafb: protected mode interface info at c000:edb0

vesafb: pmi: set display start = c00cedf5, set palette = c00cee7a

vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03 

vesafb: hardware doesn't support DCC transfers

vesafb: monitor limits: vf = 0 Hz, hf = 0 kHz, clk = 0 MHz

vesafb: total memory: 67108864

vesafb: scrolling: redraw

vesafb: framebuffer at 0xd0000000, mapped to 0xd8807000, size 65536k

```

and here's some more info on bootsplash ...

```

bootsplash 3.1.4-2004/02/19-spock-0.1: looking for picture.... silentjpeg size 192688 bytes, found (1024x768, 192748 bytes, v3).

bootsplash: error while decompressing silent picture: height mismatch (3)

bootsplash: error while decompressing picture: height mismatch (3) .

bootsplash: error while decompressing picture: height mismatch (3) .

Console: switching to colour frame buffer device 61x21

```

i hope this helps ... somehow.

btw, thanks for quick reply.

----------

## spock_

 *Sh4doW wrote:*   

> 
> 
> ```
> 
> vesafb: scrolling: redraw
> ...

 

And after that, there's no mode-switch to 1024x768? Do you have any other framebuffer drivers compiled into the kernel? Have you tried 1024x768 with other refresh rates (or with no refresh rate at all)?

----------

## Sh4doW

i recompiled the kernel (made sure that only vesafb was selected) ... added the default value 1024x768@100 ... same thing.

i've tried 85Hz and it works fine, but as soon as i try to pass the color depth parameter (like 1024x768-16@85 or -32) i'm back at 640x480 ... meaning, bootup logo won't show up since it's 16bit picture ...

if i use only video=vesafb:1024x768 or even without video parameter i'm stuck with 1024x768@87 interlaced untill i change it with fbset.

i've also tried 800x600@140 ... doesn't work ... could it be that kernel parameter only takes 2 digits for refresh rate (i'd think so after reading the documentation ... <rr>?

what about that

```
vesafb: monitor limits: vf = 0 Hz, hf = 0 kHz, clk = 0 MHz
```

thing i get ... i've seen people get some different numbers here, do you think this is related?

----------

## crahen

Is it possible to still use this patch to get modes like 1400x1050 on LCDs when your laptops video card only supports VBE 2.0?

----------

## crahen

 *crahen wrote:*   

> Is it possible to still use this patch to get modes like 1400x1050 on LCDs when your laptops video card only supports VBE 2.0?

 

VBE 3.0 only I guess... darn

----------

## snekiepete

Im getting 1400x1050 with it

----------

## catkfr

I'm quite new with linux but really wanted to get this patch to work with gentoo-dev-sources-2.6.7-r11.  I saw that other people managed to do this but I thought that for other newbies like me this could help.

In order to apply the vesafb patch, you should first apply the following patch (yes, I know it is ridiculously simple!)

http://www.mit.edu/~mserrano/prevesafb-tng-gentoo-2.6.7-r11.patch

so dowload this patch and the vesa-tng-0.9-rc2-2.6.7-gentoo.patch

cd /usr/src/linux

patch -p1 < <path-to-prevesafb-patch>/prevesafb-tng-gentoo-2.6.7-r11.patch

then apply the vesafb patch and it should work.

Hope this helps

----------

## catkfr

I can't get 1400x1050 to work properly on my laptop (Dell Inspiron 8200) with a Geforce 440 Go.  The other resolutions work fine but when I try this resolution, the screen doesn't work properly, as if the bottom left of the screen was at the wrong place (slightly higher and to the right of the corner of the screen). In the end, the text wraps and the lines finish on the left side of the screen and a few charcters are missiong and the screen is a bit corrupted (the column between the end of the lines and the beginning of the lines) and if I launch bootsplash, then the colors go wrong as well. I tried all the options in the documentation without any success. The mode that doesn't work 1400x1050-16 appears in the modes in /proc/fb0/.

For now, I'm running perfectly in 1280x1024-16. Any ideas?

----------

## snekiepete

Not sure if I can shed any light or not, my line in grub:

video=vesafb:ywrap,mtrr,1400x1050-32@85.

one thing that I noticed affected the fb was compiled in fonts, if I had none or one other than the 8x16 I would get some funkiness? possibly you could check that....

----------

## catkfr

Thanks for the info snekiepete but unfortunately, that didn't do it for me: no change at all (good or bad)

----------

## MadEgg

catkfr, thx for the hint but it doesn't work for me...

```

bash-2.05b# patch -p1 < /root/prevesafb-tng-gentoo-2.6.7-r11.patch

patching file drivers/video/vesafb.c

bash-2.05b# patch -p1 < /root/vesafb-tng-0.9-rc3-r3-2.6.8-rc1.patch

patching file arch/i386/boot/video.S

patching file Documentation/fb/vesafb.txt

patching file drivers/video/fbmem.c

Hunk #3 succeeded at 1439 (offset -42 lines).

patching file drivers/video/Kconfig

patching file drivers/video/Makefile

Hunk #1 succeeded at 44 (offset 1 line).

patching file drivers/video/vesafb.c

Hunk #2 FAILED at 59.

Hunk #6 FAILED at 231.

Hunk #7 succeeded at 463 (offset 3 lines).

Hunk #8 succeeded at 490 (offset 3 lines).

Hunk #9 succeeded at 511 (offset 3 lines).

Hunk #10 succeeded at 800 (offset 3 lines).

Hunk #11 succeeded at 834 (offset 3 lines).

Hunk #12 FAILED at 864.

Hunk #13 succeeded at 1143 (offset 2 lines).

3 out of 13 hunks FAILED -- saving rejects to file drivers/video/vesafb.c.rej

The next patch would create the file drivers/video/vesafb-thread.c,

which already exists!  Assume -R? [n] n

Apply anyway? [n] y

patching file drivers/video/vesafb-thread.c

Patch attempted to create file drivers/video/vesafb-thread.c, which already exists.

Hunk #1 FAILED at 1.

1 out of 1 hunk FAILED -- saving rejects to file drivers/video/vesafb-thread.c.rej

The next patch would create the file include/video/vesa.h,

which already exists!  Assume -R? [n] y

patching file include/video/vesa.h

```

I still get a lot of failed 'hunks'... This is on gentoo-dev-sources-2.6.7-r11 so what am I doing wrong?

----------

## catkfr

the patch you are using is not for this kernel version. Use vesafb-tng-0.9-rc2-2.6.7-gentoo

----------

## MadEgg

Ow dohh... I'm so stupid   :Embarassed: 

Anyway, the older patch works a lot better, but it complains about a vesafb-thread.c and a vesa.h file that would be created by the patch, but they already exist. Hmm, I'll see what happens if I just remove those 2 files before I apply the patch.

----------

## MadEgg

Hmmzz.. apparently those existing files were the remnants of some other patch or something.

I re-emerged gentoo-dev-sources and now both the patches applied fine.

I removed the vga=0x518 from my bootline and added ,1024x768-32@85 to the video option.

I do get a 1024x768 console with the appropriate bootsplash and stuff. The refresh rate is still 60Hz though  :Sad: 

I checked dmesg and vesafb is telling me that my card(GF6800 Ultra) is VBE 3.0 compatible(as it should be imo  :Wink: ) so that should not be a problem.

My two monitors can handle 85Hz at that resolution as well so I don't see what's the problem...

----------

## MadEgg

Anyone?

----------

## ketjow

Check, if your monitor doesn't  send bad information about his max. refresh-rates. After typing dmesg, find something that looks like this: 

```
vesafb: monitor limits: vf =  60 Hz, hf = 65 kHz, clk = 110 MHz

```

If this is the case, just add something like:

```
maxvf:85,maxhf:100,maxclk:170
```

to your video option.

By the way - Great patch! Works fine, although much slower than the "classic" vesafb (delay when switching consoles). Is this normal?

----------

## MadEgg

Hmmz. My monitor doesn't send any edid-information at all(tad strange for a 2 year old monitor but anyway).

I checked dmesg anyway, it said this:

```

vesafb: monitor limits: vf =  0 Hz, hf = 0 kHz, clk = 0 MHz

```

I added 'maxvf=160,maxhf=96,maxclk=200' to my video parameter.

The result was this:

```

vesafb: monitor limits: vf =  0 Hz, hf = 160 kHz, clk = 200 MHz

```

I then went diggin through the sourcecode. I found a bug in there which assigns the value of maxvf to the variable maxhf on line 534(or 533, maybe I added a new empty line in before). I fixed that and rebooted.

Result:

```

vesafb: monitor limits: vf =  160 Hz, hf = 96 kHz, clk = 0 MHz 

```

Still no nice refresh rate. Pixelclock has become 0 somehow.

Went digging through the sourcecode again. I found out the reason it became 0 could be found on line 767(766?), probably because mon_limits is not set.

I hacked the default value from 0 into the max pixelclock from my monitor, 200 MHz, so I entered 200000000 at line 767(766?) instead of 0.

Result after reboot:

```

vesafb: monitor limits: vf =  160 Hz, hf = 96 kHz, clk = 200 MHz 

```

Seems allright. But still no nice refresh rate, still at 60Hz.

The entire vesafb part of dmesg as of now:

```

bash-2.05b$ dmesg | grep vesafb

Kernel command line: root=/dev/hda5 video=vesafb:ywrap,mtrr,noedid,maxvf:160,maxhf:96,maxclk:200,vram:16,1024x768-16@85 splash=silent

vesafb: NVIDIA Corporation, nv40 Board - p201-12 , Chip Rev    (OEM: NVIDIA)

vesafb: VBE version: 3.0

vesafb: protected mode interface info at c000:cd50

vesafb: pmi: set display start = c00ccd86, set palette = c00ccdf0

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

vesafb: monitor limits: vf = 160 Hz, hf = 96 kHz, clk = 200 MHz

vesafb: total memory: 16777216

vesafb: scrolling: ywrap using protected mode interface, yres_virtual=8192

vesafb: framebuffer at 0xc0000000, mapped to 0xf8809000, size 16384k

bash-2.05b$

```

Maybe I should bug-report this to spock instead of posting here? Anyway, suggestions are welcome!

----------

## ketjow

strange.. Worked fine for me, except that the monitor gave bad max*-values. I looked for the errors, you've found, but couldn't localize them. When did you download the patch? Kernel 2.6.8??

----------

## MadEgg

No, the file I've got is: vesafb-tng-0.9-rc2-2.6.7-gentoo.patch

For my 2.6.7-gentoo-r11 kernel.

I'd like to switch to another kernel, I've used love-sources till about 2.6.5 but then they started breaking everything in every other release so I decided to switch to gentoo-sources. Don't like this one either because qingy doesn't seem to want to work with it, it deadlocks my whole machine when I start it.

----------

## ketjow

Try normal 2.6.8-sources from kernel.org and vesafb-tng-0.9-rc3-r3-2.6.8-rc1.patch.bz2 before reporting a bug. Perhaps it's already fixed.

----------

## MadEgg

I just tried that. The maxvf->maxhf bug was fixed, but the maxclk still gets set to 0.

When I hardcode it to 200000000 and even when I set the minvf to 85, I still get a console at 60 Hz...

I'll try this with a monitor that does supply EDID info later tonight, see if I can actually get it to work at all...

----------

## MadEgg

Nope. The monitor does supply EDID, it gets detected correctly by the vesafb driver but the refresh rate is still 60 Hz.

Can't figure out why  :Sad: 

----------

## raid517

Erm... how exactly do I use this patch? Kill me for being a total n00b if you will, but I have never patched anything in my life. Could someone tell me, or maybe the author could add it to his guide?

GJ

----------

## MadEgg

Err... both on the start post of this thread and on his webpage it is quite clearly described how to apply the patch as far as I can see...

----------

## MaxDamage

I'm using gentoo-dev-sources-2.6.8-r3, wich have vesafb-tng patch applied by default. I own an ATI Radeon 9600 Pro and use the binary drivers.

Well the problem is the same that MadEgg explained. Works well... at 60Hz! No way of getting more. My question is: Doesn't the video modes we are trying to use be defined in /etc/fb.conf? I have no video mode "1024x768-16@85" in that file (is untouched, as gentoo install writed it). Or people got it to work without having the specific video mode defined in fb.conf?

The Radeon 9600 should be VBE 3.0 complaint, so I dont know why fails. I'm missing something?

----------

## MaxDamage

Ok, look what a curious thing:

```
vesafb: ATI Technologies Inc., V350, 01.00 (OEM: ATI RADEON 9600 PRO)

vesafb: VBE version: 2.0

vesafb: protected mode interface info at c000:5757

vesafb: pmi: set display start = c00c57eb, set palette = c00c5837

vesafb: pmi: ports = c010 c016 c054 c038 c03c c05c c000 c004 c0b0 c0b2 c0b4

vesafb: monitor limits: vf = 0 Hz, hf = 0 kHz, clk = 0 MHz

vesafb: scrolling: redraw

vesafb: framebuffer at 0xc0000000, mapped to 0xe0808000, size 16384k
```

So, it recognices my Radeon 9600 as only VBE 2.0 complaint  :Evil or Very Mad:  Google says it's 3.0. What can I do?

----------

## sarge

 *MaxDamage wrote:*   

> Ok, look what a curious thing:
> 
> ```
> vesafb: ATI Technologies Inc., V350, 01.00 (OEM: ATI RADEON 9600 PRO)
> 
> ...

 

Reflash modified bios. Try google for atiflash and radedit tools.

----------

## MaxDamage

 *sarge wrote:*   

> Reflash modified bios. Try google for atiflash and radedit tools.

 

Could you be more specific? Don't know what I've to change in the BIOS.

----------

## sarge

Sure.. 

1. save original bios with atiflash 0 -s bios.bin

2. run radedit , load bios.bin , change default refresh rates and save it (newbios.bin)

3. upload modified bios to VGA : atiflash 0 -p newbios.bin

4. power off and on

I said try google coz i did it 1,5 year ago on my R9700 and since then there r new versions of this tools for sure.

----------

## chapazzo

Sup. I bought a nvidia GF4MX440 (before I had a GF2MX400, no refresh probs), and now the framebuffer is locked at 60hz. No kernel parameter, no fbset, no setting can change it. This card is VBE 3.0, and the monitor reports the modes correctly, but I can't change the refresh :/

Does anything similar happened with any other card? Hope someone can help me in this.

System info: Linux 2.6.7 (vanilla, from kernel.org), vesafb-tng-0.9-rc2-2.6.7. dmesg reports as if nothing wrong happened (no errors).

----------

## grzewho

 *ketjow wrote:*   

> Works fine, although much slower than the "classic" vesafb (delay when switching consoles). Is this normal?

 

yeah, I`d like to know that too !

----------

## Flux-

I tried to get my vesafb working at 800x600@120Hz, but I just get 60Hz always. Then I noticed that my graphic card not might be a VBE 3.0 compatible (I'm using Ati 3D Rage Pro AGP 1X/2X).

From dmesg I get:

```

vesafb: ATI Technologies Inc., MACH64GT, 01.00 (OEM: ATI MACH64)

vesafb: VBE version: 2.0

vesafb: protected mode interface info at c000:4785

vesafb: pmi: set display start = c00c4829, set palette = c00c48a1

vesafb: pmi: ports = 7885 781f 78b4 78b8 7818 7814 78c0 78c3 78c1

vesafb: monitor limits: vf = 0 Hz, hf = 0 kHz, clk = 0 MHz

vesafb: scrolling: ywrap using protected mode interface, yres_virtual=10485

vesafb: framebuffer at 0xfd000000, mapped to 0xc8800000, size 8192k

fb0: VESA VGA frame buffer device

```

And from fbset:

```

mode "800x600-56"

    # D: 36.001 MHz, H: 35.157 kHz, V: 56.252 Hz

    geometry 800 600 800 10485 8

    timings 27777 128 24 22 1 72 2

    hsync high

    vsync high

    rgba 6/0,6/0,6/0,0/0

endmode

```

So seems like my graphic card isn't a VBE 3.0 compatible. Is it impossible for me to get over 60Hz with vesafb? I have used 85Hz in X with the same graphic card (not using X atm).

----------

## adrenalin

 *Flux- wrote:*   

> 
> 
> So seems like my graphic card isn't a VBE 3.0 compatible. Is it impossible for me to get over 60Hz with vesafb?

 

Yes that is what the vesafb patch docs say. Are you sure that you are using a rage pro and not a mach as your dmesg suggests? Why dont you use a native driver? aty128fb works for my rage 128 pro card.

----------

## memborg

Mjallo

How do I get a bootsplash on my frambuffer console these are my options

```

grub.conf

default 0

timeout 5

splashimage=(hd0,0)/grub/splash.xpm.gz

title=Gentoo

root (hd0,0)

kernel /kernel-2.6.8 root=/dev/hda3 video=vesafb:ywrap,mttr,1600x1200-32@60 splash=verbose

initrd=/boot/initrd

kernel

<*> RAM disk support

   (4096) Default RAM disk size (kbytes)

   [*]   Initial RAM disk (initrd) support

   [*] Support for Large Block Devices

...

 <*>   VESA VGA graphics support

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

   (1600x1200-32@60) VESA default mode

...

 <*> Virtual Frame Buffer support (ONLY FOR TESTING!)

   Console display driver support  --->

   Logo configuration  --->

   [*] Support for the framebuffer splash

fbset

mode "1600x1200-60"

    # D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz

    geometry 1600 1200 1600 2621 32

    timings 6172 304 64 46 1 192 3

    hsync high

    vsync high

    rgba 8/16,8/8,8/0,0/0

endmode

```

I have tried to use the gentoo-highqaulity bootsplash but it doesn't show any splash...

```

/sbin/splash -s -f /etc/bootsplash/gentoo-highquality/config/bootsplash-1600x1200.cfg >> /boot/initrd

```

doesn't seem like anuone want to help...

----------

## Halanegri

memborg: You're asking about this in the wrong thread. This is about vesafb, not bootsplash/fbsplash.   :Confused: 

----------

## Halanegri

Hey, I have a Dell Inspiron 8600c with an ATi Radeon 9600 128mb Pro. How can I use my native 1680x1050 resolution with vesafb/vesafb-tng/radeonfb ?

I've tried calculating the timings and putting an entry in /usr/src/linux/drivers/video/modedb.c, and then passing "video:vesafb,1680x1050-32@60" as an option but it always gives me a blank screen. 1680x1050 doesn't show up in /proc/fb0/modes.

EDIT: Never mind, it seems to work automatically out of the box with radeonfb, no patching needed, I didn't even have to specify a video mode in my bootloader.

----------

## AvantLegion

 *Halanegri wrote:*   

> Hey, I have a Dell Inspiron 8600c with an ATi Radeon 9600 128mb Pro. How can I use my native 1680x1050 resolution with vesafb/vesafb-tng/radeonfb ?
> 
> I've tried calculating the timings and putting an entry in /usr/src/linux/drivers/video/modedb.c, and then passing "video:vesafb,1680x1050-32@60" as an option but it always gives me a blank screen. 1680x1050 doesn't show up in /proc/fb0/modes.
> 
> EDIT: Never mind, it seems to work automatically out of the box with radeonfb, no patching needed, I didn't even have to specify a video mode in my bootloader.

 

Do your KDE, GNOME, etc, still work?

I have an Inspiron 6000 with a Radeon x300 Mobility, and a 1680x1050 native LCD.

radeonfb works for me, but conflicts with the fglrx driver anytime I try to do anything substantial in X (like a DE like KDE or GNOME)

----------

## ikaro

if you had waited just a little bit more....  :Laughing: 

----------

