Draft XI 2 protocol specification

[Keith Packard]

On Tue, 2009-01-13 at 16:46 +1000, Peter Hutterer wrote:

>     An XDeviceHierarchyChangedEvent is sent whenever the device hierarchy has
>     been changed by either the client, or by server-internal events. The flags
>     specify all types of hierarchy modifiations that have occured. 
>     Clients are expected to query the server for the new hierarchy.

If clients need to take another round-trip, why pack any info into this
event other than the 'something changed' bit? Presumably this doesn't
happen very often, right?

Alternatively, pack the whole change into the event?

>     Classes is a list of input device classes that are now provided by the
>     device, see XI 1.x specification for more details.

Similarly, any reason to not just have the client download the new
device state after it receives this event?

A viable answer here might be that placing the data in events instead of
later replies is that clients can correctly parse the intervening event
stream. This doesn't apply to XDHCE events above as clients must query
state anyway.


>     root, event, child are the root window, event window or subwindow,
>         respectively. See core protocol spec for more detail.
>     root_x, root_y is the position of the pointer in screen coordinates
>     event_x, event_y is the position of the pointer in screen coordinates
>         relative to the event window.

Send these in floating point so we capture sub-pixel positions
trivially?

>     last_button is the highest bit set in buttons and determines the size of
>         buttons.
>     last_modifier is the highest bit set in modifiers and determines the size
>         of modifiers.
>     last_valuator is the highest bit set in valuators and determines the size
>         of valuators

Clients are likely to decode this incorrectly as you have to be careful
about all of these. Any reason to not just  indicate the length of each
bit vector in 32-bit units?

>     axisvalues specifies the current value of the valuator in it's current
>         mode (relative or absolute).

I assume the native values for all devices are integers?

>     Relative Motion event.
>     type is XI_RelativeMotion
>     This event is sent regardless of clipping and always provides the
>     device-specific data. Pointer acceleration does not affect the axis
>     values.

Uh. What about absolute devices? Can those send XRelativeMotionEvents?
If so, this seems more like an XIDeviceRawEvent.
(same comments about last_* apply here)


>     ┌───
>         XIPresence
>             GENERICEVENTDATA
>             devchange:                  SETofDEVICECHANGE
>             control:                    CARD16
>     └───
> 
>     DEVICECHANGE { DeviceAdded, DeviceRemoved, DeviceEnabled, DeviceDisabled,
>                    DeviceControlChanged }
> 
>     DevicePresence event, equivalent to the XI 1.4 event. 
>     type is XI_PresenceNotify
>     devchange specifies the type of device change that has occured. If
>     devchange is DeviceControlChanged, control specifies the ID of the device
>     control that has changed. Otherwise, control is unspecified.
> 
>     The length of a Presence event is always 0.

How about describing this event in detail, rather than saying 'Like XI
1.4, except'. Keeping the XI 2 spec stand-alone would reduce the amount
of reading when learning how to do input.

> - this isn't fixing the problem we have with devices that are both pointers and keyboards

So make all devices both pointers and keyboards and have XIDeviceEvent
include keys as well as buttons.

> - how do go about input classes. refurbish them?

I'm wondering whether input classes have any place now; just make all
devices the union of all classes?

> - having 16 bit device ids requires to re-implement all requests and replies.

Use 32-bit device ids then.

>   Mostly just typing, but it has to be done. 
> - 32 bit keycodes is good but requires XKB2. I think. Daniel?

> - still no subpixel precision, unless we decide to make the valuators 24.8, or
>   provide 32+32 or something.

16.16 is sufficient as X screens can't be larger than 16 bits anyway. Or
floats.

> - am I heading down a dead end?

I don't think so; let's keep pushing towards eliminating weird
distinctions between devices and make sure we've got effectively two
kinds of events -- clipped and processed by the server, and raw device
events.

> - is it beer o'clock yet?

Nothing related to X should have trouble finding a bar.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20090112/bac42f0e/attachment.pgp>