In <Pine.GSO.4.05.10002111006500.1376-100000@willis.pubsites.buffalo.edu> James A Simmons (jsimmons@acsu.buffalo.edu) wrote:
>> >> 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...
JS> I have a idea on how to handle multihead in every case. It will be in my
JS> purposal for the 2.5.X kernel. A LOT of programs do depend on the current
JS> console. The current console should be the console you opened the app on.
JS> 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 :-)
JS> I have a possible solution. You don't need a config file but you do need
JS> 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.
JS> Yes /dev/tty still needs to be defined. You have to ask yourself why do
JS> you want to use multiple heads. Well usually you do this to display
JS> different data on different screens and accept different input for each
JS> screen for a application. A good example of this is a X server. You
JS> run one X server yet it appears to work independ on each head. This is
JS> just one case where their is no sharing. You could also want to share the
JS> screen image between several people. Think of a CAD workshop where several
JS> engineneers are working on the same project. Each designers input affects
JS> the image. Of course each employee can see what the other one is doing in
JS> real time because they share the same output. Another case is where you
JS> share the same image but only one can effect whats going on. A example of
JS> this would be a computer classroom. The teacher is the only one that can
JS> enter input and all the students can see the result of what she/he is
JS> doing. The other possiblity is sharing the input but everyone sees a
JS> different image. I can't think of a reason to use this but I'm sure
JS> someone would find this useful.
Huh. I can not see the "most obvious" case here: where you have two (or more)
monitors as one big virtual console. I want to have LOTS AND LOTS of GIMP's
toolbars on my small 15" monitor and big picture on my main 21" monitor. In fact
it's THE ONLY way to use multihead in Windows98. Of course Linux should allow
some other ways (when my niece ask me to run game I want just plug USB mouse,
USB keyboard, free small 15" monitor from my toolbars and start game
there -- not possible currently with Windows98) as well but this one SHOULD be
supported.
JS> For applications that do want to use multihead their is two ways they
JS> could go about doing it. One is access the raw hardware device. A example
JS> woule be a X server using /dev/fbX and /dev/event. /dev/event is basically
JS> a input queue a app can read. A keyboard press happens and a event packet
JS> is sent to this driver. A app can then read this packet. The packets have
JS> device IDs so you can tell what device it came from. Of course you have to
JS> make sure that the data is sent to the right places. You don't want a user
JS> app on head 1 to be able to read someone key strokes on head 2. Using the
JS> raw device is the best method when you don't want to share data. Even if
JS> you are sharing say the image but want to keep the input private. In this
JS> case you want to use the /dev/event driver and /dev/tty for displaying.
JS> For those apps that just have to use multiple ttys that can share
JS> data you have to break way from the idea of what makes up a console. You
JS> have it in your mind that a console is made of one monitor and one
JS> keyboard. I say a better model is the console is made up of X input
JS> devices and Y output devices. So you want a app to use two heads or maybe
JS> just one monitor and two keyboards. Now a process can only have one tty.
JS> Instead of thinking of it as a app wanting multiple consoles instead think
JS> of it as a app redefining a console. The app calls a ioctl on the terminal
JS> to a registers a additional keyboard and a additional monitor. Now you
JS> have one tty with two monitors and two keyboards. What if you want send a
JS> specific image to all the displays. You register the same display to
JS> several ttys. Just some ideas.
This is all great but IMNSHO in fact just VERY few applications should be
aware about multihead at all. X server, GPM server, may be few others (like
GDB). All other must NOT be aware about multihead thing at all. If multihead
support requires rewriting of each and every program it's BAD thing.
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:20 EST