Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!ucla-cs!uci-ics!zardoz!tgate!ka3ovk!drilex!axiom!linus!alliant!ama
From: ama@Alliant.COM (Alan Amaral)
Newsgroups: comp.windows.x
Subject: Re: Multiple Screens and Pointer Tracking?
Message-ID: <3420@alliant.Alliant.COM>
Date: 18 Sep 89 18:56:07 GMT
References: <8909152100.AA07252@kelly.>
Reply-To: ama@alliant.Alliant.COM (Alan Amaral)
Organization: Alliant Computer Systems, Littleton, MA
Lines: 209

In article <8909152100.AA07252@kelly.> marvin@kelly.UUCP (Kyle Marvin) writes:
>I am currently working on a multiple screen server implementation and
>have some questions on the best way to handle pointer tracking.  Each
>screen will be displayed on a separate monitor, and I'm wondering how
    .
    .
    .
>
>Kyle W. Marvin
>Visual Information Technologies, Inc. (VITec)
>3460 Lotus Drive 	Plano, TX 75075 	(214) 596-5600
>uunet!convex!vitsun!marvin


Here is a description of what we are doing with the Alliant multihead
X11 server.  It is very flexible as to what it allows you to do and is
easily extensible.  It was based on what I have seen with other
configuration files like termcap so there is precedent.

Basically the format of the file allows the user to specify what
hardware is on the system, what screens on what servers the hardware is
associated with, and how they are layed out.  For screen layout a compass
model is used where the user can specify that to move from one screen to
another the cursor is to be moved off of the {n, s, e, w} edge of the
first screen and it will move onto the corresponding edge of the other
screen.

The configuration file also allows the specification of different input
devices for keyboard and mouse for systems which have more than one.  It
also allows for definitions of other, non-standard devices, like knobboxes
or data tablets, etc.

Some of the definitions may not correlate strictly to what various X
documentation sources have used for some things (then again read N sets
of docs from different sources and get N different definitions of some
things), but they should be consistent within this document. (also, some
things might be more specific to our hardware/software implementation
and/or limitations but I've tried to cull those out.)

The configuration file is read at server startup time by a simple recursive
descent parser (which I'll rewrite someday using lex).

Note, our hardware configuration is limited to 4 heads per set of hardware
so you will see things like "head[3]" in places.  This could easily be
replaced by something like "/dev/cgtwo0" or "/dev/framebuffer" or whatever
your hardware looks like.



DISPLAY environment variable:

      hostname:display.screen


Definitions:

a)    Screen: A logical specification used to direct graphical output/input
      to/from a particular set of physical hardware.  The logical to
      physical mapping is specified in the configuration file.

b)    Display: A logical specification used to direct output/input
      to/from a particular set of screens.  The logical to physical
      mapping is specified in the configuration file.  Several
      screens may map to a single display.

c)    Head: A physical framebuffer and driving hardware associated logically
      with a screen.

d)    Seat: A station operated by a single user, consisting of one or more
      heasd/screens, a keyboard, and a mouse which are logically associated
      in the configuration file and via an X server.  (I though about calling
      this a workstation but that phrase is already overused...)


Configuration language description (BNF NOTATION):

        <line>        ::= <seat-elt> | <seat-elt> <comment> |
  			  <comment>
  	<seat-elt>    ::= seat[NUM]:<config-list>
	<comment>     ::= #STRING NEWLINE
  	<config-list> ::= <config-elt> | 
  			  <config-elt>:<config-list>
  	<config-elt>  ::= <kb-elt> |
  			  <mouse-elt> |
			  <input-elt> |
  			  <screen-elt> |
			  <empty> |
                          <continuation>
        <continuation>::= "\"
  	<kb-elt>      ::= keyboard=PATHNAME
  	<mouse-elt>   ::= mouse=PATHNAME
	<input-elt>   ::= input[NUM]=PATHNAME
        <screen-elt>  ::= screen[NUM]=head[NUM] |
			  screen[NUM]=PATHNAME |
                          screen[NUM].<direction>=screen[NUM]
        <direction>   ::= n | s | e | w



    Directions are default bidirectional, i.e.
	screen[0].e=screen[1]
     implies
	screen[1].w=screen[0]

    except where ambiguous, i.e.
	screen[0].n=screen[2]
     and
	screen[1].n=screen[2]

    Potentially ambiguous cases must be explicitly defined to be unambiguous
i.e.
	screen[0].n=screen[2]
	screen[1].n=screen[2]
	screen[2].s=screen[1]

This could be taken care of by using a combinational notation (i.e. ".ne"
and ".nw") and having each half or third of one screen correspond to each
of the other screens.  This would be easy to do.

    If you can leave a screen, you MUST be able to get back someway
(otherwise life can get real interesting).


Here is a sample of what the file would look like:


##############################################################################
# X11 configuration file
##############################################################################
#
# Seat 0 configuration for a sun with default keyboard and mouse devices:
#
#  associates /dev/kb with the keyboard
#  associates /dev/mouse with the mouse
#  head[0] is the only screen

seat[0]:keyboard=/dev/kb:	\
	mouse=/dev/mouse:	\
	screen[0]=head[0]

# Seat #1 configuration
#
#  associates /dev/keyboard0 with the keyboard
#  associates /dev/mouse0 with the mouse
#  screen #0 = head #4 is center (screen #1 is to the east, #2 is to the west)
#  screen #1 = head #5 is right  (screen #2 is to the east, for circularity)
#  screen #2 = head #6 is left
#  screens motion is circular
#
#  Screen layout looks like this:
#
#      	     +--------+   +--------+   +--------+
# (from 1) ->| scrn 2 |<->| scrn 0 |<->| scrn 1 |<- (back to 2)
#            +--------+   +--------+   +--------+
#  The cursor may not be moved off the bottom or top of any screen.
#

seat[1]:keyboard=/dev/keyboard0:	\
	mouse=/dev/mouse0:		\
					\
	screen[0]=head[4]:		\
	screen[0].e=screen[1]:		\
	screen[0].w=screen[2]:		\
					\
	screen[1]=head[5]:		\
	screen[1].e=screen[2]:		\
					\
	screen[2]=head[6]:

# Seat #2 configuration
#
#  associates /dev/keyboard1 with the keyboard
#  associates /dev/mouse1 with the mouse
#  screen #0 = head #1 is left  (screen #1 is to the east, #2 is to the north)
#  screen #1 = head #2 is right (screen #0 is to the east, for circularity)
#  screen #2 = head #3 is top   (screen #0 is to the south)
#  screens motion is circular
#
#  Screen layout looks like this:
#
#                   +--------+
#                   | scrn 2 |
#                   +--------+
#                    ^      ^
#		    /        \
#                  V          \
#      	     +--------+   +--------+
# (from 1) ->| scrn 0 |<->| scrn 1 |<- (back to 0) 
#            +--------+   +--------+
#  The cursor may not be moved to the south of screen #0 or #1, or to the
#  north of screen #2.  Motion to the south of #2 will always to to screen #0.
#

seat[2]:keyboard=/dev/keyboard1:	\
	mouse=/dev/mouse1:		\
					\
	screen[0]=head[4]:		\
	screen[0].e=screen[1]:		\
	screen[0].n=screen[2]:		\
					\
	screen[1]=head[5]:		\
	screen[1].e=screen[0]:		\
	screen[1].n=screen[2]:		\
					\
	screen[2]=head[6]:		\
	screen[2].s=screen[0]


Obviously many more configurations are possible, these are only a few.