XlInputExtensionDoc.tioga
Copyright Ó 1991 by Xerox Corporation. All rights reserved.
Created by Christian Jacobi, January 7, 1992 10:20 am PST
Christian Jacobi, January 7, 1992 2:38 pm PST
UNFINISHED.
UNTESTED.
Abstract
XlInputExtension supports the X11 input extension
Documentation of functionality
Detailed documentation for particular function is to be found as comments in the definitions module.
All requests and types are set up to exactly match the features of the protocol, unless specified differently. Comments are restricted to differences in semantics or naming to the protocol. Names are chosen like in the protocol, even when the protocol appears to be inconsistent.
A difference to the bare protocol is in the event handling. Events which are generated in groups by the server (because the data wouldn't fit in 32 bytes) are combined by XlInputExtension. In such cases a single event with all the data is handed to the Cedar client.
See also the following standard X11 files
Documentation
/project/X11R5/source/public-release/mit/doc/extensions/xinput/*
/project/X11R5/source/public-release/mit/hardcopy/extensions/xinput/*
C Include files
/project/X11R5/source/public-release/mit/extensions/include/XI.h
/project/X11R5/source/public-release/mit/extensions/include/XInput.h
(/project/X11R5/source/public-release/mit/extensions/include/XIproto.h)
C Source files
/project/X11R5/source/public-release/mit/extensions/lib/xinput/*
Scope and completeness
The X input extension has been a blessed consortium standard for X11 since release X11R5. This package supports that original X11R5 version.
SendEvent, keyboard, and, most window manager functions are to be looked for in "extras" packages. The base package is not the complete extension, but complete enough so that no recompilation is needed to add the missing requests in extra modules.
XlInputExtension: Base support for this extension
XlInputExtensionKeys: Supports the Keyboard related functionality
XlInputExtensionExtras: Supports window manager level functionality
The reason to split this package in separate modules is (to a small part) the fact that not the complete functionality has been programmed yet. More important, this allows restricting the the amount of code loaded into a Cedar world.
Implementor notes 1)
Problems found in Xl
I think extension events should be handled more flexible in XlImplMainLoop. Extensions ought be able to register different procedures for different event-codes.
Extension error messages should be registered.
Think again about taking advantage of keystate notify being immediately after focusin how this fits with extensions doing the same trick...
Missing requests: GetKeyboardControl, GetPointerControl, ChangeKeyboardControl, ChangePointerControl
Problems found in input extension semantics
Why do DeviceButtonStateNotify and DeviceKeyStateNotify contain MORE𡤎VENTS but DeviceValuator does not. It says nowhere that DeviceValuator are reported in order.
Why do replies repeat the opcode?
Problems found in input extension protocol doc
In a nutshell: It is terrible.
Why does protocol spec mention macros (chapter 2.7.)? Macros are not defined at this level; it better had the contents.
Encodings do not have event-offsets (called "code").
Encodings define DeviceValuator twice. The second definition of DeviceValuator defines "n" twice.
Protocol-spec uses in
OpenDevice: returns device←id: XID while encoding does not contain any bits for this field.
CloseDevice et all: device: DEVICE DEVICE is not defined.
Encoding has duplications with core protocol.
Encoding contains new errors; protocol does not.
Both GetDeviceControl and ChangeDeviceControl return a DEVICE←RESOLUTION. It ought to have different names or same fields.
Protocol-spec Proximity events contain axis-data; encoding does not.
Encodings for SetDeviceMode "3+first𡤎rror" is not comprehensible to me.
ListInputDevices: isXPointer, isXKeyboard order is different in protocol spec and encoding. This is of course not a bug but it is unconveniant and leads to errors.
2.7. Speaks about deviceButtonPressGrab; could it mean deviceButtonGrab?
In encoding of GrabDeviceButton there is a 1 byte field owner-events with a 2 byte suggested value for AnyModifier
In QueryDeviceState, it returns n = number of input classes. Is there a relationship between n and number of entries in list for LISTofINPUTSTATE?
In GetDeviceButtonMapping, protocol mentions an nmap parameter. This doesn't really exist according to encoding.
In GetDeviceModifierMapping, protocol mentions a count parameter. This doesn't really exist according to encoding.
Problems found in input extension C lib
Why not wait for all valuator events?
Implementor notes 2)
Problems found in input extension protocol doc
GetFeedBackControl:
(In encoding:) What is "id of this feedback"
(In encoding:) "feedback class id" is not unique
ChangeFeedBackControl:
value mask: says "has n bits set to 1". Seems impossible to me.
value mask: values not unique.
what is "id of this feedback"
Why do feedback class id use different values in GetFeedBackControl and ChangeFeedBackControl?