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

[Chase Douglas]

On 12/02/2010 10:46 AM, Daniel Stone wrote:
> 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.)

That's fine with me.

[...]

>> 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. :)

Our design team believes it would be better to draw and then undo when a
gesture comes through. It's just been spec'd out though, we could play
with it and find that it's too unnatural. However, the point is that
someone believes it would be better this way, so my goal is to make that
possible.

>> 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*)

Sounds good to me :).

-- Chase