lkml.org 
[lkml]   [2010]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] input: mt: introduce MT event slots
    Michael Poole wrote:
    [...]
    >
    > How would the slot number for a contact be chosen?

    The device driver determines how to use the slots. The driver calls
    input_mt_slot(dev, slot), sends the data for the slot, picks another slot, and
    repeats.

    > If the kernel makes
    > that assignment, what should a "slot" correspond to from a computer
    > user's perspective? "Set[s] of identified sources" is a little vague:
    > Does it mean contacts from one hand, contacts in one displayed window
    > (assuming the touch surface is a screen), or something else? (I assume
    > it would not duplicate the blob or tracking IDs already defined for MT
    > events.)

    The slot is only used for data communication. Think of the slot as a combined,
    unique identifier. For example, imagine a device driver dealing with contacts
    labeled with both a USER_ID and a TRACKING_ID. The driver assigns every active
    (USER_ID, TRACKING_ID) contact to a specific slot, and uses it to communicate
    all changes to that contact. When the contact is destroyed (for instance by
    sending a zero ABS_MT_PRESSURE on that slot), the slot is free to be used for
    another contact.

    > It seems like those would be important aspects of the protocol
    > to document in Documentation/input/multi-touch-protocol.txt --
    > otherwise, driver implementers or application developers might get it
    > wrong.

    Certainly.

    Cheers,
    Henrik



    \
     
     \ /
      Last update: 2010-04-08 11:47    [W:0.023 / U:59.672 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site