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

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

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

Yeap. That's the direction fbdev is heading in and Vojtech is doing the
same for the input suite.

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

Such as ? Can you a list of things you discovered about multihead and
secuirty and easy-of-use. 

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

A interesting idea. Well will look at your ideas once ruby developement
starts to kick into gear. 



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