Re: [RFC PATCH 3/8] iio: core: Introduce new MOTION event

From: Daniel Baluta
Date: Sat Oct 11 2014 - 05:47:53 EST


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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/