Joerg Reisenweber
Mon, 07 Mar 2011 22:49:31 -0800
>On Wed, Feb 23, 2011 at 06:01:09PM +0100, Michael 'Mickey' Lauer wrote: >> I have applied everything, but wonder a bit about 09/11. The idea of >> the one second timeout was to prevent flooding the system with >> orientation messages while the device was being turned around -- based >> on the assumption that it's confusing when the display starts catching >> up with the orientation while the user obviously hasn't stopped >> messing around with it. > >Initially I found that I never got an orientation changed signal because >of that 1 sec timer. Thinking about it again, it probably kept being >reset due to the lis302 threshold being set too low. > >By raising the lis302 duration, and using a deadzone I didn't see a need >to reduce the number of signals further. But you raise a good point, it >is probably better to wait a bit for the orientation to settle before >sending a signal. Attached is a patch that adds the timeout back. A delay on orientation signal is quite undesirable regarding user experience. Usually application implementations abort the current transition (rotation) as soon as an early new contradicting signal arrives. Of course on accelerometer driver side (here), bouncing (lots of A B A B signals) should be avoided, so the difference between a few raw accelerometer readings should be low enough to make it probable there'll be no orientation change and thus new signal in the next say 50..100ms - or simply put, the rotational speed as seen by accelerometer (the integrated differences of maybe 3 or 4 absolute readings, during 20..100ms) should be low enough so it's likely that the device might stop in this orientation, before a signal is sent. Of course these ideas are based on a setting that exploits LIS302 highpass (to trigger on orientation changes only, except when movement been detected where even polling absolute values is allowable for a short period of time, to analyze the properties of that movement), a low threshold (so you actually notice even small orientation changes), and hw IRQ that avoids polling (unless a movement is about to happen, see before). A smart algorithm in driver or high level handler of FSO might detect noise that doesn't integrate to a real orientation change (like e.g in a moving car), and set threshold (and highpass parameters) of LIS302 so that this noise doesn't create too frequent IRQ handler CPU load. On detection of high frequency noise (constant strong vibration) it *might* even be reasonable or necessary to temporarily switch from highpass to absolute mode. Generally a reaction time / delay of 1 second is _way_ too high. cheers jOERG _______________________________________________ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland