# How do you determine frame buffer numbers? SOLVED!

## Gooserider

In the installation guide, they tell you a whole bunch of stuff about frame buffers, with the idea of adding a string to the boot command that sets them up.

 *Quote:*   

> 
> 
> Optional: Framebuffer
> 
> If you have configured your kernel with framebuffer support (or you used genkernel default kernel configuration), you can activate it by adding a vga and/or a video statement to your bootloader configuration file. 
> ...

 

This is all well and good, but there is a BIG peice of the picture missing!  Namely the HARDWARE side of the discussion.

Along with telling you how to write the configuration line IF you know what values to use, the documentation should AT LEAST a pointer to instructions on how to determine the specs given the only the box and the installation stage you are at.  Even better, if it can be done in a reasonable length, would be to include the instructions in the document.

But they don't, so how DO you determine what values to use in the frame buffer statement on a given hardware setup  :Question:  

Especially things like color depth, ywrap, and mode?

I've tried looking at dmesg, lspci, and poking around on the Live CD (which gives you a frame buffer so obviously it must be able to figure out what values to use...)  I've done some searching (unsuccessfuly) on the forums, and also poked around in the wiki, which gave me a couple of possible leads, but they seem mixed. (vbetest from the lrmi package; fbset, etc)

I don't want to run splash screens or anything like that (I think they are a distraction and obnoxious...) just get a better console size and font.

Gooserider

----------

## acturneruk

There is this about vbetest in the wiki, not sure if it helps you or not.

Andrew

----------

## Gooserider

I saw that earlier Acturneruk, and it was one of those mixed results things that has had me off futzing for several hours.  It appears that vbetest can be mildly dangerous....  Aside from not having any documentation that I can find other than the one liner you get with the '--help' switch, it can send your video to la-la land   :Shocked:   :Crying or Very sad:   I tried it on this box (a Mendecino Celeron, see my sig) which is currently my main box for most stuff.  (I'm installing on an Athlon XP 2500 box w/ an Nvideous GeForce video card, once done that will eventually become my main box...)  When I did, my screen went blank in X and ALL consoles.  I could ssh in from elsewhere, and everything else was still running, but I had no video out.  (interestingly enough though, my monitor didn't indicate a loss of signal or go into low power mode)

Worse, I am (and probably will be for days) in the middle of doing an emerge -e world as part of upgrading to gcc 4.1.1.   Vbetest won't let you do anything but see a list of resolutions from a remote shell   :Razz:   I eventually was able to log into a console on this box by typing blind, (confirmed by repeated ps -ef's on the remote ssh session) and tried every listed resolution that vbetest offered, again by typing blind.  Nothing worked, so I finally rebooted.  Fortunately, emerge --resume seems to be working   :Very Happy: , so I didn't loose anything there.

I've also been doing some other poking around, and found some stuff that is sort of useful.

In another wiki article, I found mention of a program called fbset.  It gives a bit more info, but is limited.  OTOH, it does have a man page, although the description says it is out of date.  It looks powerful in terms of being able to play with stuff, but after the problem I had with vbetest, I think I'll hold off on that part of it .  However, it says that the livecd is giving me a framebuffer mode of 1024 x 768, @ 76hz refresh, with a color depth of 16 bits, or 64k colors.

Then I did some poking in /proc, which seems to have all sorts of interesting stuff in it.  The problem is that some of the files are apparently binary, and attempting to cat them borks the screen output into gobbledegook.  However you can recognize a command prompt, and blind entering "reset" gets you back to normal.

cat /proc/cpuinfo tells lots of stuff about the cpu, including a list of flags which on two of my three boxes includes mtrr!  There is also a /proc/mtrr file, catting it gets me a list of two registers.  One is listed as 512mb, write-back, and the other is 64mb, write-combining.

Presumably one of these is the number I need to put in for the mtrr value, but which one?

Cat /proc/cmdline apparently gets you the initial command line that was passed to the kernel at bootup.  It looks like the livecd  is passing the line "vga=791" which again translates to the 1024x768x16 bit value I got from fbset.  

So it looks like I've gotten it down to 1024x768 for resolution.

The 16 color depth works. I might be better off with a higher depth, but I'm not sure I need it.

Mtrr I have down to two possibilities, but it's not clear which one.  Presumably the higher number is better, but I'm guessing   :Confused: 

I haven't found anything yet that gives me a good hint about y-wrap, but judging from the kernel doc reference, it looks like it's a good thing and nearly everything supports it.

At this point, I might get further with more digging, but I'm not sure it's worth the effort.  It looks like I've narrowed the possibilities down to a reasonable number, so that actually testing different options is a workable solution.  Since as I understand it, I can have multiple entries in GRUB that will boot the same kernel but with different options, it seems the simplest thing is to make a grub.conf that will let me test lots of different choices w/o having to do much changing.   :Cool: 

I do think that this kind of question is still a problem though, and a better solution is needed in the docs to help investigate hardware so that more intelligent choices can be made about the various install options.

Gooserider

----------

## nixnut

Moved from Installing Gentoo to Kernel & Hardware.

Not about getting gentoo installed, so moved here.

----------

## Gooserider

Actually Nixnut, I figured it WAS about getting Gentoo installed,,,  You are of course free to move the thread whereever you see fit, but my reason for putting it where I did was because the question I was raising about how to figure out just what values to put in for the framebuffer setup was something that was keeping me from finishing an install properly.

Remember, the Handbook tells you to figure out the framebuffer strings FIRST so that you can put them in the bootloader....

However perhaps the hardware folks will have more ideas about how to answer this question.

In regards to the solution, I'm in the testing phase right now, where I THINK I have figured out what I need to do, but haven't yet put the bootloader file together to see if it actually works.  If it does, I will upgrade the title line.

Gooserider

----------

## cnagel

I am going through the exact same things, with the exception that I found the 791 by reading the .cfg file off the CD, and passing it to *my* kernel causes a prompt that it is an unsupported mode.  Huh.  Must be that I need to compile in a different driver??  <-- that's strange...(or is it?).  Hmmm...

Chris

[Edit]:  Nope, changing from <M> to <*> (built-in driver) did not change nuttin...

----------

## Gooserider

Well, I'm not sure just why, but I actually got a frame buffer type display when I finally booted, WITHOUT passing any frame buffer values as part of my boot string   :Confused:   :Rolling Eyes: 

However I was having major problems with getting grub to work properly (which is how I know it wasn't getting any fb values, as I was booting from a minimal grub floppy...) and wasn't really getting useful help over in the Grub Error Collection thread, so I have started doing a complete re-install from the ground up using 2006.1

This means the old kernel has been blown away so I can't tell you for sure just what I did to get that result.

 Sorry....

Gooserider

----------

## Gooserider

I'm still having bootup problems, but once again, I'm getting framebuffer type displays without giving any framebuffer commands in my bootup command.

What I did do was to enable the vesafb framebuffer device in the kernel, specifying a default display size of 1024x768x76hz and the appropriate hardware.  (I could have specified a higher default display, but on that monitor 1024x768 is as small as I can read w/o straining.)

Now when I give the boot command, I get about 1-2 screens worth of bootup info at vga default, then it flashes over to framebuffer size and continues that way, but without any flash screens or background displays like you get on tty1 with the install CD.

 Gooserider

----------

