public inbox for linux-kernel@vger.kernel.org
 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>,
	JJ Ding <jj_ding@emc.com.tw>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	Seth Forshee <seth.forshee@canonical.com>,
	Aaron Huang <aaron_huang@emc.com.tw>,
	Tom Lin <tom_lin@emc.com.tw>, Eric Piel <E.A.B.Piel@tudelft.nl>,
	Daniel Kurtz <djkurtz@chromium.org>,
	Alessandro Rubini <rubini@cvml.unipv.it>
Subject: Re: [PATCH 2/6] Input: elantech - use firmware provided x, y ranges
Date: Tue, 06 Sep 2011 11:58:30 -0700	[thread overview]
Message-ID: <4E666D56.1020009@canonical.com> (raw)
In-Reply-To: <20110906184735.GA3433@polaris.bitmath.org>

On 09/06/2011 11:47 AM, Henrik Rydberg wrote:
>>>> I see that the current code scales the coordinates for v2, but it's only
>>>> half-resolution. That's not a huge deal since the resolution of modern
>>>> touchpads is very high. We could leave it scaled to not break abi, if
>>>> that was a concern. However, with new devices it makes sense to state
>>>> the ranges in terms of what the device actually supports. Otherwise,
>>>> we're just masking out useful data that userspace could be using.
>>>>
>>>
>>> I disagree. I believe that ST and MT ranges reported for the same
>>> working surface should match, especially since many devices derive ST
>>> data from MT.
>>>
>>> As far as devices that have ranges 0-15 in MT mode - I am not sure how
>>> useful such MT steam anyway and if we are better of just ignore them
>>> (maybe just use the data to report number of fingers on the surface but
>>> otherwise use standard ST protocol).
>>
>> The MT data could still be useful for pinch to zoom or potentially
>> rotate (though most low res devices probably are only semi-mt). I don't
>> want to forsake pinch to zoom just because we can't pass on the
>> resolution of MT data properly.
> 
> We are not forsaking anything. At best, the detail missed out by using
> the same scaling for ST and MT is the ability to distinguish the axis
> with the best or poorest resolution. However, some devices report
> higher MT than ST resolution, not because it is better (it is indeed
> worse), but simply to not lose bits in the filtering process. In other
> words: the logic is not without corner cases, and it only makes a
> difference to the transitional devices that are not fully MT
> capable. If this really was a concern, userspace could use the ST
> coordinates for some transformations instead.

So what do we want userspace to do? In the absence of supplying this
information we need to provide guidelines. We could say:

* Always use ST coords + finger count for drag gestures (i.e. scrolling)
* Use MT coords for pinch and rotate

If this is acceptable, we should add it to the documentation. Thoughts?

-- Chase

  reply	other threads:[~2011-09-06 18:58 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-18  1:57 [PATCH 0/6] elantech: add support for newer generation hardware JJ Ding
2011-08-18  1:57 ` [PATCH 1/6] Input: elantech - correct x, y value range for v2 hardware JJ Ding
2011-08-19 12:20   ` Éric Piel
2011-08-18  1:57 ` [PATCH 2/6] Input: elantech - use firmware provided x, y ranges JJ Ding
2011-08-18  2:44   ` Daniel Kurtz
2011-08-18  7:47   ` Dmitry Torokhov
2011-08-19  9:47     ` JJ Ding
2011-08-19 12:19       ` Éric Piel
2011-09-01 18:26     ` Chase Douglas
2011-09-05  3:22       ` JJ Ding
2011-09-06 17:03         ` Chase Douglas
2011-09-06 17:36           ` Dmitry Torokhov
2011-09-06 18:05             ` Chase Douglas
2011-09-06 18:20               ` Dmitry Torokhov
2011-09-06 19:29                 ` Chase Douglas
2011-09-07  2:33                   ` Daniel Kurtz
2011-09-06 18:47               ` Henrik Rydberg
2011-09-06 18:58                 ` Chase Douglas [this message]
2011-08-18  1:57 ` [PATCH 3/6] Input: elantech - packet checking for v2 hardware JJ Ding
2011-08-18  2:49   ` Daniel Kurtz
2011-08-18  6:38   ` Dmitry Torokhov
2011-08-18  7:31     ` JJ Ding
2011-08-18  7:52       ` Dmitry Torokhov
2011-08-18  8:06         ` JJ Ding
2011-08-19 12:22   ` Éric Piel
2011-08-18  1:57 ` [PATCH 4/6] Input: elantech - work around EC buffer JJ Ding
2011-08-18  2:50   ` Daniel Kurtz
2011-08-18  3:07   ` Wanlong Gao
2011-08-18  6:48     ` JJ Ding
2011-08-18  6:54       ` Wanlong Gao
2011-08-18  6:39   ` Dmitry Torokhov
2011-08-18  6:54     ` JJ Ding
2011-08-18  1:57 ` [PATCH 5/6] Input: elantech - clean up elantech_init JJ Ding
2011-08-18  3:04   ` Daniel Kurtz
2011-08-18  3:08     ` Wanlong Gao
2011-08-18  5:35       ` JJ Ding
2011-08-18  5:38         ` Wanlong Gao
2011-08-18  6:00         ` Dmitry Torokhov
2011-08-18  7:44           ` JJ Ding
2011-08-18  6:34   ` Wanlong Gao
2011-08-19 12:29   ` Éric Piel
2011-08-18  1:57 ` [PATCH 6/6] Input: elantech - add v3 hardware support JJ Ding
2011-08-18  2:57   ` Daniel Kurtz
2011-08-18  3:04     ` Wanlong Gao
2011-08-18  3:09       ` Daniel Kurtz
2011-08-18  3:22         ` Wanlong Gao
2011-08-18  5:39     ` JJ Ding
2011-08-18  3:01   ` Wanlong Gao
2011-08-18  5:26     ` JJ Ding
2011-08-18  5:31       ` Wanlong Gao
2011-08-18  5:34         ` Daniel Kurtz
2011-08-18  5:44           ` Wanlong Gao
2011-08-18  6:01             ` Daniel Kurtz
2011-08-18  6:06               ` Wanlong Gao
2011-08-18  7:49                 ` Tom _Lin
2011-08-18  3:30   ` Wanlong Gao
2011-08-18  3:47     ` Li Zefan
2011-08-18  4:15       ` Wanlong Gao
2011-08-18  6:02         ` Dmitry Torokhov
2011-08-18  6:08           ` Wanlong Gao
2011-08-18 13:58   ` Seth Forshee
2011-08-18 14:25     ` Seth Forshee
2011-08-19  0:15       ` Wanlong Gao
2011-08-19  2:23       ` JJ Ding
2011-08-18 17:39   ` Seth Forshee
2011-08-19  8:29     ` JJ Ding
2011-08-19 12:13       ` Seth Forshee
2011-08-19 12:41         ` Éric Piel
2011-08-19 12:50           ` Seth Forshee
2011-08-19 13:39             ` Éric Piel
2011-08-22  0:55         ` JJ Ding
2011-08-19 13:03   ` Éric Piel
2011-08-22  6:05     ` JJ Ding
2011-08-22  7:20       ` Tom _Lin

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=4E666D56.1020009@canonical.com \
    --to=chase.douglas@canonical.com \
    --cc=E.A.B.Piel@tudelft.nl \
    --cc=aaron_huang@emc.com.tw \
    --cc=djkurtz@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jj_ding@emc.com.tw \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rubini@cvml.unipv.it \
    --cc=rydberg@euromail.se \
    --cc=seth.forshee@canonical.com \
    --cc=tom_lin@emc.com.tw \
    /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