RE: [Linuxconsole-dev] Welcome!!!

[Jon M. T. <ta...@ec...>]

On Wed, 1 Mar 2000, Brad Douglas wrote:

> > -----Original Message-----
> > From: Jon M. Taylor [mailto:ta...@ec...]
> > 
> > 	I think that we have three major areas of concern which 
> > will drive
> > the design of this project:
> > 
> > 1: What do we need?
> > 	* Better multiheading,
> 
> Each head should have it's own console.  Is this already being worked on
> now?

	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.
 
> > 	* Cleaner and more abstract [virtual] console representation,
> 
> I like the idea of moving /dev/fbx to /dev/fb/fbx/,fbx+1/... and each head
> having it's own VTs.  

	Careful, a "head" is really just the set of all input and output
devices, and their associated event handling 'map', whcih 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.

> I don't think this will be easily backward compatible
> and are there possible race conditions with each head having it's own VTs?

	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.
 
> > 	* fbcon backwards compatibility,
> > 	* /dev/gfx integration,
> > 	* Abstract input devices and event flow graphing,
> > 	* ...others...
> 
> 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). That way we have a lot fewer issues to have religious
wars over |->.

Jon 

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed