From: Henrik Rydberg <rydberg@euromail.se>
To: Pavel Machek <pavel@ucw.cz>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Mika Kuoppala <mika.kuoppala@nokia.com>,
Peter Hutterer <peter.hutterer@who-t.net>,
Benjamin Tissoires <tissoire@cena.fr>,
Stephane Chatty <chatty@enac.fr>,
Rafi Rubin <rafi@seas.upenn.edu>,
Michael Poole <mdpoole@troilus.org>
Subject: Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev4)
Date: Thu, 10 Jun 2010 18:28:32 +0200 [thread overview]
Message-ID: <4C1112B0.8070806@euromail.se> (raw)
In-Reply-To: <20100610135634.GD4514@ucw.cz>
Pavel Machek wrote:
> Hi!
>
>> +Protocol Example A
>> +------------------
>> +
>> +Here is what a minimal event sequence for a two-contact touch would look
>> +like for a type A device:
>> +
>> + ABS_MT_POSITION_X x[0]
>> + ABS_MT_POSITION_Y y[0]
>> + SYN_MT_REPORT
>> + ABS_MT_POSITION_X x[1]
>> + ABS_MT_POSITION_Y y[1]
>> + SYN_MT_REPORT
>> + SYN_REPORT
> ...
>> -Usage
>> ------
>> +Here is the sequence after lifting the first contact:
>> +
>> + ABS_MT_POSITION_X x[1]
>> + ABS_MT_POSITION_Y y[1]
>> + SYN_MT_REPORT
>> + SYN_REPORT
>
> ...
>
>> +Protocol Example B
>> +------------------
>> +
>> +Here is what a minimal event sequence for a two-contact touch would look
>> +like for a type B device:
>> +
>> + ABS_MT_SLOT 0
>> + ABS_MT_TRACKING_ID 45
>> + ABS_MT_POSITION_X x[0]
>> + ABS_MT_POSITION_Y y[0]
>> + ABS_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:
>> +
>> + ABS_MT_SLOT 0
>> + ABS_MT_POSITION_X x[0]
>> + SYN_REPORT
>
> With this proposed system, protocol A is *very* different from
> protocol B. Is there way to make them more similar?
Hello,
unfortunately, the two protocols are different for a reason. Given the point of
the type B protocol, to reduce bandwidth and accommodate filtering in the input
core, the major difference is that type A receivers always expect all data
between synchronizations, whereas type B devices never send all data. This alone
means a receiver wishing to support both type of streams will need to know what
type of stream to expect. This is accomplished by the presence of ABS_MT_SLOT.
Secondly, in order to not break the established semantics of events, ABS_MT_SLOT
is used instead SYN_MT_REPORT. This also makes type B devices in type A
applications stop working in a somewhat graceful fashion.
The usage of SYN_MT_REPORT versus ABS_MT_SLOT is the only syntactic difference
between the protocols, and it stems from the different interpretation of what
comes through the wire. IMHO, it means the way the type B protocol is formulated
is the smallest possible change that accommodates the required effect.
Thanks,
Henrik
next prev parent reply other threads:[~2010-06-10 16:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-22 22:30 [PATCH 1/2] input: mt: Introduce MT event slots (rev 5) Henrik Rydberg
2010-05-22 22:30 ` [PATCH 2/2] input: mt: Document the MT event slot protocol (rev4) Henrik Rydberg
2010-05-23 6:52 ` Ping Cheng
2010-05-23 6:52 ` Ping Cheng
2010-05-23 9:20 ` Henrik Rydberg
2010-05-23 9:20 ` Henrik Rydberg
2010-05-23 17:24 ` Randy Dunlap
2010-05-23 22:27 ` Henrik Rydberg
2010-05-23 23:46 ` Randy Dunlap
2010-05-23 23:47 ` Ping Cheng
2010-05-24 7:13 ` Henrik Rydberg
2010-05-24 17:01 ` Ping Cheng
2010-05-24 18:02 ` Henrik Rydberg
2010-05-24 18:13 ` Dmitry Torokhov
2010-05-24 18:31 ` Henrik Rydberg
2010-05-25 16:33 ` Ping Cheng
2010-05-25 16:33 ` Ping Cheng
2010-06-10 13:56 ` Pavel Machek
2010-06-10 16:28 ` Henrik Rydberg [this message]
2010-06-10 14:15 ` [PATCH 1/2] input: mt: Introduce MT event slots (rev 5) Chase Douglas
2010-06-15 4:59 ` Rafi Rubin
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=4C1112B0.8070806@euromail.se \
--to=rydberg@euromail.se \
--cc=akpm@linux-foundation.org \
--cc=chatty@enac.fr \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdpoole@troilus.org \
--cc=mika.kuoppala@nokia.com \
--cc=pavel@ucw.cz \
--cc=peter.hutterer@who-t.net \
--cc=rafi@seas.upenn.edu \
--cc=tissoire@cena.fr \
/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.