[comp.windows.x] Double buffering & Input Extension Proposals

mlp@dana.UUCP (Mark Patrick) (01/13/88)

I have not seen anything in the xtensions mailing list for a while and
in particular was wondering what the current status of the double
buffering and input extension proposals are.  

We are planning on supporting some form of each of these extensions. 

We are willing to:

produce proposals, and/or 
implement the C X-lib interface and device independent portion of the 
server extension)

If necessary we will develop our own extensions (and make them available
to anyone interested) but we would rather work with others who are
seriously interested in these areas.  

Currently I have seen proposals from DEC, Sun (Dave Rosenthal) and 
Stellar and comments/counter proposal from Bob Scheifler.  How do each
of these stand with regard to each other? Is any one of these more
favoured than the others?  Is every company really going to offer its
own private extensions for these obviously needed functions?

Please mail any information either to me directly, this mail group or
to xtensions.

Mark Patrick
Ardent Computer
hplabs!dana!mlp 

gms@hpcvlx.HP.COM (George Sachs) (01/16/88)

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