Hi Alexandre,
So I have no problem with this as an IIO driver, but for devices that
are somewhat 'on the edge' I always like to get a clear answer to the
question: Why not input?
I would also argue that, to actually be 'useful' we would typically need
some representation of the 'mechanicals' that are providing the motion
being measured. Looking at the datasheet this includes, rotating shafts
(side or end on), disk edges and flat surface tracking (mouse like).
That's easy enough to do with the iio in kernel consumer interface. These
are similar to when we handle analog electronic front ends.
I you can, please describe what it is being used for in your application
as that may give us somewhere to start!
+ CC Dmitry and linux-input.
If 1 or 2, I would suggest that you provide absolute position toI can't provide absolute position, only relative. Do you mean using input driver to do that ? If not, how is built the position data?
Linux. So add the value to a software counter and provide that.
32 bits should be plenty of resolution for that.
Silly question for you. What happens if you set the delta values to 0?
Do we get an interrupt which is effectively data ready?
If we do, you might want to think about a scheme where that is an option.
As things currently stand we have a confusing interface where changing this
threshold effects the buffered data output. That should only be the
case if this interface is for a trigger, not an event.
If it is actually not possible to report the two channels separatelyI found a way to keep the consistency between delta x and delta y (without losing data). The first part is to reset a value only when user read it (also when it's buffered). The second part is to add the new value to the old value. With these two mechanism, X and Y will always be consistent:
then don't report them at all except via the buffered interface and
set the available scan masks so that both are on.