Recently, Somebody Somewhere wrote these words
> On Thu, Jun 30, 2005 at 04:00:13PM +0100, Declan Moriarty wrote:
> >
> > modprobe radeon got me a module which found the right type of card
> > in the agp bus. That looked good.
>
> Good.
>
> > modprobe fbcon gave me: FATAL: Module fbcon not found.
>
> It's 'Framebuffer Console support' in 'make menuconfig'.
>
> > Which kind of tells me I didn't compile in a framebuffer at all.
> >
> > [EMAIL PROTECTED] /usr/src/linux-2.6.12.1]# grep FRAMEBUFFER .config #
> > CONFIG_FRAMEBUFFER_CONSOLE is not set
> >
> > but the radeon module loaded a module called fb. Same thing?
>
> I think not. fbcon is only for using the text consoles as a
> framebuffer thing. When X11 runs on the fbdev driver like this:
>
> Section "Device"
> Identifier "Framebuffer"
> Driver "fbdev"
> Option "fbdev" "/dev/fb0"
> EndSection
>
> Section "Screen"
> Identifier "Screen0"
> Device "Framebuffer"
>
Ok, no framebuffer. Here's the equivelant on this box from xorg.conf
Section "Device"
Identifier "Standard VGA"
VendorName "ATI"
BoardName "Radeon"
Section "Screen"
Identifier "Screen 1"
Device "Radeon 7000"
Monitor "HP Ultra VGA 1280"
> then 'startx' switches the display to using the 'nvidiafb' module, but
> when you switch back to text console with ctrl-alt-F1 it's gone blind
> until you modprobe fbcon. As I remember it, the vga card has some
> 'text modes' where it has its own fonts, and it has 'graphic modes'
> where it has only pixels, so the driver has to paint the text
> characters. And I think X11 on nvidiafb switches it to graphic mode,
> but doesn't switch it back, so from that point you need the fbcon
> driver or you won't have a text console anymore.
Very interesting. All I lose is the cursor. Framebuffer out next rebuild
- all of it.
>
> > What you are saying is than the "new" module-init tools are crap. I
> > agree. Also some dweeb changed the names of all these modules.
>
> I think we are in the middle of a process. The old way was: A program
> talks to a device file, the kernel wakes up and loads the
> corresponding module. The new way is: Something, a boot script, loads
> a module, udev sees it and creates the corresponding device file.
> Maybe some drivers are already living in the future, so they don't
> know the old way anymore, and some other drivers don't know of the
> future yet, and we are caught in the middle, as we alway are.
You are very kind to them. Between the old way and the new, even m$
would have gone bust if they had tried that. The trouble is, the new way
is going to be worse. They tried this with pcmcia support and succeeded
in proving that linux was a _lousy_ platform for responding to device
changes on the fly. Ditto with apm, which the laptop guys poured their
brains into for years, only to find it buggered beyond belief by the
variations and they dumped 6 years of hard work and started with acpi,
which, AFAICT, is going the same way. How many attempts at this do they
need. Automount - remember that? Devfs - rewmember that? The current
failure is udev. It runs so totally counter to the secure nature of
linux (No hacker can even climb up the suers into a linux box) to have a
hacker be able to plug a usb disk into the usb port and have everything
say "Hello!", welcome it, and mount it!
--
With best Regards,
Declan Moriarty.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
