linux-kernel - Re: [PATCH v2] Input: synaptics

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-next>] [day] [month] [year] [list]

Date:	Fri, 20 Jul 2012 09:25:10 +0200
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Chung-Yih Wang (王崇懿) <cywang@...gle.com>
Cc:	Chase Douglas <chase.douglas@...onical.com>,
	Daniel Kurtz <djkurtz@...omium.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	JJ Ding <dgdunix@...il.com>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Input: synaptics - use firmware data for Cr-48

On Fri, Jul 20, 2012 at 11:14:25AM +0800, Chung-Yih Wang (王崇懿) wrote:
> From our experiments, the assumption of "the slowest corner is the
> stationary finger" is not always true. That is the major reason we want to
> report the firmware data instead of semi-mt.

Oh, but that was precisely the point; the reason it does not hold true
is due to sensor and discretization errors. If we can improve upon
this situation, we get a better model of reality.

> The problem here will be how
> to remove the pulling effect, we measured the pulling effect before and can
> not get a good result as there could be IIR in firmware as well. It seems
> not an easy job to remove the pulling effect cleanly.

Probably a simple filter will work. If the bounding box is moving too
fast for the tracked point to stay in the right corner, the solution
is to use a smaller time step. In practise, keeping the tracked point
as a state in the driver, and updating the bounding box using box ->
(1 - m) box + m box_new. If the tracked point is in the right corner,
let m = 1. If not, choose a smaller m.

> > > * Add a new device property (INVALID_Y_AXIS_CROSSING?) that
> > > describes the exact behavior of this device. I would be ok with this
> > > if everyone else is, but only because proper clickpad behavior
> > > (which I consider very importand) is broken without this knowledge.
> >
> Sounds good to me(but I would rather to have INVALID_CROSSING instead,
> depending on the relative finger positions,  it could still have wrong
> tracking either in X or Y axis crossing)

Propagating information about various sensor defects to userspace
sounds horrid to me. The sooner we can forget about these devices, the
better.

> > > * Leave the device as SEMI_MT, but provide the real locations, and
> > > allow userspace to determine the device vendor/model/etc. If
> > > userspace knows that a specific device behaves in a specific way, it
> > > can do its own quirking handling. Given the specificity of this
> > > behavior to only some devices of one brand, this would be my
> > > suggested resolution to the issue.
> >
> 
> A bit confused here, do you mean we report the real locations instead of
> bounding box the current driver have? I am not quite sure if this will
> affect other existing works in userspace for this semi-mt driver.

I am not entirely opposed to this solution, but I would much rather
see an attempt to improve the bounding box in the driver, since such a
solution could be useful for other devices as well.

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