-----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-----
