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.

quoted

quoted

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

quoted

quoted

* 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-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html