Hi Rafael

On Wed, Oct 30, 2013 at 12:28 AM, Rafael Brune [off-list ref] wrote:

On Oct 28, 2013, at 5:49 PM, David Herrmann [off-list ref] wrote:

quoted

The analog sticks of the pro-controller might report slightly off values.
To guarantee a uniform setup, we now calibrate analog-stick values during
pro-controller setup.

Unfortunately, the pro-controller fails during normal EEPROM reads and I
couldn't figure out whether there are any calibration values stored on the
device. Therefore, we now use the first values reported by the device (iff
they are not _way_ off, which would indicate movement) to initialize the
calibration values. To allow users to change this calibration data, we
provide a pro_calib sysfs attribute.

We also change the "flat" values so user-space correctly smoothes our
data. It makes slightly off zero-positions less visible while still
guaranteeing highly precise movement reports. Note that the pro controller
reports zero-positions in a quite huge range (at least: -100 to +100).

Reported-by: Rafael Brune <redacted>
Signed-off-by: David Herrmann <redacted>

Tested-by: Rafael Brune <redacted>

quoted

---
Hi Rafael

Could you give this a try? It works for me quite well.

Thanks
David

Hi David,

also for me it works very well. As much as I don’t like the ‘initialize by first
observed values’ approach, with the capability to change the calibration
values from user-space it’s a simple and good solution.
Also I like the changes of the ‘flat’ values.
We should keep our eyes open if other pro- or third-party controllers
exceed the +/- 0x400 range of values more than our ones. But I think
Nintendo does the calibration very similar and therefore that should not
happen.
Great work!

Thanks for testing! I am no big fan of this approach either. However,
it has the advantage that we can adjust the internal handling at any
time without affecting the outside. Problem with the min/max approach
is that it returns garbage until the first real *far* analog-movement.
I was thinking of a more advanced state-machine, but could not come up
with a good approach (neither do I have motivation and time to do some
more thorough research). I am willing to implement any extensions if
some-one has good ideas. But I'd like to see it added to "xwiishow"
first, so I can verify it works well. If it does, we can move it into
the hid-wiimote driver in the kernel.
Furthermore, in case anyone finds out the EEPROM calib-storage, we can
easily adjust the kernel driver to read it from there.

@Jiri: I marked the sysfs-docs as 3.13. If it doesn't make it into the
next merge-window, I can resend it marked as 3.14.

Thanks for the report and testing!
David
--
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