Hi
Is there any way to give the console a kick in the pants?
My framebuffer (and therefore system console, by definition) come up
rather late.
It seems the console doesnt care to check for drivers comming up after a
certain time, and thus I get no output despite the driver working.
I'd like to do something like console_rescan_my_damn_device() if
possible :-)
My only option right now appears to be to set up a dummy framebuffer
prior to real one starting up.
TIA.
--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux
Do not meddle in the affairs of Dragons, for you are tasty and good with
ketchup.
> My framebuffer (and therefore system console, by definition) come up
> rather late.
>
> It seems the console doesnt care to check for drivers comming up after a
> certain time, and thus I get no output despite the driver working.
>
> I'd like to do something like console_rescan_my_damn_device() if
> possible :-)
>
> My only option right now appears to be to set up a dummy framebuffer
> prior to real one starting up.
The reason for this is because the framebuffers most often depend on the
bus being set up. Usually this happening later in the boot process. What
are trying to do? Retrieve the earlier printk messages. Do you have
DUMMY_CONSOLE set to Y. I believe the data is transfered from dummycon to
fbcon after fbcon is initialized. If you having problems with that try
increasing the size of dummycon's "screen". See dummycon.c for more
details.
On 17 Jun 03 at 21:03, James Simmons wrote:
> > My framebuffer (and therefore system console, by definition) come up
> > rather late.
> >
> > It seems the console doesnt care to check for drivers comming up after a
> > certain time, and thus I get no output despite the driver working.
>
> The reason for this is because the framebuffers most often depend on the
> bus being set up. Usually this happening later in the boot process. What
> are trying to do? Retrieve the earlier printk messages. Do you have
> DUMMY_CONSOLE set to Y. I believe the data is transfered from dummycon to
> fbcon after fbcon is initialized. If you having problems with that try
> increasing the size of dummycon's "screen". See dummycon.c for more
> details.
Maybe he just enabled vga16 + XXXfb. First vga16 comes up, and start
painting characters. Few microseconds after that XXXfb (for example
matroxfb) comes up, registers itself as /dev/fb1 and reprograms hardware
to non-VGA mode.
>From that point on vga16fb paints characters to unmapped memory, and
there is only black on screen.
Petr Vandrovec
[email protected]
> Maybe he just enabled vga16 + XXXfb. First vga16 comes up, and start
> painting characters. Few microseconds after that XXXfb (for example
> matroxfb) comes up, registers itself as /dev/fb1 and reprograms hardware
> to non-VGA mode.
It would be nice to do it even soon :-) Its just not setup that way :-(