linuxconsole-dev

dummy console

[James S. <jsi...@li...>]

Hi!

   I'm looking for some feedback to a problem I have been having. As you
know I have a true multidesktop going. One of the most annoying things I
coming across is the one vt intialization in the beginning. Why is this a
problem? Well I like to use my mda display as my printk console. It is
most helpful when experimenting with vgacon or fbcon. Now I have to go and
hack things up to get mdacon going right away. I can in theory have both
going right away which is what I like to do but still use one for the
console to use printk. Either way I get to see data right away. This is
pretty much I like to do it. So I like to see mda_console_init go away in
some fashion. Maybe get called in console_init(). We just have to be
careful about any kmallocs.
   Now some could argue use dummy_con and have mdacon take over. With
fbcon also we then need two dummy_cons to take over. Also we don't know
how many fbdev devices we could have. We could end up with many
dummy_cons. Well this brings me to the next issue. What calls
take_over_console to get to fbcon! Since it is possible to have vgacon
along side fbcon the question is do we take over vgacon or have fbcon
spawn a new VT to run along side vgacon? Then if we do have vgacon and
dummycon at the beginning which one does fbcon take over? As you can see
it is quite a mess.

   The solution I thought of to deal with this we not have dummy_con at
the very beginning. Instead have fbcon spawn its own VTs instead of
calling take_over_console. What we if don't have vgacon or mdacon at the
beginning. I thought about not have the console enabled (CON_ENABLE) so
nothing is printed yet by printk. If we do have mdacon and vgacon
then we can enable the console. People could argue that data will be
missed farther back in the log buffer. I thought about that and with Mortons
patch I could do that. In his patch with printk the log buffer and what
the console print are different things. This means data could be added to
the log_buffer while the consoles are still printing the previous line.
Now we could star printing right at the beginning of the log_buffer as
soon as the console becomes enabled and then get up to speed.

So what do you think? Anyone have any better ideas?

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] dummy console

[Geert U. <ge...@li...>]

On Tue, 10 Apr 2001, James Simmons wrote:
>    The solution I thought of to deal with this we not have dummy_con at
> the very beginning. Instead have fbcon spawn its own VTs instead of
> calling take_over_console. What we if don't have vgacon or mdacon at the
> beginning. I thought about not have the console enabled (CON_ENABLE) so
> nothing is printed yet by printk. If we do have mdacon and vgacon
> then we can enable the console. People could argue that data will be

Note that fbcon can work as some kind of dummycon as well, if you supply a
dummy display_switch.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds