Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!hplabs!hp-pcd!hpcvlx!gms
From: gms@hpcvlx.HP.COM (George Sachs)
Newsgroups: comp.windows.x
Subject: Re: Double buffering & Input Extension Proposals (current status?)
Message-ID: <1610002@hpcvlx.HP.COM>
Date: 15 Jan 88 23:16:18 GMT
References: <8801131528.AA06851@sandoz.dana.ether>
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 49

I don't know about double-buffering, but I can respond to the input
extension part of this note:

Hewlett-Packard is definitely interested in extending X input to support
non-standard devices.  We are planning to implement an extension to do
this regardless of what other vendors do, but feel that it's in everyone's
interest to come up with a common solution.

I have seen DEC's proposal, but not any others.  A good first step would
be to publish all proposals in a common place (probably xtensions).

Support of input devices necessarily involves ddx code, and so any
extension to do this will not be a portable extension.  However, some parts,
such as Xlib-level functions, dix code, and event definitions should
at least have a core set that is standard across all servers.

We are planning to send our proposal to xtensions in the near future, but 
here are some points that I think need to be addressed (most are addressed 
by our proposal):

1).  New input events will be desired.  For some of these, the server may
     need to send more information than will fit into the current 32-byte
     xEvent.  The proposed solution is to use more than one xEvent, which
     will require a small change to Xlib as well.

2).  New code should be defined in dix to route the new events to the
     appropriate client(s).  This code should be something that all
     vendors can live with, and should not break if someone defines a
     new event type later.

3).  New common input events should be defined, so that different vendors don't
     have events that contain the same information, but are of different
     event types.

4).  A set of Xlib-level functions should be defined, at least some of 
     which should be common across vendors.

5).  A means should be found of extending the select mask mechanism beyond
     its current limit of 32 masks (25 of which are currently in use).

We think that it is very important that there be at least a core set of
support for nonstandard input devices that is common to all vendors.  It
should be possible to write client programs that access graphics tablets,
buttonboxes, or any other device that is supported by multiple vendors,
with the expectation that the client programs will work with servers from
different vendors.

George Sachs
gms@hp-pcd