[RFC XI 2.1 - inputproto] Various fixes in response to Peter Hutterer's review

[Daniel Stone]

Hi,

On Thu, Dec 02, 2010 at 10:30:56AM -0500, Chase Douglas wrote:
> On 12/01/2010 04:27 PM, Daniel Stone wrote:
> > The one thing that still concerns me here is promiscuous event sending:
> > where every client that has selected for the events receives them
> > whether it wants to or not.  The reason given for this is to enable
> > low-latency fallthrough, so that if the WM has a touch grab and decides
> > it doesn't want the touch events, the client doesn't have to round-trip
> > to the server to get a potentially huge buffer of all the touch data.
> > 
> > This is fine in theory, and I'm all for avoiding the roundtrips, but I
> > do worry that we've replaced one problem (buffering the touch data,
> > which may be huge, in the X server), with several problems (buffering
> > the touch data, which may be huge, in n clients).  Since a client would
> > be able to declare disinterest in a touch stream and pass it on to the
> > next client at any time, every client would have to buffer every touch
> > stream, and be ready to act on it.
> 
> I think there are some non-obvious benefits to this approach as well.
> For example, if a client cares about touch state rather than touch path,
> it would not need to buffer the data as it comes in. Think of a drag and
> drop operation. When a touch begins, it determines what object was
> selected. While the client doesn't own the touch, it just keeps track of
> the latest touch position as events come in. Once the client owns the
> touch, it drags the object to the last position seen. Thus, no buffering
> of the touch event stream is necessary.

For these clients, I think we could be a little smarter, and have a flag
in selection which specifies whether or not they want to receive
not-for-you events.  If they opt out of those events, then they could
just receive a single event containing the entire last-known valuator
state when the event becomes theirs.  (Or none at all if the event never
becomes theirs.)

> > Chase and I talked quickly about hints for this: clients being able to
> > say 'please do not send me any more events from this touch stream', for
> > cases like a global gesture recogniser that has decided it sees nothing
> > of use to it, as well as the corresponding 'please do not send any other
> > clients any more events from this touch stream', for when a client has
> > decided that the touch stream is meaningful to it, and that it won't
> > pass it on.  This would pretty much solve my concerns, except that it's
> > an irritating burden for app developers, and would probably be
> > reasonably difficult to get correct.  The penalty for forgetting to do
> > it, or getting it wrong, would be waking up every app with a touch
> > selection in the window trace every time you have an event, as well as
> > making them copy in the touch data, etc.
> 
> A few points I'd like to make:
> 
> 1. Most MT apps really just want gestures like pinch to zoom or pan to
> scroll. If these apps subscribe to a system-wide gesture recognizer,
> they won't need to subscribe to MT through X. This would allow them to
> have the MT support they want without being awakened on every MT event.

Sure, but at the same time this is a fairly strong break with the rest
of X input processing.  This isn't necessarily a bad thing, mind, it
just means that we need to think it through pretty carefully to avoid
creating something that's obviously different and difficult to get right
for potentially no gain.

> 2. MT apps that want to do atypical gesture processing or raw MT
> handling, like a drawing app, are the types of apps that could best use
> tentative events. They can begin gesture processing before they own the
> touch, or they could start drawing to provide some feedback.

Hm, I'm not sure whether a drawing app would ever want to start drawing
for not-for-you events; if I went to do a pinch gesture on a drawing app
and it started sketching out a path, my immediate instinct would be that
the pinch isn't going to happen and to try again.  I'm not a UI/UX/IX
designer though, so take that with a grain of salt. :)

> So I think it boils down to: normal clients should not be affected
> adversely, and more complex MT clients will want this flexibility
> anyways. I haven't been able to come up with many potential apps that
> would bridge this gap, potentially having wakeup storms for no benefit
> while not being able to effectively use tentative events for immediate
> feedback or processing.

OK, so would something like this suit you:
  * at selection time, clients can choose whether or not to receive
    not-for-you events
  * at any point during a touch stream, the current owner of a touch can
    tell the server that it should not send any more events for that
    touch stream to non-owning clients
  * at any point during a touch stream, non-owning clients can opt out
    of receiving further events from that stream
  * if a client which has not selected for not-for-you events becomes
    the owner of a touch stream, an event is sent to that client with
    the entire current state of the touch (i.e. dev->touch->last*)
?

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101202/e8f22cc5/attachment.pgp>