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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 6 Sep 2011 20:47:35 +0200
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Chase Douglas <chase.douglas@...onical.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	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>,
	Alessandro Rubini <rubini@...l.unipv.it>
Subject: Re: [PATCH 2/6] Input: elantech - use firmware provided x, y ranges

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

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