From: Steffen Seeger <s.seeger@physik.tu-chemnitz.de>
  To  : ggi-develop@eskimo.com
  Date: Wed, 14 Apr 1999 10:32:51 +0200 (MEST)

Re: current state of kernel input work?

> hi,
> 
> I am trying to work toward independent multihead. I followed ggi-console
> for a while but at the time it was incompatible with framebuffers and was
> incomplete. I'd like to contribute but at the moment finding out where all
> the ggi efforts are is daunting. 
> 
> - KGI talks about input processing--is this different from ggi-console? 

Let's differentiate: the old KGI (ggi-0.0.9) had input and output processing
closely connected in the console/kgi code. However, it supported independent
multihead out of the box.

ggi-console used a more message passing oriented approach, but
is discontinued.

KGI-0.9 (the new one) has input and output processing well separated, and
is quite useable right now. It has some problems with the keyboard driver,
but they are fixed with the next snapshot.
 
> - libGII is appealing but apparently kernel changes would need to be made
> so individual keyboards could be addressed/assigned.

That's what the kernel patches in the new KGI design do.

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

The kernel part handles this for consoles. However, for graphics devices
this is a policy decision and can be made optional.

> - 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 cannot coexist, as KII takes control of all input devices.
This will be a) through kernel level drivers (kbd-i386.c) or b) user level
drivers (e.g. the various mice will be supported by a daemon that parses
the protocols and injects events to the kernel using a special device).

However, the USB drivers can easily take advantage of KII, as for each
physical input device, you just have to register a kii_input 'driver'
and send events through kii_handle_input(). This is very easy, and all
the other (multihead) stuff is handled by the KGI/KII subsystems.

> 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/

KGI-0.9 is ready for and supports independent multihead, that's one of the
points it has been designed for. I have not been able to test this feature
yet, because I had to setup my new development machine and went into 
some trouble there. However, it is running now, and I am going to test 
independent multihead and probably release a new snapshot early next week.

> Brad
> brad@pht.com | http://www.pht.com/~brad/

			Steffen

PS: The last snapshot can be found at my homepage
http://www.tu-chemnitz.de/~sse/ggi


----------------- e-mail: seeger@physik.tu-chemnitz.de -----------------
------------- The GGI Project: http://www.ggi-project.org -------------