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

Neil Brown 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
> 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.

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.

Thanks!

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

Good luck!

NeilBrown



More information about the openmoko-kernel mailing list