Re: 2.6.25 + vga=791
> >>>> In installing linux-image-2.6.25-1-686 I find I can no longer use
> >>>> vga=791 on the kernel commandline. I get "undefined videomode number:
> >>>> 317" that's 791 hex.
Here's something funny:
I just saw this error message tonight, building a new machine with an integrated ATI X1200 GPU. I'm too tired to troubleshoot it until tomorrow, though.
> Good job Dave for pointing out those klibc packages: I forgot :-(
> libklibc-dev. Now following Spocks website verbatim I get uvesafb at bootup.
Hmm. I've been compiling my 'klibc' DEBs from scratch instead of using the precompiled packages from the repositories. It is interesting to see that you didn't have to do that, and were still able to get 'v86d' to run UVESA FB! The "spock" site states that 'klibc' must be built against a compiled kernel tree which has CONFIG_UVESA_FB enabled, so that's what I've been doing.
Looks like I need to experiment with your (easier) way! ;)
> BTW I found out uvesafb was running when I had specified vga=791 and got
> a 80x25 FB at boot.
>
> Can you modigy uvesafb parms on the fly while running?
Well, I believe that answer is yes. My purpose was to get my virtual terminals to run at 60 Hz vertical refresh, instead of the 75 Hz that my monitor (accurately) reports at boot. My monitor is able to do 75 Hz, but the manufacturer says that using 75 Hz at 1280x1024 may shorten its lifespan. I found that the NVidia FB, once the kernel developers added support for the GeForce 7XXX family, defaulted to 60 Hz because the monitor reports 60 Hz as its preferred vert. refresh. But 1280x1024@60 is not a standard VESA mode, so the VESA FB simply can't set it; after the boot sequence, VESA FB also does not allow changes to the virtual terminals' video mode. I don't want to use 'nvidiafb' because the X 'nvidia' driver cannot coexist with it. (I really hope to see a free source X driver with 3D acceleration soon that CAN work with 'nvidiafb'; it looks like the ATI drivers are already reaching a similar goal.)
To answer your question: if I run 'fbset -i' in a virtual terminal (I'm talking about using Ctrl-F1, not something like an xterm) I can discover the vert. refresh rate being used by the framebuffer driver. If I supply the boot parameter "video=uvesafb" on my "kernel" line in 'menu.lst', I get 1280x1024 at 75 Hz. (So, the driver correctly detects the optimal resolution, but uses the highest possible refresh rate reported by the monitor instead of the alternate rate it reports as preferred.) OTOH, if I supply a parameter like "video=uvesafb:1280x1023@60", then the virtual terminals are set to 1280x1024 at 60 Hz. Perfect!
Either way, I am also able to use 'fbset <mode>' to change the mode to a different vertical refresh. That makes me think I should say "yes" to your question. However, I never tried changing the resolution; my monitor in an LCD, and resolutions other than 1280x1024 look degraded. I would check for you right now, but that machine is in pieces in the other room because of a CPU upgrade. I can try it tomorrow, though. I believe it will work: the userspace 'v86d' utility stays in memory after boot, which makes it possible for UVESA FB to talk to the video card BIOS at any time (not just at boot time, like VESA FB).
If you compile your own kernels, there is some useful documentation about how to set your video mode for UVESA FB provide with the kernel sources. Let's say we are in the directory than contains the unpacked kernel source tree. You can take a look at this file:
linux-source-<version>/Documentation/fb/uvesafb.txt
(The first kernel which had this driver was 2.6.24, BTW.) The document was written by "spock" himself, and it is the second best source of info I've found besides the "spock" website.
HTH, and glad to hear about your success,
Dave W.
Reply to: