Re: [Linuxconsole-dev] another feature

[Steffen S. <s.s...@ph...>]

James Simmons wrote:

> > In KGI terminology "focus" refers to a collection of physical input
> > device
> > drivers or event sources. E.g mice, graphic tablets, user specific
> > applications, etc. All events generated by these event sources will
> > be reported to the same event sink (input device). Currently this may
> > be the input device of a terminal emulator. Later a /dev/event mapper
> > will be added.
> 
> Okay. the Y input devices of a head is a focus. Vojtech has /dev/event
> and a input device and it's being used for USB devices. Now that Vojtech
> work will be head into CVS very soon you can take a look at what he has
> done and we can combine whatever both of you have developed.

There already is a patch to make Voitech's input drivers work with KGI,
though I had no time to test it myself or with the lates versions by
Voitech.
Maybe Voitech himself could also have a look at what I have done.

> I hope you still see a tty as just one keyboard and one display.

No. I see a tty (special file) as the application interface (mapper)
to a virtual terminal. And a virtual terminal from my point of view is
exactly one input device (kii_device_t) and exactly one output
device (kgi_device_t). These are keyboard and display _abstractions_
that need not be visible on a display to have the application be
able to use it. This draws a clear boundary between the
mappers (terminal emulator, graphical console) and the drivers,
enforcing modularity. The KGI terminal emulator API makes it
difficult enough to mess with the display hardware except through
the display driver so that noone will try to use this approach.
Why I think doing so is not a good approach? Because it hardcodes
mapper details into drivers. This is a BIG no-no for KGI.
 
> Linus doesn't care for people breaking the rules.

Neither do I. The current KGI implementation tries hard not to break
any UNIX concepts to achive it's goal. At least I am not aware of any
cases
and would be more than grateful for anyone who spotted this to be the
case
to tell me so I can fix it. The only point -- which I am also not
that happy with -- is the behaviour of mmap() on the /dev/graphic
special
file, which is modified such that resources aquired by one process
are not inherited by child processes or threads. This is a point Linus
himself stated to be 'an approach that might make sense in that and some
other contexts'. It could be made the standard behaviour if drivers had
a chance to influence the result of a fork. Currently in Linux
they haven't for whatever reason, so we have to live with that.

> > A "head" (or workplace as I prefer) in KGI terminology refers to a focus
> > and all output devices --simply speaking-- this focus may be focused on.
> 
> Okay. X input devices and Y output devices.
> 
> > A "workplace" may consist of several heads.
> 
> Thast teh whole machine. You can have a bunch of heads per machine
> normally.

No, it is _not_ the whole machine. It's the heads _one_ user has access
to.
This has implications on other resources, such as sound devices, local
peripherals, user-accessible interfaces (serial, parallel, ...).
Managing those via /etc/security/console.perms is a nice approach, but
will require distinction of workplaces.

> > Why have I split this? Because this avoids unneccessary constraints
> > on what virtual terminal is displayed on what display and each
> > KGI-head may appear to be a multidisplay workplace.
> 
> So /dev/vc/X appears to userland as one big VT pool even if internally
> where have a bunch of VT pools to each console. We just have to make sure
> you can't VT switch from one head to another head. If the heads are in two
> different offices then if we VT switch to another VT that's in another
> office I really don't feel like getting up and going to another office to
> use another VT.

For KGI this simply puts constraints on the internal mapping tables,
which determine which input or output device gets mapped to which
focus or display. Currently this table is static and handcoded,
simply because this sufficed to test KGIs multihead capabilities and
there are more important things to code right now; this being not a
major issue. 

Do you have access to a old monochrome display adapter (MDA)? In that
case you might want to give KGI a try and test it yourself.

			Steffen

_______________________________________________________________________________
Steffen Seeger                             
mailto:se...@ph...