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

quoted

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.

The question was whether we should add those to the long-lived input
interface or not, sorry if that sounded like a rant.

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.

So far, we have provided the baseline of reliable data from similar
devices.

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.

Input properties are not a precious resource, there is no limit on the
bitmask values or anything like that, but there is no rush to add new
ones.

quoted

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.

I am interpreting Chase's suggestion as simply reporting the raw
values instead of min/max.

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.

So it seems there is no need to add logic to the driver, only change
one line from min/max to raw data for this particular hardware. That
would solve your problem, yes?

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.

I understand you are not interested in looking into this, and your
main objective is quite clear.

Thanks,
Henrik