RE: [Linuxconsole-dev] Welcome!!!

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

> 	Yes.  EvStacks maps a "scroller" (/dev/tty) onto a VT, connects
> some event sources/sinks to the VT, and presto you have a console.  James
> and the other console developers appear to be thinking along similar
> lines.

Yes. The move is to have each fbdev driver unaware of the console system.
Fbcon is the interface from fbdev to the console system.

> 	Careful, a "head" is really just the set of all input and output
> devices, and their associated event handling 'map', which are being used
> by one person.  A binding, basically.  A "console" in the traditional UNIX
> sense is a keyboard and a TTY.  A head could consist of a VT102 terminal,
> or a standard PC keyboard + mouse + monitor + joystick, or even extreme
> cases like two monitors, a braille touchpad on a serial port, a USB
> joystick and keyboard, and no /dev/tty at all.  Heads and consoles are
> often the same thing, but sometimes they will be quite different.

Very true. Consider a workstation with several sound cards. Each employee
wants to listen to his own stuff. You have to make sure it goes to the
right person. This has to be done. 

> 	Yes, this could be an issue.  Right now I advocate head == VT, but
> for multi-monitor and such things this could get real ugly real fast |->.
> Watch the kernel remap a dozen different widely varying types of input and
> output devices back and forth every time you switch VCs!  Drown in races!
> Throw spinlocks all over the place!  Get into remote event handling and
> watch your network latency become your user interface latency!  Etc etc
> etc.  Of course we will probably want to be able to do most or all of this
> type of stuff, but Linus may balk at adding such complexity to the kernel,
> at least all in one go |->.  IMHO, this is an issue for Linus to decide.

KISS. See my other post about what a tty is to linus.

> > How does this fit in with DRI (I'm unable to find decent documentation)?
> > Are gfx and DRI trying to do the same thing?
> 
> 	More or less.  It would be very cool if we could design this new
> console system such that it could easily support and plug into /dev/gfx,
> DRI, KGI, fbdev, or any other potential kernel graphics (and input device)
> driver framework(s). 

Removing the consoel system from hardware drivers is the way to go IMHO.