Re: [Linuxconsole-dev] another feature

[James S. <jsi...@ac...>]

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

We all have to work together to get things done. 

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

Okay. So you can use /dev/tty even when no keyboard or display is
attacted. The current method is dummy_con when no display is avaliable
and in Vojtech work he has a dummy_keyboard when no keyboard is present. 
Which is mapped by take_over_console for displays and I don't know for
input devices. I have to look. Dummy con is what I use on a explict open
of /dev/fb so fbcon isn't used. This prevents fbcon using accels at the
same time as /dev/fb. 

> This draws a clear boundary between the
> mappers (terminal emulator, graphical console) and the drivers,
> enforcing modularity. 

The natural flow appears to be heading in this way. 

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

I agree. Thats the way it should be. 

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

I just spoke about this on the kernel mailing list. 

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

For now. I know when I finish linux GFX so SGI Infinte Reality engine can
be ported over this problem will be fixed. 

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

Okay.

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

No :(

"Look it's a text editor, no it's a OS, no it's Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U