[PATCH/RFC] Change accelerometers to use ABS events rather than REL events.

NeilBrown neilb at suse.de
Sun Mar 8 23:30:05 CET 2009

On Mon, March 9, 2009 8:36 am, Andy Green wrote:
> Hash: SHA1
> Somebody in the thread at some point said:
> | [Obviously if this patch is accepted we need to tell developers about
> |  it.  I have a number of other improvements to the accelerometers I
> |  hope to deliver over the next couple of weeks.  They will have minimal
> |  or zero disruption to current code. ]
> | -		input_report_rel(lis->input_dev, REL_X, mg_per_sample *
> | +		input_report_abs(lis->input_dev, ABS_X, mg_per_sample *
> | +	set_bit(EV_ABS, lis->input_dev->evbit);
> The accelerations have a relative effect on position, but the
> accelerations themselves are absolute it seems.

Sort of...  Accelerations have a relative effect on speed, which
has a relative effect on position.   But gravity causes an acceleration
to be reported that isn't changing speed at all.
I definitely think that these values look most like 'absolute' values.

The Freerunners accelerometers can be configured to run the signal
through a highpass filter before digitising it.  Then it would be
appropriate to report EV_REL events.  However you would only be
able to measure "jerk" (da/dt) and not orientation, as the effect
of gravity would be filtered away.

> However, changing it would likely break most of the userspace
> accelerometer code for no gain other than correct book-keeping really.
> What's the downside of just leaving these as relative?

1/ It is "wrong"
2/ a value of 0 is never reported for EV_REL. User-space code will either
   need to special case 'REL_X wasn't reported' as meaning 'X-acceleration
   is now zero', or be buggy.  I suspect the latter will be most common,
   though I doubt this will have a big effect on application correctness.
3/ We cannot use the max/min/level settings that EV_ABS provides in order
   to calibrate the accelerometers (note the something generating REL events
   never needs calibration, something generating ABS events could.
   According to the docs the accelerometers does guarantee 100% accuracy
   so calibration might be useful in some circumstances.
4/ We cannot use the 'fuzz' setting of EV_ABS to filter out noise.
5/ One day (hopefully) this driver will go upstream.  You might get it
   in without anyone noticing that it does the wrong thing.  Or someone
   might notice and insist that it doesn't go mainline until it
   generates the right sort of events.  It would be hard to argue against
   that.  The argument "But we have been shipping this broken interface
   to customers" doesn't really cut it upstream.  Their/our position
   is "get it upstream first".
6/ Someday mainline might support other accelerometers.  If some produce
   EV_REL will others report EV_ABS, that would be very confusing.
   Alternately if EV_REL became the standard because Openmoko managed to
   slip in a driver that did the wrong thing, that would be ..

Yes, it might cause some pain now.  But I think it could cause a lot
more pain later if it isn't fixed soon.


 There is another change that I want to make that would break any
 current accelerometer reading application.
 I would like to cause the 'tap' and 'double-tap' recognition to generate
 some sort of 'EV_KEY' events.
 I think it would be much easier to work with these if they came on
 a different event device.  While it is certainly possible to mix
 EV_ABS and EV_KEY in the one device, it is unlikely that one application
 would be interested in both, so if you could just get the EV_KEY without
 being bothered with EV_ABS, that would be good.  And that is best done
 with the new devices.

 That would cause the event devices to get renumbered, so any code that
 assumes that /dev/input/event[23] are the accelerometers would be
 broken.  Similarly the AUX button would almost certainly move off
 We really should introduce some udev rules to create links from meaningful
 names (similar to /dev/touchscreen0 or /dev/ts).  Hardcoding names like
 /dev/input/event* in applications is asking for trouble :-(

More information about the openmoko-kernel mailing list