Re: [PATCH v2] Input: synaptics - use firmware data for Cr-48

["Henrik Rydberg" <rydberg@euromail.se>]

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