Re: [Linuxconsole-dev] comments on multi-heading/console

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

James Simmons wrote:

> > also, another possiblity would be to make solid api's for the fb, and
> > inputX, then create whatever console code you wanted in userspace,
> > bypassing any of linus's kernel decisions.
> 
> Personally I think this is the best approach for multihead aware programs.

A view I share.

> A VT should just be a one keyboard and one display. I used to think it was
> a cool idea to map a multiple devices like several display or several
> keyboards to a VT. So a VT would be 3 display and 2 keyboards and other
> crazy combos. Fbdev sort of does this now. 
> It maps a console to a display.
> With working with fbdev I realize now its a PITA. Know I think its better
> if a app wants to be multihead aware to open the explict hardware devices
> and grab them for themselves. Now of course the kernel has to see if
> someone is using a VT for any device you want to explictly use.

That is basically how my approach works internally to implement
consoles.
The video hardware drivers, input hardware drivers etc. only care about
mapping a virtual representation (devices) to the actual hardware.
 
> Take
> /dev/fb. You wouldn't want to be on a console and then all the sudden a X
> session starts because someone ran X on anther station requestion that
> head you are on. I really like to see the X server some day just using
> /dev/input and /dev/fb instead of any VTs like its does now.

But, there are more (security and ease-of-use) issues involved as
I had to learn.

Most important I found no (reasonably simple) way to establish 
proper protection/virtualization without introducting another process
attribute, the workplace ID. This should be set by the initial
login process like the user-ID. With that you can easily virtualize
console specific /dev entries as neccessary.
However, I did not implement it as there are much more issues,
especially login,xdm etc. need to be made aware of this.

			Steffen

PS: some 'low-level introductionary style' articles that explain how
KGI handles the human-machine interaction issues may be found at

http://www.tu-chemnitz.de/~sse/ggi

People on this list may or may not want to read and comment on it.

PPS: The sample implementation code referred in these articles
may be found there as well. Browseable or downloadable at your choice.
It is fairly useable in terms of a console replacement and I had a
simple true multihead system going with two keyboards and two monitors,
each running independent sessions, with multiple virtual terminals, etc.
_______________________________________________________________________________
Steffen Seeger                             
mailto:se...@ph...