Problem installing the "nouveau" driver

Mike McCarty Mike.McCarty at sbcglobal.net
Tue Jun 29 09:52:44 PDT 2010


alupu at verizon.net wrote:
> On Jun 29, 07:40:18 AM, Simon wrote:
> 
> I'm confused.  So before we go to the _exact_ steps of

Yes. You are conflating almost unrelated things.
I'm not a specialist on that particular video processor,
so take what I write here with a little grain of salt
here and there. However, I've written video drivers for
MSDOS which handled many of the same kinds of modes
for (no longer produced) video boards.

> how to set a font in kernel which would take effect after
> "nouveau" is up, I want to establish a common ground.
> 
> With "nouveau", my boot-up goes through these basic steps:
> 
> 1. The original/"regular" console sequence (80x25)

Yes, if that's what you have selected. Some BIOS used to
allow boot in different modes. I haven't seen that in modern
ones, however.

> 2. Nouveau is loaded by UDEV

This I don't know about, but it makes sense.

> 3. At this point, the console goes blank for a sec or so.
>  The preceding messages are wiped out.

Not quite. The video processor has been commanded to switch
to a graphics mode, and is now using different RAM. Usually,
the previous messages are still held in the character mode RAM.
If you issue a command to the video processor to switch back
to character mode, then the original text will probably reappear.

> 4. The remainder of the boot-up sequence proceeds and stays
> in 240x67 all the way to the prompt (and beyond).
> 
> 5. I can never change the 240x67 resolution of the console
> text mode.

That's a very strong statement. If your driver permits it,
then there's nothing I can think of about the hardware
which wouldn't do exactly what you seem to want. Temper my
statement, because I'm not expert in that exact hardware.

As a test, try booting up KNOPPIX, and then shutting down.
I trow you'll see the original "text boot stuff" reappear
on your screen after X shuts down.

> QUESTION
> Does anybody have/see a different behavior?
> 
> NOTE
> I can imagine people going directly to X (graphics mode).

X and graphics mode have nothing to do with each other,
except that X expects the video driver to be able to
execute graphics commands. IOW, one can have graphics
mode without X, but not the other way 'round. The BIOS
is capable of displaying text on the screen, even when
the display is in (certain) graphics modes.

One could presumably boot to MSDOS, select a graphics mode,
and then use loadlin to boot Linux with an initial graphics
mode. X requires a boatload of other stuff to be loaded
and running before it can "go". That's why you don't see
X used during boot. It sits on top of the kernel, so the
kernel can't use it during bootstrap. X also wants a video
driver installed. So, X can't be loaded until boot is
actually over, and init is running, I think. Someone may
want to correct me on that; I'm not an expert in Linux
boot sequence. Howver, believe I've not seen X started until after
init was running, and boot is, technically, over, and all
we're doing is loading applications. Some may want to
niggle about precisely when boot is over, but in my mind,
once the kernel is running, and we could now produce a
login prompt, then boot is over, and we're just loading
apps and initializing optional peripherals used by them.

This is somewhat happens when one uses a frame buffer mode
during boot. There is an initial graphics mode selected
for the display, which is then used pretty much just to
display text (though some use a little "splash" at the
start with a graphic in it, which then gets scrolled
off).

> In that case, to stay with me on step 4 above, just come
> "down" in console text mode for a moment or so
> (Ctrl-Alt-Backspace or whatever) and check the ensuing
> text resolution.

Again, you seem to be conflating X with graphics mode.
Graphics mode is a hardware setting. X is a software
package. The driver sits under X and on top of the
hardware. When X wants to issue a command to the hardware,
it does so by making calls to the driver, via an API.
The driver interprets the request, and issues actual
hardware commands to the video processor. The exact commands
to the hardware are hardware specific, which is why
you need different drivers for different video processors.

> BTW, I'm interesting in the answer to my question above
> more than in comments to this note :)

I don't understand that statement. I've tried to address
misconceptions on your part in this reply.

> BTW, the _exact_ steps of how to set a font in kernel which
> would take effect after "nouveau" is up, will be highly
> appreciated.
> 
> Thanks,
> -- Alex


-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!



More information about the lfs-support mailing list