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]
Date:	Thu, 01 Sep 2011 11:26:32 -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 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.

It's trivial to project the MT and ST axes onto each other in userspace.
I suggest we report the real range and resolution of ST and MT axes
independently.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ