linuxconsole-dev

Alots of updates.

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

Hi!!

 Thanks to Vojtech major parts of the kernel have been updated. The
console system now interfaces with the way keyboards are handled by the
input suite. For people that want to use other devices as the keyboard for
the console look at the input device drivers for keyboards now that its
standardized (for brallie guy). Now that we have the input suite
and have fbdev cleanup. The next two big issues to tackle. 

First issue:

  How to cleanup up the console code. Its a mess. Many data structs no
longer needed etc. Also as pointed out when the group first formed. Alot
of stuff for serial consoels needless overlap with the serial console.
This needs to be cleaned up. Also we need to work on splitting up
console.c. Its just big and a mess. 

Second issue:
   The next question is how to handle multihead? Here are some models.

---------------------------------------------------------------------------
First Model:

   The current kernel doesn't really handle this very well. The kernel has
32 virtaul consoles. Fbdev has a function con2fb that maps a framebuffer
to a VT or set of VTs. This is done because the current console system
can't handle multihead properly. Continuing to use this model we would map
devices around. Many problems with this model :(

Second model:

  Create VT pools per head. In this model we have a each head behave
indpenedently. For each head you you can VT switch around but you can
never VT switch to another head. 

Any other models/ideas people can think of? Comments welcomed!
  

"Look it's a text editor, no it's a OS, no it's Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

Re: Alots of updates.

[Vojtech P. <vo...@su...>]

On Wed, Apr 05, 2000 at 10:38:38AM -0400, James Simmons wrote:

> First Model:
> 
>    The current kernel doesn't really handle this very well. The kernel has
> 32 virtaul consoles. Fbdev has a function con2fb that maps a framebuffer
> to a VT or set of VTs. This is done because the current console system
> can't handle multihead properly. Continuing to use this model we would map
> devices around. Many problems with this model :(
> 
> Second model:
> 
>   Create VT pools per head. In this model we have a each head behave
> indpenedently. For each head you you can VT switch around but you can
> never VT switch to another head. 
> 
> Any other models/ideas people can think of? Comments welcomed!

Now I won't talk about implementation, but about configurations the model
we choose must handle:

1) Single monitor, single keyboard, many VTs. Simple.

2) Any number of monitors, keyboards, VTs. There must be a working
console which the root can log on even without any setup.

3) Same number of monitors as keyboards. Separate heads with multiple
VTs each for separate users that can think they have a computer for
themselves each.

4) Single keyboard many monitors. Each monitor has a couple VTs, any can
be selected from the single keyboard.

These are the four basic scenarios we have to cover. If we handle more,
then even better, but we have to handle these.

-- 
Vojtech Pavlik
SuSE Labs