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

[Andy Green]

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