RE: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors

[Baluta, Teodora]

Hi,

Thanks for the reply, Sylwester! I am considering v4l2 now and I have some questions/comments below.

> -----Original Message-----
> From: linux-iio-owner@xxxxxxxxxxxxxxx [mailto:linux-iio-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Sylwester Nawrocki
> Sent: Thursday, January 15, 2015 7:38 PM
> To: Baluta, Teodora; Jonathan Cameron
> Cc: Mauro Carvalho Chehab; Lars-Peter Clausen; Linux Kernel Mailing List;
> linux-iio; LMML; Hans Verkuil
> Subject: Re: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors
> 
> On 14/01/15 18:14, Baluta, Teodora wrote:
> > On Vi, 2014-12-26 at 11:13 +0000, Jonathan Cameron wrote:
> >> On 18/12/14 16:51, Lars-Peter Clausen wrote:
> >>> Adding V4L folks to Cc for more input.
> >>
> >> Thanks Lars - we definitely would need the v4l guys to agree to a
> >> driver like this going in IIO. (not that I'm convinced it should!)
> >>
> >>> On 12/08/2014 03:10 PM, Baluta, Teodora wrote:
> >>>> Hello,
> >>>>
> >>>> On Vi, 2014-12-05 at 02:15 +0000, Jonathan Cameron wrote:
> >>>>> On 04/12/14 13:00, Teodora Baluta wrote:
> >>>>>> This patchset adds support for fingerprint sensors through the IIO
> interface.
> >>>>>> This way userspace applications collect information in a uniform
> >>>>>> way. All processing would be done in the upper layers as suggested
> in [0].
> >>>>>>
> >>>>>> In order to test out this proposal, a minimal implementation for
> >>>>>> UPEK's TouchChip Fingerprint Sensor via USB is also available.
> >>>>>> Although there is an existing implementation in userspace for USB
> >>>>>> fingerprint devices, including this particular device, the driver
> >>>>>> represents a proof of concept of how fingerprint sensors could be
> >>>>>> integrated in the IIO framework regardless of the used bus. For
> >>>>>> lower power requirements, the SPI bus is preferred and a kernel
> driver implementation makes more sense.
> >>>>>
> >>>>> So why not v4l?  These are effectively image sensors..
> >>>>
> >>>> Well, here's why I don't think v4l would be the best option:
> >>>>
> >>>> - an image scanner could be implemented in the v4l subsystem, but
> >>>> it seems far more complicated for a simple fingerprint scanner - it
> >>>> usually has drivers for webcams, TVs or video streaming devices.
> >>>> The v4l subsystem (with all its support for colorspace, decoders,
> >>>> image compression, frame control) seems a bit of an overkill for a
> >>>> very straightforward fingerprint imaging sensor.
> >
> >> Whilst those are there, I would doubt the irrelevant bits would put
> >> much burden on a fingerprint scanning driver.  Been a while since I
> >> did anything in that area though so I could be wrong!
> 
> IMO V4L is much better fit for this kind of devices than IIO. You can use just a
> subset of the API, it shouldn't take much effort to write a simple
> v4l2 capture driver, supporting fixed (probably vendor/chip specific) image
> format.  I'm not sure if it's better to use the v4l2 controls [1], define a new
> v4l2 controls class for the fingerprint scanner processing features, rather than
> trying to pass raw data to user space and interpret it then in some library.  I
> know there has been resistance to allowing passing unknown binary blobs to
> user space, due to possible abuses.
> 
> [1] Documentation/video4linux/v4l2-controls.txt
>
                                                                                                               
The fingerprint sensor acts more like a scanner device, so the closest type is the V4L2_CAP_VIDEO_CAPTURE. However, this is not a perfect match because the driver only sends an image, once, when triggered. Would it be a better alternative to define a new capability type? Or it would be acceptable to simply have a video device with no frame buffer or frame rate and the user space application to read from the character device /dev/videoX?

> >>>> - a fingerprint device could also send out a processed information,
> >>>> not just the image of a fingerprint. This means that the processing
> >>>> is done in hardware - the UPEK TouchStrip chipset in libfprint has
> >>>> this behavior (see [0]). So, the IIO framework would support a
> >>>> uniform way of handling fingerprint devices that either do
> >>>> processing in software or in hardware.
> 
> You can use the v4l2 controls API for that, which also supports events.
> The controls could be made read only.
> It would be interesting to list what kind of features these could be.

Looking through the controls API, they seem to be a good fit.

> 
> >> This is more interesting, but does that map well to IIO style
> >> channels anyway?  If not we are going to end up with a whole new
> >> interface which ever subsystem is used for the image side of things.
> >>>>
> >>>> The way I see it now, for processed fingerprint information, an IIO
> >>>> device could have an IIO_FINGERPRINT channel with a modifier and
> >>>> only the sensitivity threshold attribute set. We would also need
> >>>> two
> >>>> triggers: one for enrollment and one for the verification mode to
> >>>> control the device from a userspace application.
> 
> This could be all well handled with the v4l2 controls, for instance see what
> features are available in the Camera Flash controls subset
> 
> http://linuxtv.org/downloads/v4l-dvb-apis/extended-controls.html#flash-
> controls
> 
> >> Sure - what you proposed would work.  The question is whether it is
> >> the best way to do it.
> >
> > Any thoughts on this from the v4l community?
> 
> I would try it with V4L2, it seems to me most suitable subsystem for such
> devices to me.  The question is what ends up in the kernel and what in user
> space.  Anyway IMO V4L2 API is quite flexible with regards to that, due to
> wide range of devices it needs to cover.
> 
> >>>> [0]
> >>>> http://www.freedesktop.org/wiki/Software/fprint/libfprint/upekts/
> >>>>
> >>>>>> A sysfs trigger is enabled and the device starts scanning. As
> >>>>>> soon as an image is available it is written in the character device
> /dev/iio:deviceX.
> >>>>>>
> >>>>>> Userspace applications will be able to calculate the expected
> >>>>>> image size using the fingerprint attributes height, width and bit
> >>>>>> depth. Other attributes introduced for the fingerprint channel in
> >>>>>> IIO represent information that aids in the fingerprint image
> >>>>>> processing. Besides these, the proposed interface offers
> >>>>>> userspace a way to read a feedback after a scan (like the swipe was
> too slow or too fast) through a modified fingerprint_status channel.
> >>>>>>
> >>>>>> [0] http://www.spinics.net/lists/linux-iio/msg11463.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
N‹§²æ¸›yú²X¬¶ÇvØ–)Þ{.nlj·¥Š{±‘êX§¶›¡Ü}©ž²ÆzÚj:+v‰¨¾«‘êZ+€Êzf£¢·hšˆ§~†­†Ûÿû®w¥¢¸?™¨è&¢)ßf”ùy§m…á«a¶Úÿ0¶ìå