Message-ID: <4E66749A.10009@canonical.com>
Date:	Tue, 06 Sep 2011 12:29:30 -0700
From:	Chase Douglas <chase.douglas@...onical.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	JJ Ding <jj_ding@....com.tw>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Seth Forshee <seth.forshee@...onical.com>,
	Aaron Huang <aaron_huang@....com.tw>,
	Tom Lin <tom_lin@....com.tw>,
	Eric Piel <E.A.B.Piel@...elft.nl>,
	Daniel Kurtz <djkurtz@...omium.org>,
	Henrik Rydberg <rydberg@...omail.se>,
	Alessandro Rubini <rubini@...l.unipv.it>
Subject: Re: [PATCH 2/6] Input: elantech - use firmware provided x, y ranges

On 09/06/2011 11:20 AM, Dmitry Torokhov wrote:
> On Tue, Sep 06, 2011 at 11:05:11AM -0700, Chase Douglas wrote:
>> On 09/06/2011 10:36 AM, Dmitry Torokhov wrote:
>>> On Tue, Sep 06, 2011 at 10:03:05AM -0700, Chase Douglas wrote:
>>>> On 09/04/2011 08:22 PM, JJ Ding wrote:
>>>>> Hi Chase,
>>>>>
>>>>> On Thu, 01 Sep 2011 11:26:32 -0700, Chase Douglas <chase.douglas@...onical.com> wrote:
>>>>>> On 08/18/2011 12:47 AM, Dmitry Torokhov wrote:
>>>>>>> On Thu, Aug 18, 2011 at 09:57:05AM +0800, JJ Ding wrote:
>>>>>>>> +
>>>>>>>> +		i = (etd->fw_version > 0x020800 &&
>>>>>>>> +		     etd->fw_version < 0x020900) ? 1 : 2;
>>>>>>>> +		*x_max = (etd->capabilities[1] - i) * 64;
>>>>>>>> +		*y_max = (etd->capabilities[2] - i) * 64;
>>>>>>>> +		*y_2ft_max = (*y_max - i) * 64 / 4;
>>>>>>>
>>>>>>> Hmm, we should have the same range for ST and MT data and scale MT data
>>>>>>> if it has lower resolution to match ST.
>>>>>>
>>>>>> I saw this go by a while back and it made sense to me at the time.
>>>>>> However, I've had some thoughts that give me pause.
>>>>>>
>>>>>> Seth Forshee has been working on getting a semi-mt driver for ALPS
>>>>>> devices. The ALPS devices have an interesting mechanism for providing
>>>>>> multitouch data, but it boils down to having a resolution of only 15
>>>>>> values in the X axis and 11 in the Y axis (it looks possible to
>>>>>> extrapolate and get double the resolution, but my point will remain).
>>>>>>
>>>>>> Let's take the X synaptics module as an example of the repercussions of
>>>>>> in-kernel axis scaling. The X synaptics module translates two touch
>>>>>> drags into scroll events. Synaptics will want to use the highest
>>>>>> resolution axis for generating scroll events. If both the MT and ST axes
>>>>>> have the same resolution, it might pick the MT axes for scrolling. On
>>>>>> ALPS devices with in-kernel axis scaling that would be a bad choice.
>>>>> I don't know about the ALPS devices, but since we already report
>>>>> ABS_MT_POSITION_{X,Y} with elantech v2, we have to do the scaling in
>>>>> kernel anyway to adhere to multitouch protocol. So I would say it is
>>>>> still more appropriate to have the same resolution for ST and MT with
>>>>> respect to elantech v2. Maybe ALPS should be considered an exception to this?
>>>>
>>>> The multitouch protocol doesn't require scaling of axes to match, at
>>>> least not according to the protocol documentation.
>>>>
>>>> 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.
> 
> How would userspace know that MT data should only be used for gestures
> but nothign else? By examining range? What is the "too small range"
> then? It would be different for different devices. I do not want
> userspace portions of the drivers to turn into unmanageble collection of
> quirks.

I wasn't suggesting that it have a big switch that enables or disables
gestures. I just want userspace to be able to figure out whether ST or
MT data would be better for a given task. If the range of the ST and MT
axes could provide this data, then it makes sense to do so. The test
wouldn't be like "is MT range big enough", it would be "is MT range
better than ST or vice versa".

However, Henrik pointed out that some devices report ranges that aren't
representative of how accurate or precise they really are. That
invalidates this approach.

> Some hardware is just hopeless... And pinch to zoom is cute but hardly
> most used function on a laptop (as opposed to phone/tablet), I'd just
> leave it be.

Just because a piece of hardware is imprecise does not mean it is
useless for gestures. Sure, it may not work that great for precision
zooming, but it would be good enough for threshold matching. The Unity
window manager uses these thresholds to fire actions like spread (or
"expose" in OS X terms).

-- Chase
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists