[UPDATE] Getting higher refresh rates using vesafb driver

grzewho · l33t Joined: 31 Dec 2002 Posts: 626 Location: /home/g

will the patch get into official gentoo-sources ?
_________________

spock_ · Posted: Wed Aug 06, 2003 7:09 pm Post subject:

Thx for the tip b3rT. Someone having lilo as his bootloader might find it useful

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

I'll probably post it to bugzilla sooner or later. It will be posted sooner if I get more data about the modelines

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 · Guru Joined: 12 Mar 2003 Posts: 595 Location: Florida

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.

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.

If I run xvidtune I get

spock_ · Posted: Wed Aug 06, 2003 9:03 pm Post subject:

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

lurid · Guru Joined: 12 Mar 2003 Posts: 595 Location: Florida

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.
_________________
Go find a cheerleader and saw her legs off. - Nny

spock_ · Posted: Wed Aug 06, 2003 11:01 pm Post subject:

Have a look at README included with the patch, it's all described there

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 · l33t Joined: 31 Dec 2002 Posts: 626 Location: /home/g

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

thanks a lot for your great work!!!

dobra robota

_________________

spock_ · Posted: Fri Aug 15, 2003 7:21 pm Post subject:

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).
_________________
"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."

thadk · Tux's lil' helper Joined: 21 Jun 2002 Posts: 123

spock_ · Posted: Sat Aug 16, 2003 9:35 am Post subject:

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?

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

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

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.
_________________
"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."

thadk · Tux's lil' helper Joined: 21 Jun 2002 Posts: 123

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.

spock_ · Posted: Sat Aug 16, 2003 10:21 am Post subject:

Here is a corrected version:

thadk · Tux's lil' helper Joined: 21 Jun 2002 Posts: 123

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

.

aLEczapKA · Apprentice Joined: 13 Jun 2003 Posts: 192

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?
_________________
while true; do eject /dev/cdrom; eject -t /dev/cdrom; done

spock_ · Posted: Sun Aug 17, 2003 8:17 am Post subject:

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.
_________________
"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."

aLEczapKA · Apprentice Joined: 13 Jun 2003 Posts: 192

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!!!
_________________
while true; do eject /dev/cdrom; eject -t /dev/cdrom; done

aLEczapKA · Apprentice Joined: 13 Jun 2003 Posts: 192

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..
_________________
while true; do eject /dev/cdrom; eject -t /dev/cdrom; done

FileZilla · n00b Joined: 18 Aug 2003 Posts: 13

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 · n00b Joined: 13 Jul 2003 Posts: 59 Location: Socal

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

Malice · Tux's lil' helper Joined: 13 Jun 2003 Posts: 78

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 · Posted: Sat Aug 23, 2003 4:48 am Post subject:

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

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)

Angrybob · Guru Joined: 19 Apr 2003 Posts: 575

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

LinuxDolt · Tux's lil' helper Joined: 05 May 2003 Posts: 104

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 · Tux's lil' helper Joined: 08 Oct 2002 Posts: 143

it does not work for me

/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?
_________________
Jeden Tag erhöht sich zwangsläufig die Anzahl derer, die mich
am Arsch lecken können... Das ist heute DEIN Tag!

Angrybob · Guru Joined: 19 Apr 2003 Posts: 575

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