On Fri, Jul 20, 2012 at 3:25 PM, Henrik Rydberg [off-list ref] wrote:

On Fri, Jul 20, 2012 at 11:14:25AM +0800, Chung-Yih Wang (王崇懿) wrote:

quoted

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.

quoted

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

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.

Not providing the userspace driver with enough information to give
users the best experience possible sounds horrid to me.  It turns out
that using a bounding box with fixed "[(min_x, min_y), (max_x,
max_y)]", and no per-finger pressure information, instead of the
coordinates and pressures provided by the firmware, is throwing away
useful data that could be used by the userspace driver.

What we would like is a way to tell userspace what the firmware
originally intended, but with a caveat that the firmware can't be 100%
trusted.  And, since this is for a relatively small class of hardware,
to do it in a way that doesn't consume precious resources, like
additional input properties.

quoted

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.

This is essentially what this patch does.  It sets the SEMI_MT flag to
indicate that the kernel data cannot be totally trusted, and then
provides real MT-B (including per-finger pressures), instead of a
fixed bounding box.  It leaves it to userspace to treat the two slots
worth of coordinates as a bounding box or as actual fingers using its
own heuristics.  By limiting to only one hardware type (using DMI),
any breakage caused by this alternative use of the SEMI_MT flag is
limited.

Hopefully it is clear what we are trying to accomplish.  I don't see
how we can make a bounding box, even an improved bounding box, work.
Perhaps Henrik has a really good idea, but I haven't been able to
figure out what he is suggesting.

Thank you for the nice discussion and alternative suggestions about
better ways of doing this!

-Daniel

quoted

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