> >>>> 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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]", 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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
