On Thu, Oct 9, 2014 at 10:31 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > 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 :) We have already sent a second proposal :). http://marc.info/?l=linux-iio&m=141285801717857&w=2 We are also hoping to get more opinions from other parties. CC'ing Karol from Samsung :). Daniel. -- 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
