linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chase Douglas <chase.douglas@canonical.com>
To: Henrik Rydberg <rydberg@euromail.se>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Jiri Kosina <jkosina@suse.cz>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] input: mt: Interface and MT_TOOL documentation updates
Date: Mon, 13 Dec 2010 09:46:06 -0800	[thread overview]
Message-ID: <4D065BDE.5020107@canonical.com> (raw)
In-Reply-To: <1292001842-5000-1-git-send-email-rydberg@euromail.se>

On 12/10/2010 09:24 AM, Henrik Rydberg wrote:
> +- The MT_TOOL_ENVELOPE type is used to indicate that the contact position
> +is not well-defined, and is only used for legacy hardware. The real contact
> +positions are to be found within the bounding rectangle formed by the
> +envelope contact positions.

By definition, this only covers rectangles with two coordinates to
define the shape and location. Why do we want to call it envelope? It's
just extra confusion to me. Why not call it MT_TOOL_RECT?

Please describe how to use this tool type. Its usage is different than
any tool type usage before, so an explanation would be helpful. Must the
value of the tool on the first touch be 0 until a second touch can
define the rect? Or, can touches always default the value to 1 since
we're talking about devices that only support two fingers?

If this is really to remedy only poor two finger devices, would it be
better to flag the device itself somehow to say "don't trust this
device's coordinate positions" (or something more elegant)? This would
prevent an extrapolation of tool types to multiple fingers at a time.

Lastly, using tool types for this seems odd since this does not signify
a physical tool. It merely signifies that the device coordinates cannot
be trusted literally. Maybe we should use some other namespace for
binding information across multiple touches, like MT_BIND_RECT?

-- Chase

  parent reply	other threads:[~2010-12-13 17:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-10 17:24 [PATCH v2] input: mt: Interface and MT_TOOL documentation updates Henrik Rydberg
2010-12-10 17:36 ` Dmitry Torokhov
2010-12-10 17:41   ` Henrik Rydberg
2010-12-10 17:42     ` Ping Cheng
2010-12-10 17:47       ` Henrik Rydberg
2010-12-14  3:53         ` Peter Hutterer
2010-12-13 17:46 ` Chase Douglas [this message]
2010-12-13 21:21   ` Henrik Rydberg
2010-12-13 23:02     ` Chase Douglas
2010-12-13 23:25       ` Henrik Rydberg
2010-12-14  4:36         ` Peter Hutterer
2010-12-14  9:10           ` Henrik Rydberg
2010-12-20  8:17             ` Peter Hutterer
2010-12-14 14:33           ` Chris Bagwell
2010-12-14 15:02       ` Chris Bagwell

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=4D065BDE.5020107@canonical.com \
    --to=chase.douglas@canonical.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).