[PATCH xi2.1 inputproto] Many more updates to the XI 2.1 protocol

[Peter Hutterer]

On Thu, Mar 10, 2011 at 03:47:41PM -0500, Chase Douglas wrote:
> Signed-off-by: Chase Douglas <chase.douglas at canonical.com>
> ---
> To see the full protocol spec as I make changes, go to:
> 
> http://cgit.freedesktop.org/~cndougla/inputproto

[...]
 
> Areas known to be lacking consensus agreement:
> 
> * How to handle touch begin for clients who don't want unowned events. I think
>   defining touch begin as a representation of the begining of a touch, as
>   opposed to an event sent immediately after a touch begins, clarifies things.
> * Dropping of TouchUpdateUnowned hasn't been discussed before.
> * Should IndependentPointer devices be a separate touch device mode? Peter
>   suggested using labels somehow, but I'm not sure what that means. I've left
>   things as they were for now.
> * Addition of active_touches to DeviceEvent has not been formally reviewed
> * Should clients be able to make multiple grabs/selections per physical device
>   per window? This also affects whether slave touch selections are canceled on
>   device attachment.
> * Should direct touch emulated pointer events send motion then button press
>   events, or just button press events? I worry about XI 1.x, which turns a
>   button press into two or more events (button press + 1 or more valuator
>   events) and how that could affect things. I think it's easier to leave it as
>   it is.

Slugging my way through it. fwiw, I didn't look at the patch but rather at
the protocol spec as a whole to check if it makes sense when you _dont_ see
what's been there before. I've read through the whole protocol, but these
comments here affect mainly the top section before the actual protocol
descriptions start.

Comments:
* the different TouchBegin semantics (owner/non-owner) IMO make sense
  because they simply reduce the semantics to "Begin" is the first event
  you'll get. this made less sense in the patch but reading the spec in one
  go it seems to fit nicely
* there were several sections where I got badly confused. I've tried to
  improve them, feel free to point out where things aren't clear.
* it is not clear whether a passive grab can be established for owner-only.
  does a grab always require the ownership semantics or can there be the
  default TouchBegin semantics too? If so, how is this decided?
* can we allow more than one TouchObserve grab on the root window? after
  all, they won't be doing anything with it anyway
* it seems impossible to be an observer that gets ownership. for a situation
  where you are below the accepting client, this means you're stuck. you can
  either observe (and never get ownership) or not observe (and lose those
  touch sequence the parent accepts)
* the TouchObserve grab concept as-is doesn't quite fit. the idea originally
  came up to solve the problem of a grabber that wants to keep getting
  events after rejecting. That is what TouchRejectObserve does. The grab
  mode TouchObserve doesn't fit. if you can't become owner anyway, this is
  hardly different to RawEvents so we could use those.
  which brings me to
* no RawEvents for touches? would be a good time to fix the broken grab
  semantics for raw events too (deliver them even if a grab is present)
* SemiMultitouch simply needs a better name. Why not use BoundingBox or
  something more descriptive?
* If SemiMultitouch isn't good enough to give you touch points, how is the
  pointer emulation decided?
* as pointed out in the other email, I'm still confused on whether the
  master device delivers touch events. this isn't mentioned in the spec but
  the last patchset I reviewed skipped touch events from the master device
* in the touch event delivery section, the sentence "No touches from an
* indirect device may begin while the
  device is floating, as it does not have an associated pointer position to
  focus events." This is incorrect. Run XIQueryPointer on the floating
  slave, you'll see it does have a pointer position. In fact, it even has a
  sprite, it's just not rendered.
  this is in-line with XI1 where clients are expected to manually
  render the cursor.
* pointer event handling for indirect devices: what was the motivation for
  withholding touch events when the pointer leaves the window again? 
  It isn't clear what "withheld" means, even if you have the ownership
  selection, you still don't get it? this whole concept feels a bit tacked
  on the side and breaks ownership assumptions (that touch events are
  delivered immediately if you can cope with ownership changes).
* it is unclear if a client can grab for pointer + touch, both actively and
  passively. this is an issue for dependent device, especially because touch
  events are withheld during pointer grabs.
  I think the event mask should be honoured during grabs if valid.
* a device that emulates pointer events must also initialize valuators
  though they may serve no other purpose. should there be a mapping field in
  the TouchAxisClass to say which valuator this one maps to in case of
  pointer emulation?
  for a client it may be important to know that the axis a device advertises
  is just there because of pointer emulation.
  same goes for the button class, you need one to send button events.
* it is unclear how pointer emulation works. x/y, fair enough. what about
  pressure and other information potentially available?  
* pointer emulation describes very well how button events are generated very
  well (see my comment below though) but I predict that sooner or later
  people will want the feature to emulate third buttons per timeout, etc.
  any plans?
* in the pointer emulation section the protocol states that "Both the
  emulated pointer events and their associated touch events will have the
  PointerEmulated flag set." That is after a paragraph that states that
  pointer and touch events are mutually exclusive. so you get either pointer
  or a touch event with that flag but you cannot get the other.
  that seems rather pointless. if you select for touch events, you won't get
  the emulated events anyway and if you select for pointer events you never
  see the touch events. so I'm wondering what that flag conveys other than
  the server saying "hey, I know more than you about this event" :)

> * Should IndependentPointer devices be a separate touch device mode? Peter
>   suggested using labels somehow, but I'm not sure what that means. I've left
>   things as they were for now.

e.g. we can provide a property on the touch device to label is as
independent. this isn't something that changes often and it seems to have zero
effect on the protocol.

> * Should direct touch emulated pointer events send motion then button press
>   events, or just button press events? I worry about XI 1.x, which turns a
>   button press into two or more events (button press + 1 or more valuator
>   events) and how that could affect things. I think it's easier to leave it as
>   it is.

don't confuse input drivers, the input API and the XI protocol. atm, it's
the drivers converting and afaict there is no requirement in the protocol
for this.

Branch is up in my people repo, not counting typos and the need for section
renumbering.

    git://people.freedesktop.org/~whot/inputproto.git multitouch

Cheers,
  Peter

>