On 06/10/14 15:17, Daniel Baluta wrote: > > > On 10/04/2014 04:12 PM, Jonathan Cameron wrote: >> On 02/10/14 14:43, Daniel Baluta wrote: >>> This is to be used by drivers to signal detection of motion. We also >>> add some possible values for motion as IIO events modifiers: >>> * running >>> * jogging >>> * walking >>> * still >>> >>> These values are supported by Frescale's MMA9553 sensor: >>> >>> http://freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf >>> >>> Signed-off-by: Daniel Baluta <daniel.baluta@xxxxxxxxx> >>> Signed-off-by: Irina Tirdea <irina.tirdea@xxxxxxxxx> >> Hmm.. This is the interesting one. >> Not immediately obvious how best to represent this stuff. >>> --- >>> Documentation/ABI/testing/sysfs-bus-iio | 7 +++++++ >>> drivers/iio/industrialio-core.c | 4 ++++ >>> drivers/iio/industrialio-event.c | 1 + >>> include/linux/iio/types.h | 7 ++++++- >>> 4 files changed, 18 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio >>> b/Documentation/ABI/testing/sysfs-bus-iio >>> index d760b02..070346d 100644 >>> --- a/Documentation/ABI/testing/sysfs-bus-iio >>> +++ b/Documentation/ABI/testing/sysfs-bus-iio >>> @@ -808,6 +808,13 @@ Description: >>> number or direction is not specified, applies to all channels of >>> this type. >>> >>> +What: /sys/.../events/in_activity_motion_either_en >>> +KernelVersion: 3.17 >>> +Contact: linux-iio@xxxxxxxxxxxxxxx >>> +Description: >>> + Enables or disables motion detection. Each time motion is detected an >>> + event of this type will be generated. >>> + >> The either bit seems a bit random but I can see there is no particularly obvious >> alternative. > > I wonder if introducing a new IIO_EV_DIR_NONE event direction type would make > sense. In this case the sysfs attribute will drop event direction text from its > name (e.g /sys/.../events/in_activity_motion_en) > >> >> We really need a clean way of representing a multilevel 'state change' like this. >> >> Looking at the event code, I almost wonder if we would be better using the >> direction element for running, walking etc rather than a modifier. > > When pushing events code to userspace the modifier seemed to be the only option. > >> >> Having said that we will probably also get devices where this is polled rather >> than >> event. 'What activity is currently going on?' > > Adding IIO_EV_INFO_VALUE bit, would create an attribute > /sys/.../events/in_activity_motion_either_value that could expose the current > activity going on. > >> If we take that view modifiers make sense as it becomes >> 'Is the user running?' Perhaps even offering a confidence interval, e.g units as >> percentage >> in_activity_running_input 0..100 >> in_activity_walking_input 0..100 >> etc >> >> Then our event becomes a state change event (yup we'll need to add that) >> >> /events/in_activity_walking_rising_en will then cause events when the percentage >> confidence on a state rises above the provided threshold or goes above it >> (default of 50% perhaps on devices which only report one state). >> >> /events/in_activity_walking_falling_en will do the leaving case. > > This is a very nice idea and it will also offer more flexibility. I am not sure > about the use case of confidence interval but using 0 and 100 will do the trick > for us. Sure, feel free to propose something else. We could define a confidence interval that counts as 'we think it is this'. Basically just use values of 0 or 100 when there is no explicit indication of the confidence available. Not sure what you do get ;) > > We will use this interface for implementation of significant motion in Android's > HAL. [1] > > I will experiment more with how IIO attributes work and I will send a v2 > using direction instead of modifier for activity type (running, walking etc). > > >> >> Note these are just some quick initial thoughts on alternative methods. >> I'll want to think on this more and get responses from more interested >> parties! > > Thanks a lot for your time! You are welcome. Funnily enough I rather enjoy trying to think of ways to handle new 'weird' hardware in a consistent fashion :) > > Daniel. > > [1] https://source.android.com/devices/sensors/composite_sensors.html -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
