linuxconsole-dev

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

[Firstname L. <ms...@ho...>]

Hi.  I've seen a lot of good stuff written in this list so far.  (and were 
not even a week old ;)

As for keeping things simple, the simplest way to get multi-console support 
is to add /dev/InputX  (event) support to GGI.  Someone said they were 
planning to do this, i forgot who.

with /dev/InputX support, you should be able to run XGGI on one monitor, 
with a keyboard and mouse, and run a seperate instance on a second monitor, 
with a USB keybaord and differn't mouse.  It might not be as flexable as you 
were hopeing, (actually you could probably just make extra drivers to 
generate /dev/InputX events, like one that hooks to telnetd, so someone 
could telnet in, and that input comming over the network could be used as 
the input of the console), or as fast as you were hopeing, but should be 
able to satisfy a large number of the cases, with minimal work, and get a 
lot more people interested in the project.  (and ready to bitch about what 
they don't like with the way it's being done :)  also i've heard that 
there's a ggi-terminal emulator, which let's you run a shell.  Of course 
linus wouldn't be needed to do this either, since it dosn't mess with the 
kernel.


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.  But adding event support to GGI is still 
the quickest way to get feedback.

Corey

(note: i don't know about others, but i intend to actually use this once 
it's created ;)
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

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

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

> Hi.  I've seen a lot of good stuff written in this list so far.  (and were 
> not even a week old ;)

Its just starting :) The number of people interested keeps growing. Even
Eric Raymond is involved in this project. 
 
> 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 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. 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.  

"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

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

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

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

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

James Simmons wrote:

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

Quite a lot of them aren't ideas any longer, but are already tested
and working code. I will try to get a detailed documentation of my
console system done, post it on gg...@kl... and CC it to this
list.

			Steffen

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

The difference between a "concept" and a "random collection of routines"
is that the concept will survive, and the routines won't. -- L. Torvalds