All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chase Douglas <chase.douglas@canonical.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Henrik Rydberg <rydberg@euromail.se>,
	Chris Bagwell <chris@cnpbagwell.com>,
	Peter Hutterer <peter.hutterer@who-t.net>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] Alternative approach to MT_TOOL_ENVELOPE
Date: Wed, 15 Dec 2010 12:31:13 -0500	[thread overview]
Message-ID: <4D08FB61.6000404@canonical.com> (raw)
In-Reply-To: <20101215072528.GB11867@core.coreip.homeip.net>

On 12/15/2010 02:25 AM, Dmitry Torokhov wrote:
> On Wed, Dec 15, 2010 at 02:37:54AM +0100, Henrik Rydberg wrote:
>> Hi Chase,
>>
>>>
>>
>>> I gave this some more thought, and I was close to accepting it with
>>> documentation of the above restrictions. Then I thought of how the
>>> following two devices would be presented to userspace:
>>>
>>> 1. A real MT device supporting up to 2 touches (e.g. a bamboo touch)
>>>   - ABS_{X,Y}, BTN_TOUCH, BTN_TOOL_FINGER, and BTN_TOOL_DOUBLETAP for ST
>>>   - ABS_MT_SLOT, ABS_MT_TRACKING_ID, ABS_MT_POSITION_{X,Y}, ABS_MT_TOOL_TYPE
>>>
>>> 2. A partial MT device using MT_TOOL_ENVELOPE (e.g. synaptics MT)
>>>   - ABS_{X,Y}, BTN_TOUCH, BTN_TOOL_FINGER, and BTN_TOOL_DOUBLETAP for ST
>>>   - ABS_MT_SLOT, ABS_MT_TRACKING_ID, ABS_MT_POSITION_{X,Y}, ABS_MT_TOOL_TYPE
>>>
>>> Note that they are identical! The range of values for each axis would be
>>> identical too. The only way to tell the two apart would be to watch for
>>> the ABS_MT_TOOL_TYPE axis.
> 
> Question: does the driver really need to know this data beforehand?  I'd
> expect MT-aware driver simply having handlers for both styles and then
> doing the best it can with the data stream it gets... There should not
> be ambiguity as to what event is - I believe we should be sending
> BTN_TOOL_ENVELOPE even for the single/first contact for devices that do
> not do full MT tracking.

In XI 2.1 with MT, I would envision a partial MT device having different
axis labels. We don't want to push an implementation specific
abstraction, as MT_TOOL_ENVELOPE is, through the X protocol and require
clients to watch the tool type. It should be readily apparent by the
axis labels of the position valuators whether they represent true MT
coordinates or a bounding rectangle of touches.

As for whether clients will want to know if the device is real or
partial MT, I think we should design a protocol that allows for a client
to know. Maybe the application gives visual feedback on how to perform
gestures depending on the device type?

Thanks,

-- Chase

  reply	other threads:[~2010-12-15 17:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-14 21:21 [PATCH 0/4] Alternative approach to MT_TOOL_ENVELOPE Chase Douglas
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
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 [this message]
2010-12-15 20:25           ` Chris Bagwell
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=4D08FB61.6000404@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 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.