[PATCH/RFC] Change accelerometers to use ABS events rather than REL events.
neilb at suse.de
Sun Mar 8 23:30:05 CET 2009
On Mon, March 9, 2009 8:36 am, Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 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