Draft XI 2 protocol specification

[Matt Helsley]

On Mon, 2009-01-19 at 06:27 +1100, Daniel Stone wrote:
> 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.

Some data for this:

Most of the wacoms I see on NewEgg are 2000 lines per inch.
My tablet is a cheapo tablet (< $200) and it still has 2000 lines per
inch. At 12x9 inches thats a nice 24000x18000 which far surpasses my
screen resolution. Selfishly optimizing for my tablet and screen would
put most of the bits in the subpixel coordinates.

Pressure levels I've seen tend to be in a much smaller range: 512-1024.

However I don't use/develop tablets professionally. So I don't have the
really nice stuff and I have no idea what resolutions we'll see in the
future :).

Cheers,
	-Matt Helsley

> > - 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
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg