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]