From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Wed, 14 Apr 1999 19:41:18 +0200 (MEST)

Re: current state of kernel input work?

Hi !

> - KGI talks about input processing--is this different from ggi-console? 

Yes. GGI-Console, AKA EvStack was a fundamentally different approach to the
whole user<->IO subsystem. It was based on pushing events through a
tree-like structure within the kernel to handle stuff like keyboard mapping,
terminal emulation, SAK etc. pp.

> - libGII is appealing but apparently kernel changes would need to be made
> so individual keyboards could be addressed/assigned.

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".

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.

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).

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.

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.

> - using libGII, would keyboard<->display resolution would be handled in
> userspace?

It could. LibGII is pretty generic about that. However I would really prefer
the above solution due to security considerations and better flexibility.

> - if ggi-console is separate, does it coexist with fbdev yet?

GGIconsole is asleep for now, as the main developer, Jason McMullan has
resigned from advancing it. I'll eventually pick it up again some day, but
I have very little time right now.

> - the USB patches impact a lot of the keyboard handling and actually may
> make the independent multihead problem simpler, but do the various ggi
> efforts take advantage (or at least coexist) with the USB/multikeyboard
> patches? 

They don't take advantage yet. We'd have to look at what these patches do.
LibGII should be able to accomodate any reasonable scheme.


> I have a web page that discusses some of the hurdles of independent
> multihead and suggests a start at a solution. I'd like to hear your input
> from a ggi perspective. Please have a look: 
> http://pacific.pht.com/~brad/patches/mhead/

Will do.

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =