[PATCH/RFC] Change accelerometers to use ABS events rather than REL events.
neilb at suse.de
Tue Mar 10 00:20:32 CET 2009
On Monday March 9, andy at openmoko.com wrote:
> The downside for me is I will get "current andy-tracking broke
> accelerometers again, 2.6.24 rocks, Qi ate my dog", etc.
Yes, that is a definite issue. I'll post something on -devel to
hopefully get some apps fixes.
> | 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
Now that is interesting...
I don't think it will affect my plans much as it is easy to tell from
the various status registers what caused the interrupt, I don't need
two different service routines or anything like that.
Does this have anything to do with the fact that the driver seems to
like enabling both interrupts at one. e.g.
__lis302dl_int_mode(lis->dev, 1, LIS302DL_INTMODE_FF_WU_12);
__lis302dl_int_mode(lis->dev, 2, LIS302DL_INTMODE_FF_WU_12);
This will presumably ensure that the two interrupt lines go high/low
at the same time. Is that important? I don't think it can be
important on the A6/A7, and my limit understanding for signal levels
suggest that it probably isn't important for that A5.
If it is important, we should probably fix __enable_wakeup as it
currently only enables interrupt 1, not 2.
Either way, we should probably document this in the code, which I will
offer a patch for once I have a more complete understanding.
> | We really should introduce some udev rules to create links from
> | 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.
Be careful, it might be a boomerang!
> 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.
More information about the openmoko-kernel