[PATCH/RFC] Change accelerometers to use ABS events rather than REL events.
Andy Green
andy at openmoko.com
Mon Mar 9 10:33:52 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Somebody in the thread at some point said:
|> 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.
Unless you stepped off the cliff anyway.
| I definitely think that these values look most like 'absolute' values.
I don't disagree with it, I think you're more right than the current
situation.
| 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.
Yeah but it's overkill changing type of what we report based on highpass
or not I think.
|> 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"
...
| 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 ..
| embarrassing.
|
| Yes, it might cause some pain now. But I think it could cause a lot
| more pain later if it isn't fixed soon.
I can save the planet by taking this patch :-))
The downside for me is I will get "current andy-tracking broke
accelerometers again, 2.6.24 rocks, Qi ate my dog", etc.
| 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.
Accelerometer interrupt routing differs across different PCB revisions.
~ This plan will work out across all GTA02 devices only if waiting for
TAP is mutually exclusive with sampling since some only have one
interrupt line routed, not two.
A5: INT1+INT2 signals shorted and routed to CPU input, 100K pullup
A6+A7: Only INT1 from each routed to CPU input, INT2 NC, no pullup
| 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 :-(
Agreed but I think for the reason above maybe we dodged that particular
bullet this time.
What I've done is taken the patch into andy-tracking and any feedback
about what breaks will be welcome before it goes into stable.
I can't push andy-tracking right now since there's a fight going on with
Ben's recent OHCI changes and 3D7K that needs solving first.
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkm04oAACgkQOjLpvpq7dMpOhACfc7o9UPF4E+MjMdTPBtscHEWg
ROgAniNPndEVWrqPq2swqCn54OgwpKbv
=fxwE
-----END PGP SIGNATURE-----
More information about the openmoko-kernel
mailing list