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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1515260592.23948.23.camel@intel.com>
Date:   Sat, 6 Jan 2018 17:43:12 +0000
From:   "Pandruvada, Srinivas" <srinivas.pandruvada@...el.com>
To:     "gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
        "jic23@...nel.org" <jic23@...nel.org>
CC:     "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>
Subject: Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor

On Sat, 2018-01-06 at 13:12 +0000, Jonathan Cameron wrote:
> On Sat, 6 Jan 2018 00:20:24 +0000
> Alan Cox <gnomes@...rguk.ukuu.org.uk> wrote:
> 
> > 
> > > 
> > > > 
> > > > From an IIO sensor point of view A Gesture sensor:    
> > > Outputs
> > > 	A pre defined activity type
> > > 		WAKE
> > > 		TILT
> > > 		GLANCE
> > > 		PICK_UP
> > > 		 &
> > > 		 more
> > > 
> > > 	A user defined activity type as "string"
> > > 
> > > Inputs
> > > 	A raw binary cdev interface to download templates/patterns
> > > 
> > > 
> > > I want to gather more opinions before submitting a RFC patch.  
> > The only question I have is should it appear under IIO or should it
> > be an
> > input event interface. It feels to me more like an input device in
> > that in
> > this case while it's not keys or joystick it is still 'please do
> > X'. That
> > might also make it much easier (in the non-Android space in
> > particular)
> > to bind these activities to actions in things like web browsers.
> > 
> I agree that this may well be an option for many of the gestures
> specifically
> metioned (flicks etc and glyphs).
> 
> However, there are other obvious uses of this technology such as step
> detection
> or activity classification (running, walking sitting) that so far
> have fallen
> in the scope of IIO as they aren't really things you expect the
> device to
> perform an an action in response to.  Another one of those messy
> corners
> that fall through the gaps!
> 
> The drivers/iio/accel/mma9553.c does activity detection, but that
> isn't
> really 'events' in the same way as we have here...
> 
> So right answer might be a hybrid of an underlying flexible IIO
> device
> and an input front end for when it makes sense.

What about we can also send an input event, if the event is one of the
input event type which is defined in uapi/linux/input-event-codes.h?


> 
> We probably need to get the in kernel use of IIO events sorted.  Non
> event
> stuff has been sorted for years, but this last corner was never of
> enough
> interest to anyone to actually implement it (it's fairly straight
> forward
> to do).
Currently in IIO event is a u64 value in Fifo. But here we need some
user defined events also. Since this ABI may already may be in use so
can't change u64 to a structure with data type definition and
associated data. But we can define additional predefined ids for custom
events (Similar to HID sensor usage spec added CUSTOM usage ids).

Thanks,
Srinivas

> 
> > 
> > (+ linux-input)
> > 
> > Alan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ