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

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

[Lars-Peter Clausen]

Adding V4L folks to Cc for more input.

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.
>
> - 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.
>
> 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.
>
> Thanks,
> Teodora
>
> [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
>>>
>>> Teodora Baluta (3):
>>>    iio: core: add support for fingerprint devices
>>>    iio: core: change channel's storagebits/realbits to u32
>>>    iio: fingerprint: add fingerprint sensor via USB
>>>
>>>   Documentation/ABI/testing/sysfs-bus-iio |  51 +++
>>>   drivers/iio/Kconfig                     |   1 +
>>>   drivers/iio/Makefile                    |   1 +
>>>   drivers/iio/fingerprint/Kconfig         |  15 +
>>>   drivers/iio/fingerprint/Makefile        |   5 +
>>>   drivers/iio/fingerprint/fp_tc.c         | 162 +++++++++
>>>   drivers/iio/fingerprint/fp_tc.h         |  22 ++
>>>   drivers/iio/fingerprint/fp_tc_usb.c     | 618 ++++++++++++++++++++++++++++++++
>>>   drivers/iio/fingerprint/fp_tc_usb.h     | 144 ++++++++
>>>   drivers/iio/industrialio-core.c         |   9 +
>>>   include/linux/iio/iio.h                 |  11 +-
>>>   include/linux/iio/types.h               |  10 +
>>>   12 files changed, 1047 insertions(+), 2 deletions(-)
>>>   create mode 100644 drivers/iio/fingerprint/Kconfig
>>>   create mode 100644 drivers/iio/fingerprint/Makefile
>>>   create mode 100644 drivers/iio/fingerprint/fp_tc.c
>>>   create mode 100644 drivers/iio/fingerprint/fp_tc.h
>>>   create mode 100644 drivers/iio/fingerprint/fp_tc_usb.c
>>>   create mode 100644 drivers/iio/fingerprint/fp_tc_usb.h
>>>
>>
>
> N�����r��y���b�X��ǧv�^�)޺{.n�+����{��*"��^n�r���z�\x1a��h����&��\x1e�G���h�\x03(�階�ݢj"��\x1a�^[m�����z�ޖ���f���h���~�mml==
>

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

[Jonathan Cameron]

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!
>>
>> - 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.
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.
Sure - what you proposed would work.  The question is whether it is
the best way to do it.


>>
>> Thanks,
>> Teodora
>>
>> [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
>>>>
>>>> Teodora Baluta (3):
>>>>    iio: core: add support for fingerprint devices
>>>>    iio: core: change channel's storagebits/realbits to u32
>>>>    iio: fingerprint: add fingerprint sensor via USB
>>>>
>>>>   Documentation/ABI/testing/sysfs-bus-iio |  51 +++
>>>>   drivers/iio/Kconfig                     |   1 +
>>>>   drivers/iio/Makefile                    |   1 +
>>>>   drivers/iio/fingerprint/Kconfig         |  15 +
>>>>   drivers/iio/fingerprint/Makefile        |   5 +
>>>>   drivers/iio/fingerprint/fp_tc.c         | 162 +++++++++
>>>>   drivers/iio/fingerprint/fp_tc.h         |  22 ++
>>>>   drivers/iio/fingerprint/fp_tc_usb.c     | 618 ++++++++++++++++++++++++++++++++
>>>>   drivers/iio/fingerprint/fp_tc_usb.h     | 144 ++++++++
>>>>   drivers/iio/industrialio-core.c         |   9 +
>>>>   include/linux/iio/iio.h                 |  11 +-
>>>>   include/linux/iio/types.h               |  10 +
>>>>   12 files changed, 1047 insertions(+), 2 deletions(-)
>>>>   create mode 100644 drivers/iio/fingerprint/Kconfig
>>>>   create mode 100644 drivers/iio/fingerprint/Makefile
>>>>   create mode 100644 drivers/iio/fingerprint/fp_tc.c
>>>>   create mode 100644 drivers/iio/fingerprint/fp_tc.h
>>>>   create mode 100644 drivers/iio/fingerprint/fp_tc_usb.c
>>>>   create mode 100644 drivers/iio/fingerprint/fp_tc_usb.h
>>>>
>>>
>>
>> N�����r��y���b�X��ǧv�^�)޺{.n�+����{��*"��^n�r���z�\x1a��h����&��\x1e�G���h�\x03(�階�ݢj"��\x1a�^[m�����z�ޖ���f���h���~�mml==
>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Baluta, Teodora]

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!
> >>
> >> - 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.
> 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.
> 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?

Thanks,
Teodora

> 
> 
> >>
> >> Thanks,
> >> Teodora
> >>
> >> [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
> >>>>
> >>>> Teodora Baluta (3):
> >>>>    iio: core: add support for fingerprint devices
> >>>>    iio: core: change channel's storagebits/realbits to u32
> >>>>    iio: fingerprint: add fingerprint sensor via USB
> >>>>
> >>>>   Documentation/ABI/testing/sysfs-bus-iio |  51 +++
> >>>>   drivers/iio/Kconfig                     |   1 +
> >>>>   drivers/iio/Makefile                    |   1 +
> >>>>   drivers/iio/fingerprint/Kconfig         |  15 +
> >>>>   drivers/iio/fingerprint/Makefile        |   5 +
> >>>>   drivers/iio/fingerprint/fp_tc.c         | 162 +++++++++
> >>>>   drivers/iio/fingerprint/fp_tc.h         |  22 ++
> >>>>   drivers/iio/fingerprint/fp_tc_usb.c     | 618 ++++++++++++++++++++++++++++++++
> >>>>   drivers/iio/fingerprint/fp_tc_usb.h     | 144 ++++++++
> >>>>   drivers/iio/industrialio-core.c         |   9 +
> >>>>   include/linux/iio/iio.h                 |  11 +-
> >>>>   include/linux/iio/types.h               |  10 +
> >>>>   12 files changed, 1047 insertions(+), 2 deletions(-)
> >>>>   create mode 100644 drivers/iio/fingerprint/Kconfig
> >>>>   create mode 100644 drivers/iio/fingerprint/Makefile
> >>>>   create mode 100644 drivers/iio/fingerprint/fp_tc.c
> >>>>   create mode 100644 drivers/iio/fingerprint/fp_tc.h
> >>>>   create mode 100644 drivers/iio/fingerprint/fp_tc_usb.c
> >>>>   create mode 100644 drivers/iio/fingerprint/fp_tc_usb.h
> >>>>
> >>>
> >>
> >> N�����r��y���b�X��ǧv�^�)޺{.n�+����{��*"��^n�r���z�\x1a��h����&��\x1e�G���h�\x03(�階�ݢj"��\x1a�^[m�����z�ޖ���f���h���~�mml==
> >>
> > 
> > -- 
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Sylwester Nawrocki]

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

>>>> - 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.

>> 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

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@vger.kernel.org [mailto:linux-iio-
> owner@vger.kernel.org] 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@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

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

[Florian Echtler]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

Hello Teodora,

On 23.01.2015 14:05, Baluta, Teodora wrote:
> 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?
Sorry if I jump in here right in the middle of this discussion, but some
time ago, I wrote a fingerprint sensor driver for the Siemens ID Mouse
(still part of the kernel AFAICT) which acts as a misc device and just
creates a character device node that can be used to directly read a PGM
file.

Maybe this would be a slightly simpler approach than pulling in all the
streaming-optimized features of V4L2?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Baluta, Teodora]

Hi Florian,

Thanks for the reply!

On Vi, 2015-01-23 at 17:46 +0100, Florian Echtler wrote:
> Hello Teodora,
> 
> On 23.01.2015 14:05, Baluta, Teodora wrote:
> > 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?
> Sorry if I jump in here right in the middle of this discussion, but some
> time ago, I wrote a fingerprint sensor driver for the Siemens ID Mouse
> (still part of the kernel AFAICT) which acts as a misc device and just
> creates a character device node that can be used to directly read a PGM
> file.

I agree that it would be the simplest approach if you want a USB
fingerprint driver in kernel space, but I was looking for a way to
support fingerprint devices regardless of bus (there's also fingerprint
devices that use SPI) and provide a common interface for user space
applications.

The actual driver for UPEK's TouchChip sensor is just a proof of concept
on how the interface would work, rather than the final goal. There's
already a library that enables USB-only fingerprint devices (libfprint).
> 
> Maybe this would be a slightly simpler approach than pulling in all the
> streaming-optimized features of V4L2?

I agree that for a fingerprint device, the V4L2 subsystem offers too
much (the initial RFC is for IIO).

Thanks,
Teodora

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

[Sylwester Nawrocki]

Hi,

On 23/01/15 14:05, Baluta, Teodora wrote:
...
>>>>>>> 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?

I don't think a new capability is needed for just one buffer capture.
The capture driver could just support read() and signal it by setting the
V4L2_CAP_READWRITE capability flag [2], [3].

[2]
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html#device-capabilities
[3] http://linuxtv.org/downloads/v4l-dvb-apis/io.html#rw

--
Regards,
Sylwester