linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chase Douglas <chase.douglas@canonical.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Henrik Rydberg <rydberg@euromail.se>
Cc: Chris Bagwell <chris@cnpbagwell.com>,
	Peter Hutterer <peter.hutterer@who-t.net>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/4] Alternative approach to MT_TOOL_ENVELOPE
Date: Tue, 14 Dec 2010 13:21:08 -0800	[thread overview]
Message-ID: <1292361672-2581-1-git-send-email-chase.douglas@canonical.com> (raw)

Hello all,

I was left somewhat dissatisfied by the MT_TOOL_ENVELOPE addition, so I decided
to try to propose a different solution for the problem. As a recap, the problem
can best be defined by Synaptics hardware that provide two touch coordinates
(X1, Y1) and (X2, Y2). Unfortunately, the real touches may be at (X1, Y2) and
(X2, Y1). Further, three touches may be recognized, but only two coordinates are
reported.

Following this are four patches. The first merely reverts the MT_TOOL_ENVELOPE
addition. The second adds documentation for evdev codes to the Documentation
directory. It was hastily created, so it has some ommissions and may have some
mistakes. My hope is that we keep this or a similar document up to date whenever
non-obvious codes are added to evdev. The third patch adds the following EV_ABS
codes:

ABS_RECT_MIN_X
ABS_RECT_MIN_Y
ABS_RECT_MAX_X
ABS_RECT_MAX_Y

The purpose of these codes is to provide for devices that at best report a
rectangular bounding box of touches. Instead of using the MT evdev protocol,
this approach uses ST protocol semantics.

Finally, the last patch adds support for the above codes to the synaptics
driver.

It is my belief that this is a better interface than MT_TOOL_ENVELOPE for the
following reasons:

* The code meanings are more readily graspable from the names
* The codes behave with ST semantics, which is useful because we likely cannot
  split properties like pressure and orientation among the touches
* ST semantics are easier to comprehend than MT semantics, and MT isn't required
  to solve this problem
* The codes provide only the max and min values, none in between. This is in
  contrast with MT_TOOL_ENVELOPE, which provides all touches as presented by the
  hardware. However, we don't trust all the coordinate pairings, so providing
  faulty pairings may induce incorrect userspace usage of the events.
* A clear distinction is made here that full multitouch devices should use the
  MT protocol, while lesser devices should use the ST protocol.

Thanks!

-- Chase

             reply	other threads:[~2010-12-14 21:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-14 21:21 Chase Douglas [this message]
2010-12-14 21:21 ` [PATCH 1/4] Revert "input: mt: Interface and MT_TOOL documentation updates" Chase Douglas
2010-12-14 21:21 ` [PATCH 2/4] Documentation: Add evdev type and code definitions Chase Douglas
2010-12-15 23:59   ` Peter Hutterer
2010-12-16 14:56     ` Chris Bagwell
2010-12-16 16:57       ` Dmitry Torokhov
2011-01-07 20:39       ` Chase Douglas
2011-01-07 20:34     ` Chase Douglas
2010-12-16 14:12   ` Henrik Rydberg
2011-01-07 20:43     ` Chase Douglas
2010-12-17 10:18   ` Nikolai Kondrashov
2010-12-14 21:21 ` [PATCH 3/4] Input: Add ABS_RECT_* legacy multitouch evdev codes Chase Douglas
2010-12-14 21:21 ` [PATCH 4/4] Input: synaptics - Add support for ABS_RECT_* Chase Douglas
2010-12-14 21:38 ` [PATCH 0/4] Alternative approach to MT_TOOL_ENVELOPE Chase Douglas
2010-12-14 22:12 ` Dmitry Torokhov
2010-12-15  0:21   ` Chase Douglas
2010-12-15  1:37     ` Henrik Rydberg
2010-12-15  7:25       ` Dmitry Torokhov
2010-12-15 17:31         ` Chase Douglas
2010-12-15 20:25           ` Chris Bagwell
  -- strict thread matches above, loose matches on Subject: below --
2010-12-15 10:26 Henrik Rydberg
2010-12-15 17:40 ` Chase Douglas
2010-12-15 19:36   ` Henrik Rydberg
2010-12-15 21:13     ` Chase Douglas
2010-12-16 14:41       ` Henrik Rydberg
2010-12-15 20:41   ` Chris Bagwell
2010-12-15 21:08     ` Chase Douglas
2010-12-16 14:35       ` Henrik Rydberg
2010-12-16  0:19 ` Peter Hutterer

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=1292361672-2581-1-git-send-email-chase.douglas@canonical.com \
    --to=chase.douglas@canonical.com \
    --cc=chris@cnpbagwell.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.hutterer@who-t.net \
    --cc=rydberg@euromail.se \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).