From: Henrik Rydberg <rydberg@euromail.se>
To: Michael Poole <mdpoole@troilus.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] input: mt: introduce MT event slots
Date: Thu, 08 Apr 2010 11:43:49 +0200 [thread overview]
Message-ID: <4BBDA555.1020003@euromail.se> (raw)
In-Reply-To: <87tyrmiqw2.fsf@troilus.org>
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
next prev parent reply other threads:[~2010-04-08 9:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-08 0:13 [PATCH] input: mt: introduce MT event slots Henrik Rydberg
2010-04-08 3:07 ` Michael Poole
2010-04-08 9:43 ` Henrik Rydberg [this message]
2010-04-08 11:40 ` Michael Poole
2010-04-08 13:01 ` Henrik Rydberg
2010-04-16 7:40 ` Hennerich, Michael
2010-04-16 14:29 ` Henrik Rydberg
2010-04-08 19:15 ` Rafi Rubin
2010-04-08 20:25 ` Henrik Rydberg
2010-04-08 21:23 ` Rafi Rubin
2010-04-08 22:12 ` Henrik Rydberg
2010-04-15 23:25 ` Dmitry Torokhov
2010-04-16 15:09 ` Henrik Rydberg
2010-05-04 7:57 ` Henrik Rydberg
2010-05-04 17:29 ` Dmitry Torokhov
2010-05-04 21:41 ` Henrik Rydberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BBDA555.1020003@euromail.se \
--to=rydberg@euromail.se \
--cc=akpm@linux-foundation.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdpoole@troilus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.