From: James Simmons <jsimmons@edgeglobal.com>
  To  : ggi-develop <ggi-develop@eskimo.com>
  Date: Wed, 14 Apr 1999 16:05:53 -0400 (EDT)

Re: current state of kernel input work?

On Wed, 14 Apr 1999 becka@rz.uni-duesseldorf.de wrote:

> Yes. IMHO it would be best to introduce the notion of a "head" into the
> kernel, which is a collection of IO devices that are associated with a
> given "workplace".
> 

Thats what I have been doing very recently. In the process of seperating
/dev/fb from fbcon. I soon realized that the console code was to
interwoven with VT switching. /dev/fb also had to know about VT switching
as well as teh console system. At this point I realized you have no choice
but to split the console code and vt switching code. With the vt switching
code I realized  multiheadeness could be implimented pretty easy. The
biggest problem I have is the spread of video drivers. In fbmem.c in
register_framebuffer I have code to create a head. Then in vgacon
vgacon_init I have head creation code. Its kind of scattered. I find the
VT handling a little of a pain right now. Need to work threw it more.

> However as there might be "shared" devices, this shouldn't be a 1:1 mapping,
> but allow to attach some devices to multiple heads or to easily move them
> between heads.

Completely agree. I have it set up that way. 

> 
> Interaction with such a head should be done with a _single_ /dev/tty like
> device (which as of now already combines two devices, the output device -
> usually a graphics card - and the input device - usually the keyboard).

Will be working on this. It is a matter of convicing the kernel guys to
have /dev/tty represent real heads and /dev/vty to represent virtual
heads. 

> This avoids many security issues you would have with a multi-devfile
> setup, as the getty just needs to chown a single file just like now.

One aprroach I had to solve that problem was to save the current device
state (file ownership, permissions) at the time of a VT switch. Then when
you switch back it installs the orginal permissions.

> It as well allows for hotplugging support without application help, as
> you will just see yet another device-id pop up in some events. With a
> multi-dev setup, you'd have to ask the application to open the new device,
> when it gets plugged in.

Working on this with the linux input development team. Know of a good way
to create a unique device id? Maybe something to deal with /dev numbers.

James Simmons                             Seeing is deceiving.  It's
System Admin EdgeNet Inc                  eating that's believing.
Linux Kernel Developer                    -- James Thurber
jsimmons@edgeglobal.com                   
http://www.edgeglobal.com/~jsimmons