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

  Code:

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

  change it to read:

  Code:

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

1. Download the patch.
   
2. 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

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

   Code:

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

   
   
4. Patch your kernel tree.
   

   Code:

   cd /usr/src/linux bzip2 -dc vesafb-rrc-0.1.6-2.6.x.bz2 | patch -p1

   
   
5. 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 /usr/src/linux/scripts/vesa_modeline_gen.pl

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

   Code:

   make bzImage mount /boot mv /boot/bzImage /boot/bzImage.old cp /usr/src/linux/arch/i386/boot/bzImage /boot

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

   Code:

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

   Code:

   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.
   
   
9. Unmount /boot, reboot and enjoy your framebuffer console at a high refresh rate. Mine is running perfectly in 1024x756 @ 85Hz
   

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!

[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?
_________________
Think about your breathing.
http://floam.sh.nu

[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

[spock_]

To answer all your questions:

1. 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 ).
   
   
2. 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.
   
   
3. 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.
   

[Eediot]

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,

[spock_]

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.

[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
_________________
"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

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

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

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

[Config]

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

[spock_]

OK, here is a 'translation' for you:

[Config]

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

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

Anyway - thanks for your feedback and support

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

[lucida]

[Config]

But doesn't the radeon have its own framebuffer driver - a hardware accelerated one?
_________________
Config - caught by a chronic disease called tuxmania....

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

[Config]

You can do

[Eediot]

thanks, gentoo's too obvious for me

[lucida]

[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

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.