Hi Rafael On Wed, Oct 30, 2013 at 12:28 AM, Rafael Brune <mail@xxxxxxxxx> wrote: > > On Oct 28, 2013, at 5:49 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > >> 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 <mail@xxxxxxxxx> >> Signed-off-by: David Herrmann <dh.herrmann@xxxxxxxxx> > > Tested-by: Rafael Brune <mail@xxxxxxxxx> > >> --- >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
