lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 16 Aug 2022 00:03:47 +0530
From:   Jagath Jog J <jagathjog1996@...il.com>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     andy.shevchenko@...il.com, hadess@...ess.net, hdegoede@...hat.com,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] iio: Add new event type gesture and use direction
 for single and double tap

Hi Jonathan,

On Sun, Aug 14, 2022 at 10:24 PM Jonathan Cameron <jic23@...nel.org> wrote:
>
> On Sat, 13 Aug 2022 12:48:02 +0530
> Jagath Jog J <jagathjog1996@...il.com> wrote:
>
> > Add new event type for tap called gesture and the direction can be used
> > to differentiate single and double tap. This may be used by accelerometer
> > sensors to express single and double tap events. For directional tap,
> > modifiers like IIO_MOD_(X/Y/Z) can be used along with singletap and
> > doubletap direction.
> >
> > Signed-off-by: Jagath Jog J <jagathjog1996@...il.com>
> Hi Jagath,
>
> This ABI is definitely something I want more eyes than ours on, so
> whatever happens I'll leave it on the list for a few weeks.

Sure, I will leave KernelVersion blank in the next series.

>
> > ---
> >  Documentation/ABI/testing/sysfs-bus-iio | 41 +++++++++++++++++++++++++
> >  drivers/iio/industrialio-event.c        |  7 ++++-
> >  include/linux/iio/types.h               |  2 ++
> >  include/uapi/linux/iio/types.h          |  3 ++
> >  tools/iio/iio_event_monitor.c           |  8 ++++-
> >  5 files changed, 59 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> > index e81ba6f5e1c8..54cb925f714c 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -2038,3 +2038,44 @@ Description:
> >               Available range for the forced calibration value, expressed as:
> >
> >               - a range specified as "[min step max]"
> > +
> > +What:                /sys/.../events/in_accel_gesture_singletap_en
> > +What:                /sys/.../events/in_accel_gesture_doubletap_en
> > +KernelVersion:       5.21
> > +Contact:     linux-iio@...r.kernel.org
> > +Description:
> > +             Device generates an event on a single or double tap.
> > +
> > +What:                /sys/.../events/in_accel_gesture_singletap_value
> > +What:                /sys/.../events/in_accel_gesture_doubletap_value
> > +KernelVersion:       5.21
> > +Contact:     linux-iio@...r.kernel.org
> > +Description:
> > +             Specifies the threshold value that the device is comparing
> > +             against to generate the tap gesture event. Units and exact
> > +             meaning of value are device specific.
>
> I wonder if we should list a direction?  As in smaller is more sensitive?

Yeah in most of the devices which support tap, this value represents the
threshold, the lower the value higher the tap sensitivity. I will add it to the
description in the next series.

> (at least to first approximation)
Do I need to add available attributes into ABI docs?

> That way a user would at least be able to consistently decide if they should
> raise or lower the number to get the perf the want.
>
> > +
> > +What:                /sys/.../events/in_accel_gesture_singletap_reset_timeout
> > +What:                /sys/.../events/in_accel_gesture_doubletap_reset_timeout
> > +KernelVersion:       5.21
> > +Contact:     linux-iio@...r.kernel.org
> > +Description:
> > +             Specifies the timeout value in seconds for the tap detector
> > +             to not to look for another tap event after the event as
> > +             occoured. Basically the minimum quiet time between the two
> spelling.  occured

Sorry, I will correct this.

Thank you
Jagath

>
> > +             single-tap's or two double-tap's.
> > +
> > +What:                /sys/.../events/in_accel_gesture_doubletap_tap_2min_delay
>
> I'm not sure this naming is intuitive enough. Might be a simple
> as doubletap_tap2_min_delay?  My brain didn't parse 2min correctly.
>
> This one is a bit odd, so definitely want to hear more view points on whether
> this is general enough to cover sensors and intuitive enough that people
> have some hope of setting it right.
>
> > +KernelVersion:       5.21
> > +Contact:     linux-iio@...r.kernel.org
> > +Description:
> > +             Specifies the minimum quiet time in seconds between the two
> > +             taps of a double tap.
> > +
> > +What:                /sys/.../events/in_accel_gesture_maxtomin_time
> > +KernelVersion:       5.21
> > +Contact:     linux-iio@...r.kernel.org
> > +Description:
> > +             Specifies the maximum time difference allowed between upper
> > +             and lower peak of tap to consider it as the valid tap event.
> > +             Units in seconds.
> Needs to be associated with 'tap' in the naming.
> Easiest is probably only to define it as
> singletap_maxtomin_time + doubletap_maxtomin_time and not have the
> shared version as we'd lose the 'tap' part of the name.
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ