NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/sci/virtual/4251

Internet Message Format | 1992-12-31 | 4.1 KB

Path: sparky!uunet!noc.near.net!hri.com!enterpoop.mit.edu!micro-heart-of-gold.mit.edu!uw-beaver!news.u.washington.edu!stein.u.washington.edu!hlab
From: [e-mail] (Bruce Cohen)
Newsgroups: sci.virtual-worlds
Subject: Re: TECH: Has anyone extended X?
Message-ID: <[e-mail]>
Date: 29 Dec 92 16:15:47 GMT
References: <[e-mail]> <1992Dec17.203714.8346@u.w
Organization: Mentor Graphics Corporation
Lines: 60
Approved: [e-mail]
NNTP-Posting-Host: stein.u.washington.edu
Originator: [e-mail]



In article <[e-mail]>,
[e-mail] (Gavin Bell) writes:

|> In my humble opinion, X (and Xt) is really broken when dealing with
|> devices other than the keyboard and mouse.  Dealing with arbitrary
|> input devices is certainly non-trivial, but it seems like a much
|> better job could have been done with some careful thought and design.
|> After all, you don't have to worry much about optimal performance;
|> these are all fairly low bandwidth input devices (mice generate a few
|> hundred events per second at most, trackballs and datagloves about the
|> same...).
|>

1) I agree that a more general input model than the one provided by the
   X input model is highly desirable.  A good place to start is the
   logical device model first developed for GKS.  This was later
   extended and implemented by Tektronix in the input system of the 4100
   and 4200 series graphic terminals (sadly, Tek is not in that business
   anymore).  I proposed a similar model to the X input model working
   group when the model was being developed, but could not find
   sufficient interest to get it incorporated.

   The basic idea is that the graphic system provides some number of
   logical devices, abstractions of a physical device, each of which has
   some number of input axes (conceptually each axis has a real number
   value with some bounds), a set of triggers (input events with an
   associated small integer value; these include keys and buttons), and a set
   of actions (such as movement of a cursor, or echo of a character in a
   text area).  There is also a set of physical devices, mouse, tablet,
   dialbox, keyboard, etc., and a mapping from the input axes and events
   of the physical devices to those of the logical devices.  One nice
   feature of this architecture is that the clients are insulated from
   the current complement of physical devices, so that if you don't have
   a 6-DOF dialbox for controlling viewpoint in a 3D view, for instance,
   you can map the two axes of a mouse to two of the axes of the logical
   input device driving the view, and change the mapping by connecting a
   button or function key or whatever from the keyboard or the mouse to
   an action which remaps the axes to change from X & Y translation to
   pitch and yaw, for instance.  All of this takes place without any
   knowledge or action necessary by the client application, which just
   continues to get the same event streams it always got.

2) While input devices are indeed low bandwidth devices (you typically
   only have to respond to 60 events per second per device for smooth
   updating, and if you get more events than that you can batch them up
   at that rate), but there are profound implications for the system
   architecture because some software will have to respond to those
   events within some delay latency time and event rate criteria.  If
   each event requires several process context switches, or network
   transactions, as it might if the event handling were separated by
   client-server boundaries, then a few hundred events per second can
   have a real impact on system performance.  That's why it would have
   been nice to get that logical model into the X server itself, to save
   some of that overhead.
------------------------------------------------------------------------
Bruce Cohen, Mentor Graphics Corpooration | email: [e-mail]
8005 SW Boeckman Road                     | phone: [phone]
Wilsonville, OR 97070-7777                |