[RFC] Multitouch proposal v2 + implementation

[Ping Cheng]

On Mon, Sep 20, 2010 at 9:58 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> On Mon, Sep 20, 2010 at 10:29:49AM -0700, Ping Cheng wrote:
>> On Sun, Sep 19, 2010 at 9:45 PM, Daniel Stone <daniel at fooishbar.org> wrote:
>> > This is my second draft of the multitouch proposal, along with a fairly
>> > complete implementation; patchsets for inputproto, xserver,
>> > xf86-input-evdev, libXi and xinput follow.
>> >
>> > This is more or less half way between Peter's proposal and my original
>> > one: it doesn't use valuators anymore, but it has a different, and
>> > hopefully more workable, approach to grabbing.
>>
>> I have a corner case that I'd like to know how you address it.
>>
>> How do we deal with the single touch case for multi-touch devices?
>> Shouldn't we still post valuator for single touch events so MT devices
>> can perform single touch functions while the touch is not grabbed by
>> the client? The single touch use case can occur before and after the
>> client grabs the MT events.
>>
>> Maybe you have already discussed and covered this case in your
>> proposal. But I am not familiar with the X server (and evdev) code. So
>> I am taking a shortcut to get my question answered - asking the expert
>> :).
>
> Actually, I haven't discussed that in the spec, only briefly with Peter.
> Core emulation is actually somewhat tricky, as you need to guarantee
> that you're the only one sending core events.  The following scenario is
> the kind of thing I'm worried about:
>    * T+0: TouchBegin started on SD 1, sent to client A via sync grab
>    * T+5: Core event sent from SD 2, sent to client B via sync grab on
>           MD 3, device frozen
>    * T+6: More core events enqueued from SD 2 -> MD 3
>    * T+10: Client A uses ReplayTouch on touch stream, no other
>            listeners found; core events emulated, routed through MD 3
>
> MD 3's core events queue for client B is now going to going to contain
> events from T+5, T+6, T+7 ... and then T+0.
>
> So I think for core emulation, the only safe way to do it is going to be
> to decide at event generation time whether it's going to be a core event
> or a touch event.

Yea, I understand that. My question is who is responsible to make the
decision, the X driver, the X server, or the client? I would think it
is the client. Then we (the driver and X driver) need to pass the
events to them (the clients).

>  I've seen some kernel drivers which emulate ABS_[XY]
> events for the first finger down, which seems like the most sensible
> semantic I can think of.

There is no problem for kernel drivers to send ABS_{X/Y]s. But the
issue remains since it is a decision in the user land instead of in
the kernel. It is us, who work in the user land, to decide how we want
the data to be translated. I just wanted to make sure that your spec
considers this case.

> Does that make sense?

Yes, it does. But more discussion won't hurt either :).

Ping