lkml.org 
[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[Multihead] was Re: [PATCH] devfs v99.11 available

> >> There are EXECTLY one tty with devfs now: /dev/tty - current tty for process.
>
> C> Define current?
>
> God knows :-) But every process SHOULD have /dev/tty as current tty for process
> ("the name of device /dev/tty is alias of terminal name used to log in system"
> backword translation from Russian translation). It's outlined in my "The UNIX
> Programming Environment" by Kernighan & Pike back from 1984 this way and I bet
> used in LOTS AND LOTS of programs. Even if it's not required by POSIX...

I have a idea on how to handle multihead in every case. It will be in my
purposal for the 2.5.X kernel. A LOT of programs do depend on the current
console. The current console should be the console you opened the app on.
See idea below and cases where multihead is needed.

> C> It's possible to not only have more than 1 monitor, but also more than one
> C> keyboard (PS/2 and USB for example). Suppose you have 2 keyboards and two
> C> monitors. Now how do you define current?
>
> There are should be configuration file somewhere I think :-)

I have a possible solution. You don't need a config file but you do need
a interface to register a device to the console with.

> C> Or am I just completely missing the point here?
>
> Yes and no. There are no natural way to define "current" tty if PROGRAM can
> work with more then one monitor and keyboard equally. Unfortunatelly this is
> not a choice: programs are NOT ready to work in such environment. Most
> programs do not care much about multihead. They just want something as
> its terminal (think about things like "crypt"). So /dev/tty should be
> defined somehow even with multihead: otherwise LOTS of programs will break.
> I'm not know how it'll be done, though. But it will ne done for sure.
> /dev/ttyN and friends (including /dev/tty0) on other hand are Linux-specific
> (it's usad by programs like XFree86 or GPM) and most should be rewritten for
> multihead anyway.

Yes /dev/tty still needs to be defined. You have to ask yourself why do
you want to use multiple heads. Well usually you do this to display
different data on different screens and accept different input for each
screen for a application. A good example of this is a X server. You
run one X server yet it appears to work independ on each head. This is
just one case where their is no sharing. You could also want to share the
screen image between several people. Think of a CAD workshop where several
engineneers are working on the same project. Each designers input affects
the image. Of course each employee can see what the other one is doing in
real time because they share the same output. Another case is where you
share the same image but only one can effect whats going on. A example of
this would be a computer classroom. The teacher is the only one that can
enter input and all the students can see the result of what she/he is
doing. The other possiblity is sharing the input but everyone sees a
different image. I can't think of a reason to use this but I'm sure
someone would find this useful.
For applications that do want to use multihead their is two ways they
could go about doing it. One is access the raw hardware device. A example
woule be a X server using /dev/fbX and /dev/event. /dev/event is basically
a input queue a app can read. A keyboard press happens and a event packet
is sent to this driver. A app can then read this packet. The packets have
device IDs so you can tell what device it came from. Of course you have to
make sure that the data is sent to the right places. You don't want a user
app on head 1 to be able to read someone key strokes on head 2. Using the
raw device is the best method when you don't want to share data. Even if
you are sharing say the image but want to keep the input private. In this
case you want to use the /dev/event driver and /dev/tty for displaying.
For those apps that just have to use multiple ttys that can share
data you have to break way from the idea of what makes up a console. You
have it in your mind that a console is made of one monitor and one
keyboard. I say a better model is the console is made up of X input
devices and Y output devices. So you want a app to use two heads or maybe
just one monitor and two keyboards. Now a process can only have one tty.
Instead of thinking of it as a app wanting multiple consoles instead think
of it as a app redefining a console. The app calls a ioctl on the terminal
to a registers a additional keyboard and a additional monitor. Now you
have one tty with two monitors and two keyboards. What if you want send a
specific image to all the displays. You register the same display to
several ttys. Just some ideas.

Codito, ergo sum - "I code, therefore I am"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.047 / U:0.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site