Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Peter Hutterer wrote:
> On Tue, May 18, 2010 at 10:10:29PM +0200, Henrik Rydberg wrote:
>> This patch adds documentation for the SYN_MT_SLOT event and gives
>> examples of how to use the event slot protocol.
> 
> thanks, this is really nice documentation! the approach seems good, though I
> do have a few questions inline.
> 
[...]
> 
> Is there a limit on the number of slots?

The slots are dynamically allocated by the driver, so there is no practical
limit. Each slot currently takes 44 bytes, and allocating a few kilobytes of
kernel memory is not a problem.

> Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
> in advance if a device may use slots or not?

Eventually, this might become true, but you are pointing at one of the weaker
points of the current setup. There is no bit field for the EV_SYN events, so
there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This
could quite possibly be added to the EVIO interface. Meanwhile, the method I use
is to detect the first SYN_MT_SLOT and select parser based on that information.

>> +
>> +Protocol Example B
>> +------------------
>> +
>> +Here is what a minimal event sequence for a two-contact touch would look
>> +like for a type B device:
>> +
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_TRACKING_ID 45
>> +   ABS_MT_POSITION_X x[0]
>> +   ABS_MT_POSITION_Y y[0]
>> +   SYN_MT_SLOT 1
>> +   ABS_MT_TRACKING_ID 46
>> +   ABS_MT_POSITION_X x[1]
>> +   ABS_MT_POSITION_Y y[1]
>> +   SYN_REPORT
>> +
>> +Here is the sequence after moving contact 45 in the x direction:
>> +
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x[0]
>> +   SYN_REPORT
>> +
>> +Here is the sequence after lifting the contact in slot 0:
>> +
>> +   ABS_MT_TRACKING_ID 0
>> +   SYN_REPORT
>> +
>> +The active slot is already 0, so the SYN_MT_SLOT is omitted.  The message
>> +removes the association of slot 0 with contact 45, thereby destroying
>> +contact 45 and freeing slot 0 to be reused for another contact.
> 
> I'm probably missing something here, but how would a process know which one
> is the active slot if it didn't get the previous event?

I am assuming you are not talking about losing events in the stream, but simply
what information is available at the point of parsing it. The parser (the X
evdev driver for instance) keeps all attributes of all slots, plus a single
variable saying what slot is currently active, i.e, being modified.

If you are thinking of a setup where one program is already hooked up to the
device, and a new one comes in just as the message in question appears on the
wire, it just means the new program will have to spend some time catching up. If
this should ever become a problem, one could possibly add a send-full-state
method to the input layer, to be issued when the new program opens the device. I
doubt this will be needed in practice though, since contacts change all the time.

As a side note, the notion of a used slot depends on how the attributes of the
slot are interpreted. The method described in the document treats an
ABS_MT_TRACKING_ID value outside of the driver-specified value range as an
unused slot.

Cheers,
Henrik

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/