Index: [thread] [date] [subject] [author]
  From: Steffen Seeger <s.seeger@physik.tu-chemnitz.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 15 Apr 1999 12:28:09 +0200 (MEST)

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.

That's why I rewrote it from scratch. So I am not the only one
to realize that. :-) Basically, the notion of "head" is equivalent 
to KII's notion of a focus. However, we need a 'workplace' id to be
assigend to processes (just as user and group id's). KII currently
uses the controlling tty (or that of the parent, if a process has none)
to determine the workplace a process belongs to. Not perfect, but working.

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

This will always be a pain if you refuse to accept that a _central_ resource
management instance (like KGI/KII) is neccessary. Yes, you can avoid it,
but it will be far easier if you do accept it. You can believe me that
I took a very long thought before deciding to throw the kernel console
system away and replace it with code written from scratch.

Take a look at the KGI-0.9 code. All that's missing to have graphical
multihead is to enable the dev_graphic_init() to have /dev/graphics 
(or /dev/fb, /dev/gfx) and to write a driver for your card.

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

That's what the workplace ID is needed for. This way you can have
/dev/wp/mouse, /dev/wp/graphics, /dev/wp/audio etc. which are mapped to
/dev/wp0/mouse, /dev/wp0/graphics, ... just like the console<->tty mapping.

However, either the sound drivers etc. or the central management code needs
to be aware of that.

			Steffen

----------------- e-mail: seeger@physik.tu-chemnitz.de -----------------

Index: [thread] [date] [subject] [author]