[PATCH xserver 16/17] Input: Add initial multitouch support from Xi 2.1

[Chase Douglas]

On 01/07/2011 10:57 AM, Daniel Stone wrote:
> On Thu, Jan 06, 2011 at 02:30:07PM -0500, Chase Douglas wrote:
>> 1. The protocol document implies that the server generates pointer
>> events from touch events. I didn't see any of that here (or maybe I
>> misread the protocol?)
> 
> I haven't implemented it in the server yet because I'm not sure how the
> semantics should look.  This isn't something we can really do without a
> workable client stack, so I'm happy to wait until you guys have
> something usable that we can at least test against to make sure we're
> not implementing something completely useless.

Ok. We can probably leave things as they are right now. We'll have the
protocol description as the end goal, but leave the event generation in
the MT evdev for now as we figure it out. I agree that server generation
is probably the best way forward.

>> 2. This is missing the previously discussed ability to request that the
>> server buffer touch events until the client becomes the owner of the
>> events. My proposal is to rename XIAllowTouchEvents to
>> XIModifyTouchEventDelivery, and have it handle touch allowance and
>> setting propagation flags like the buffering request. I would suggest
>> that we merely rename the call in this patch and add a patch on top to
>> implement the buffering.
> 
> Ah yes, so it is; this somehow failed to make it to my TODO.  When you
> say buffering events though - my recollection was that we were going to
> add a flag for clients to specify that they didn't care about
> intermediate states, i.e. didn't want to receive any events for
> non-owned touches.  Else we're going to have to add an arbitrarily-large
> touch buffer if even one client requests buffered events, which will
> require a roundtrip to recieve, ugh.

Yes, I think you're right. We should just store the initial internal
event and send it and an update event when such a client becomes the owner.

> Also, as discussed on IRC, I'm not entirely sure how to implement this
> without adding an extra XI_TouchMotionButOnlyIfIOwnTheTouch event type;
> I guess we could use the 16-bit padding in both the XISelectEvents and
> XIPassiveGrabDevice requests as flags with a TouchOnlyIfOwned flag.
> Peter?

I think we should just do a per-client flag, and use a new request to
set event delivery options.

If there are really fancy pants applications that need to handle some
selections both ways, they can always open a second connection to the
server. I doubt there will be very many of these.

>>> +            /* Only one client per window may select for touch events on the
>>> +             * same devices, including master devices.
>>> +             * XXX: This breaks if a device goes from floating to attached. */
>>
>> Maybe we should prohibit XIAllMasterDevices and any slave device
>> selection at the same time, just as is done for XIAllDevices?
> 
> That would prevent anyone from ever receiving touch events for a
> floating direct touch device if someone had an XIAllMasterDevices grab.
> I've been thinking about just allowing both grabs and selections on
> different devices (e.g. allowing them on all of the SD, the MD, all MDs,
> and all devices), and using the most specific one for delivery.  So,
> first check a grab on the specific SD, then the specific MD, then all
> MDs, then all devices.
> 
> At the moment, I can't think of how to manage the floating -> attached
> corner case in that comment (i.e. when you have a grab on a floating
> device which later becomes attached to an MD that also has a touch grab,
> or if there's an AllMasterDevices touch grab), so I'm inclined to not
> pretend we can always ensure exclusive access.

I want to ensure that whatever we do, we fall on the side of emitting
events only to one owning client at a time.

I wonder if maybe we should instead cause an attachment to fail if it
would break exclusivity here. With an appropriate error code the
requesting client would understand what's going on. It's a bit of a
kludge though, since XI 2.0 clients may get an error they don't
understand. In reality, this corner case shouldn't come up too often, so
maybe the kludge would be acceptable?

-- Chase