linux-kernel - Re: [PATCH 2/6] Input: elantech - use firmware provided x, y ranges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E6660D7.9040800@canonical.com>
Date:	Tue, 06 Sep 2011 11:05:11 -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 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.

-- 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/