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:

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!

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

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:

Code:

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

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

Code:

fbset <horiz_res>x<vert_res>

for example

Code:

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.

Code:

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

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

Code:

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

Patch your kernel tree.

Code:

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).

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! ]. 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.

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 ).

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:

Code:

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.

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.

I'm glad it works for someone, I was just starting to get afraid I did smth wrong 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 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

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.

My max vert is 160
My max horiz is 70
My bandwidth is 110_________________"Our enemies are innovative and resourceful, and so are we, they never stop thinking about new ways to harm our country and our people, and neither do we." George W. Bush

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 _________________Config - caught by a chronic disease called tuxmania....

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:

Code:

$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]_________________Config - caught by a chronic disease called tuxmania....

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]:

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

The first two lines are easy... then it gets tuff
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...._________________Config - caught by a chronic disease called tuxmania....

May be, this did the trick. Anyhow, this patch is great, and if you (I would be willing to help ) I hope it would get included in the mainstream kernel_________________Config - caught by a chronic disease called tuxmania....

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 ). It's something.. for the start 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 But in time - who knows.. ). 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.

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
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 )_________________Config - caught by a chronic disease called tuxmania....

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

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.