Draft XI 2 protocol specification

[Daniel Stone]

Hi,
This is roughly relayed from what I remember telling you on IRC last
week.  Stupid failboat hotel internet.

On Tue, Jan 13, 2009 at 04:46:19PM +1000, Peter Hutterer wrote:
>     ┌───
>         XIDeviceEvent:
>             [...]
>             buttons:                    SETofBUTTONBIT
>             modifiers:                  SETofMODIFIERBIT
>             valuators:                  SETofVALUATORBIT
>             axisvalues:                 LISTofCARD32
>     └───
> 
>     BUTTONBIT { (1 << Button1), (1 << Button2), ... , (1 << ButtonN) }
>     MODIFIERBIT { ShiftMask, LockMask, ControlMask, Mod1Mask, ... , ModNMask }
>     VALUATORBIT { (1 << 1), ( 1 << 2), ... ( 1 << n) }
> 
>     SETofBUTTONBIT, SETofMODIFIERBIT and SETofVALUTORBIT are always padded to
>     4 bytes.
> 
>     [...]
>     buttons is the button state before the event, with a button mask set if the
>         matching button is down.
>     modifiers is the modifier state before the event, with a modifier mask set
>         if the matching modifier is down.
>     valuators specifies which valuators are provided in this event. If a
>         valuator's mask is specified, the valuator is provided in axisvalues.
>     axisvalues specifies the current value of the valuator in it's current
>         mode (relative or absolute).

I'd like to bloat this event hideously, so slap me if it gets out of
hand.

I'd like to raise modifiers to SETofMODIFIER2BIT, and use it like so:
(n << 2): modifier n is locked
(n << 2) + 1: modifier n is latched
(n << 2) | ((n << 2) + 1): modifier n has undergone latch-tolock

I don't see any reason to break with core and change the modifier values
tbh, so that looks like it's fine to set in stone.

Also, I assume buttons and modifiers are intended to replace state, but
you also need group, with the same encoding as SETofMODIFIER2BIT.

Then, if we want to make things truly useful, how about duplicating all
of buttons, modifiers, valuators, and axisvalues to provide before and
after state with all events? In the common case, this results in an
increase of 20 bytes (from 36 to 56 bytes) in event size, assuming I can
count at 6am.

>     ┌───
>         XRelativeMotionEvent
>             [...]
>     └───
> 
>     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.
> 
>     All fields are equivalent to the respective fields in the XDeviceEvent.

So do we specify that you must have the device grabbed to request
relative motion?

> The current status is that I have switched parts of the server over to
> generate and process XI2 events (it requires *a lot* of changes, but also
> cleans the server up a bit).

Yeah, I saw, and I also think we're going in the same direction.  Part
of my plan with -atkins is to have all the XKB filters just return a
list of potentially-modified events, and also to convert
GetPointerEvents + miEqEnqueue into PostPointerEvents.  Once that's
done, we're free to not have to pass lists of xEvents around.

One of the things I think would solve a fair few problems is having
something like this:
        int     clients_who_received_core_events_for_this[MAXCLIENTS/8];
        int     clients_who_received_xi1_events_for_this[MAXCLIENTS/8];
        int     clients_who_received_xi2_events_for_this[MAXCLIENTS/8];
which would, I think, solve a lot of problems we have with coherent
state notification.  So passing extensible EventListRecs around sounds
like victory to me.  (Also, no DDX ever modified the events it got.
Stupid API, in retrospect.)

> I'm not sure about the following things:
> - modifiers. daniel, can you chime in here how to solve this the best way?

As above.

> - device controls in XI2? Really? (see Presence event)

No.

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

\o/

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

Yeah, I think state that there can only be one instance of any class on
a particular device.  I think the feedbacks actually look alright (given
that mice have LEDs and crap these days, and keyboards have screens
again, hello StringFeedbackClass), so leave those mostly as-is; maybe
move BellFeedbackClass into KeyClass.

> - having 16 bit device ids requires to re-implement all requests and replies.
>   Mostly just typing, but it has to be done. 

Rather.  Any reason to not make it CARD32, anyway?

> - 32 bit keycodes is good but requires XKB2. I think. Daniel?

Yep, ACK.  Even if the grand xkbcomp integration hasn't happened, we can
just bump the format xkbcomp and the server use and call it XKM2.  (And
fix the vmods problem at the same time.)

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

Yeah, I reckon 32 + 32 would be cool.  What do the Wacoms provide? I
imagine high-end tablets give you pretty insane definition.

> - am I heading down a dead end?

No.  \o/

> - is it beer o'clock yet?

daniels at hyperdub:~% date
Mon Jan 19 06:26:55 EST 2009

Hmm.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20090119/9eb5278f/attachment.pgp>