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

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

[Teodora Baluta]

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.

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

-- 
1.9.1

[RFC PATCH 1/3] iio: core: add support for fingerprint devices

[Teodora Baluta]

This patch introduces the IIO_FINGERPRINT channel which exposes fingerprint sensor
information needed by consumer, attributes for a fingerprint device and
a modifier for the IIO_FINGERPRINT channel. We detail these below.

In order to have a uniform interface, we add the following attributes:
height, width, bit depth, color scheme, orientation, resolution, sensitivity
threshold. These provide information about the image a scanner type device
like a fingerprint sensor produces. Depending on the device, some of these
could be adjusted. For example, setting a lower resolution or a higher
sensitivity threshold.

The sensitivity threshold controls the sensitivy of the finger detection
process. The SW6888[0] sensor and the MBF200[1] sensor have this option.

Add a modifier that enables us to communicate a status code after each scan.
The status codes for a fingerprint device are added in the types.h file.
Devices that are able to send out these status codes are UPEK Eikon 2 and
Validity VFS101 (see [2]). Thus, we have two channels: a modified one
representing the status code and the actual scanned fingerprint data channel.

This patch adds ABI documentation for the attributes a fingerprint
device would have. These attributes describe the image such a sensor
produces. Also, add ABI documentation for the fingerprint channel and
fingerprint status modified channel.

[0] http://ww1.microchip.com/downloads/cn/DeviceDoc/sw6888.pdf
[1]
http://pdf.datasheetcatalog.com/datasheet/FujitsuMicroelectronics/mXsxyvq.pdf
[2]
http://cgit.freedesktop.org/libfprint/libfprint/tree/libfprint/drivers

Signed-off-by: Teodora Baluta <teodora.baluta@intel.com>
---
 Documentation/ABI/testing/sysfs-bus-iio | 51 +++++++++++++++++++++++++++++++++
 drivers/iio/industrialio-core.c         |  9 ++++++
 include/linux/iio/iio.h                 |  7 +++++
 include/linux/iio/types.h               | 10 +++++++
 4 files changed, 77 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 4a9e29a..74d0eed 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1125,3 +1125,54 @@ Contact:	linux-iio@vger.kernel.org
 Description:
 		This attribute is used to read the number of steps taken by the user
 		since the last reboot while activated.
+
+What:		/sys/bus/iio/devices/iio:deviceX/scan_elements/in_fingerprint_en
+KernelVersion:	3.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Activates the fingerprint channel. By activating the channel,
+		the scanned fingerprint can be read from the character device
+		/dev/iio:deviceX.
+
+What:		/sys/bus/iio/devices/iio:deviceX/scan_elements/in_fingerprint_status_en
+KernelVersion:	3.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Activates the fingerprint status modified channel. After
+		activation, a status code representing the scan feedback from
+		the device can be read from the character device
+		/dev/iio:deviceX.
+
+What:		/sys/bus/iio/devices/iio:deviceX/in_fingerprint_scan_height
+What:		/sys/bus/iio/devices/iio:deviceX/in_fingerprint_scan_width
+What:		/sys/bus/iio/devices/iio:deviceX/in_fingerprint_scan_bit_depth
+What:		/sys/bus/iio/devices/iio:deviceX/in_fingerprint_scan_colorscheme
+What:		/sys/bus/iio/devices/iio:deviceX/in_fingerprint_scan_orientation
+What:		/sys/bus/iio/devices/iio:deviceX/in_fingerprint_scan_resolution
+What:		/sys/bus/iio/devices/iio:deviceX/in_fingerprint_sensitivity_threshold
+KernelVersion:	3.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Attributes that describe the output of a fingerprint device.
+		These values are device dependent and should be provided to the
+		upper layer for processing the image.
+
+		The height * width * bit_depth represents the total amount of
+		data the fingerprint channel stores and makes available in the
+		corresponding character device. Here height and width are
+		represented in pixels.
+
+		The colorscheme represents whether the image is black-on-white
+		or white-on-black. We associate the black-on-white with 0 and
+		white-on-black with 1. Similarly, we use 0 for a horizontal
+		orientation and 1 for a vertical orientation.
+
+		The scan_resolution (in ppmm) is a useful metric for processing
+		the fingerprint. The sensor usually has a set resolution, but as
+		with any other scanners this attribute could also be used as a
+		quality setting.
+
+		Lastly, a sensitivity threshold is a way of adjusting
+		sensitivity in the finger detection/scanning.
+		The userspace application should be able to set this value if
+		the device has this capability.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 45bb3a4..f54d22b 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -72,6 +72,7 @@ static const char * const iio_chan_type_name_spec[] = {
 	[IIO_HUMIDITYRELATIVE] = "humidityrelative",
 	[IIO_ACTIVITY] = "activity",
 	[IIO_STEPS] = "steps",
+	[IIO_FINGERPRINT] = "fingerprint",
 };
 
 static const char * const iio_modifier_names[] = {
@@ -97,6 +98,7 @@ static const char * const iio_modifier_names[] = {
 	[IIO_MOD_JOGGING] = "jogging",
 	[IIO_MOD_WALKING] = "walking",
 	[IIO_MOD_STILL] = "still",
+	[IIO_MOD_STATUS] = "status",
 };
 
 /* relies on pairs of these shared then separate */
@@ -121,6 +123,13 @@ static const char * const iio_chan_info_postfix[] = {
 	[IIO_CHAN_INFO_INT_TIME] = "integration_time",
 	[IIO_CHAN_INFO_ENABLE] = "en",
 	[IIO_CHAN_INFO_CALIBHEIGHT] = "calibheight",
+	[IIO_CHAN_INFO_SCAN_HEIGHT] = "scan_height",
+	[IIO_CHAN_INFO_SCAN_WIDTH] = "scan_width",
+	[IIO_CHAN_INFO_SCAN_BIT_DEPTH] = "scan_bit_depth",
+	[IIO_CHAN_INFO_SCAN_COLOR_SCHEME] = "scan_color_scheme",
+	[IIO_CHAN_INFO_SCAN_ORIENTATION] = "scan_orientation",
+	[IIO_CHAN_INFO_SCAN_RESOLUTION] = "scan_resolution",
+	[IIO_CHAN_INFO_SENSITIVITY_THRESHOLD] = "sensitivity_threshold",
 };
 
 /**
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 878d861..e280cfe 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -40,6 +40,13 @@ enum iio_chan_info_enum {
 	IIO_CHAN_INFO_INT_TIME,
 	IIO_CHAN_INFO_ENABLE,
 	IIO_CHAN_INFO_CALIBHEIGHT,
+	IIO_CHAN_INFO_SCAN_HEIGHT,
+	IIO_CHAN_INFO_SCAN_WIDTH,
+	IIO_CHAN_INFO_SCAN_BIT_DEPTH,
+	IIO_CHAN_INFO_SCAN_COLOR_SCHEME,
+	IIO_CHAN_INFO_SCAN_ORIENTATION,
+	IIO_CHAN_INFO_SCAN_RESOLUTION,
+	IIO_CHAN_INFO_SENSITIVITY_THRESHOLD,
 };
 
 enum iio_shared_by {
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index 904dcbb..d0c7cc9 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -32,6 +32,7 @@ enum iio_chan_type {
 	IIO_HUMIDITYRELATIVE,
 	IIO_ACTIVITY,
 	IIO_STEPS,
+	IIO_FINGERPRINT,
 };
 
 enum iio_modifier {
@@ -66,6 +67,7 @@ enum iio_modifier {
 	IIO_MOD_JOGGING,
 	IIO_MOD_WALKING,
 	IIO_MOD_STILL,
+	IIO_MOD_STATUS,
 };
 
 enum iio_event_type {
@@ -91,6 +93,14 @@ enum iio_event_direction {
 	IIO_EV_DIR_NONE,
 };
 
+#define STATUS_UNKNOWN				255
+
+#define STATUS_FINGERPRINT_GOOD			0
+#define STATUS_FINGERPRINT_FAIL			1
+#define STATUS_FINGERPRINT_TOO_SLOW		2
+#define STATUS_FINGERPRINT_TOO_FAST		3
+#define STATUS_FINGERPRINT_CENTER_FINGER	4
+
 #define IIO_VAL_INT 1
 #define IIO_VAL_INT_PLUS_MICRO 2
 #define IIO_VAL_INT_PLUS_NANO 3
-- 
1.9.1

[RFC PATCH 2/3] iio: core: change channel's storagebits/realbits to u32

[Teodora Baluta]

In order to fit a channel that describes a fingerprint scan the u8 range is
not enough. For example, a scan whose height is 384 pixels and whose
width is 144, for a bit depth of 8 bits per pixels, the total bits would
be 384 x 144 x 8 = 442368, well over the u8 maximum 255 value.

Fix that by changing the realbits and storagebits fields in the
iio_chan_spec struct to u32.

Signed-off-by: Teodora Baluta <teodora.baluta@intel.com>
---
 include/linux/iio/iio.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index e280cfe..e34e67c 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -232,8 +232,8 @@ struct iio_chan_spec {
 	int			scan_index;
 	struct {
 		char	sign;
-		u8	realbits;
-		u8	storagebits;
+		u32	realbits;
+		u32	storagebits;
 		u8	shift;
 		u8	repeat;
 		enum iio_endian endianness;
-- 
1.9.1

[RFC PATCH 3/3] iio: fingerprint: add fingerprint sensor via USB

[Teodora Baluta]

Add IIO implementation for the USB Fingerprint TouchChip Coprocessor
from UPEK.

Although there is an existing implementation in userspace for USB
fingerprint devices, this 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.

Add dependency on IIO_SYSFS_TRIGGER that provides support for using
SYSFS as IIO triggers. The purpose of the sysfs trigger is to tell the
device to wait for a finger to scan. After the fingerprint is scanned,
an image is produced by the device (as with any scanner type device).

Unlike other sensors, the output isn't a simple value that changes quite
frequently. It is a one-time or on demand sensor that outputs a larger
amount of data. The approach is to use the character device to present
the scanned image to userspace - which is already available in the IIO
framework.

The USB protocol was derived from libfprint's implementation of this
driver (see upektc_img in [0]), as well as some helper functions.

[0]
http://cgit.freedesktop.org/libfprint/libfprint/tree/libfprint/drivers

Signed-off-by: Teodora Baluta <teodora.baluta@intel.com>
---
 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 +++++++++
 8 files changed, 968 insertions(+)
 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

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 345395e..33ce755 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -77,5 +77,6 @@ endif #IIO_TRIGGER
 source "drivers/iio/pressure/Kconfig"
 source "drivers/iio/proximity/Kconfig"
 source "drivers/iio/temperature/Kconfig"
+source "drivers/iio/fingerprint/Kconfig"
 
 endif # IIO
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..0db9c1f 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -27,3 +27,4 @@ obj-y += pressure/
 obj-y += proximity/
 obj-y += temperature/
 obj-y += trigger/
+obj-y += fingerprint/
diff --git a/drivers/iio/fingerprint/Kconfig b/drivers/iio/fingerprint/Kconfig
new file mode 100644
index 0000000..77e7fc6
--- /dev/null
+++ b/drivers/iio/fingerprint/Kconfig
@@ -0,0 +1,15 @@
+#
+# fingerprint USB sensors
+#
+
+menu "Fingerprint sensors"
+
+config FP_TC
+	tristate "Upek TouchChip Fingerprint Coprocessor USB"
+	select IIO_SYSFS_TRIGGER
+	select IIO_BUFFER
+	select IIO_TRIGGERED_BUFFER
+	help
+		A swipe-type sensor over USB that includes a biometric coprocessor.
+
+endmenu
diff --git a/drivers/iio/fingerprint/Makefile b/drivers/iio/fingerprint/Makefile
new file mode 100644
index 0000000..7b13302
--- /dev/null
+++ b/drivers/iio/fingerprint/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for IIO fingerprint sensors
+#
+
+obj-$(CONFIG_FP_TC)		+= fp_tc.o fp_tc_usb.o
diff --git a/drivers/iio/fingerprint/fp_tc.c b/drivers/iio/fingerprint/fp_tc.c
new file mode 100644
index 0000000..4496ce9
--- /dev/null
+++ b/drivers/iio/fingerprint/fp_tc.c
@@ -0,0 +1,162 @@
+/*
+ * UPEK TouchChip USB Fingerprint sensor driver
+ * Copyright (c) 2014, Intel Corporation.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/irq.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/trigger_consumer.h>
+#include <linux/iio/triggered_buffer.h>
+#include <linux/crc-itu-t.h>
+#include "fp_tc.h"
+
+/*
+ * If the device had a biometric coprocessor (see UPEK TouchStrip)
+ * the channel has IIO_CHAN_INFO_PROCESSED enabled
+ */
+static const struct iio_chan_spec fp_tc_channels[] = {
+	{
+		.type = IIO_FINGERPRINT,
+		.info_mask_separate = BIT(IIO_CHAN_INFO_SCAN_HEIGHT) |
+			BIT(IIO_CHAN_INFO_SCAN_WIDTH) |
+			BIT(IIO_CHAN_INFO_SCAN_BIT_DEPTH) |
+			BIT(IIO_CHAN_INFO_SCAN_ORIENTATION) |
+			BIT(IIO_CHAN_INFO_SCAN_COLOR_SCHEME),
+		.scan_index = 1,
+		.scan_type = {
+			.sign = 'u',
+			.realbits = FP_TC_SCAN_HEIGHT * FP_TC_SCAN_WIDTH *
+				FP_TC_SCAN_BIT_DEPTH,
+			.storagebits = FP_TC_SCAN_HEIGHT * FP_TC_SCAN_WIDTH *
+				FP_TC_SCAN_BIT_DEPTH,
+		},
+	},
+	{
+		.type = IIO_FINGERPRINT,
+		.modified = 1,
+		.scan_index = 0,
+		.channel2 = IIO_MOD_STATUS,
+		.scan_type = {
+			.sign = 'u',
+			.realbits = 8,
+			.storagebits = 8,
+		},
+	},
+	IIO_CHAN_SOFT_TIMESTAMP(2),
+};
+
+static int fp_tc_read_raw(struct iio_dev *indio_dev,
+			  const struct iio_chan_spec *chan,
+			  int *val, int *val2, long mask)
+{
+	*val2 = 0;
+	switch (chan->type) {
+	case IIO_FINGERPRINT:
+		switch (mask) {
+		case IIO_CHAN_INFO_SCAN_HEIGHT:
+			*val = FP_TC_SCAN_HEIGHT;
+			return IIO_VAL_INT;
+		case IIO_CHAN_INFO_SCAN_WIDTH:
+			*val = FP_TC_SCAN_WIDTH;
+			return IIO_VAL_INT;
+		case IIO_CHAN_INFO_SCAN_BIT_DEPTH:
+			*val = FP_TC_SCAN_BIT_DEPTH;
+			return IIO_VAL_INT;
+		case IIO_CHAN_INFO_SCAN_ORIENTATION:
+			*val = FP_TC_SCAN_ORIENTATION;
+			return IIO_VAL_INT;
+		case IIO_CHAN_INFO_SCAN_COLOR_SCHEME:
+			*val = FP_TC_SCAN_COLOR_SCHEME;
+			return IIO_VAL_INT;
+		default:
+			return -EINVAL;
+		}
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct iio_info fp_tc_info = {
+	.read_raw		= &fp_tc_read_raw,
+	.driver_module		= THIS_MODULE,
+};
+
+static irqreturn_t fp_tc_buffer_handler(int irq, void *p)
+{
+	struct iio_poll_func *pf = p;
+	struct iio_dev *indio_dev = pf->indio_dev;
+	struct fp_tc_data *data;
+	u8 *image;
+	int retval;
+
+	image = kzalloc(FP_TC_SCAN_HEIGHT * FP_TC_SCAN_WIDTH + 1, GFP_KERNEL);
+	if (!image)
+		return -ENOMEM;
+
+	data = iio_priv(indio_dev);
+
+	retval = data->fp_tc_get_data(indio_dev, image + 1);
+	memcpy(image, &data->scan_result, 1);
+
+	iio_push_to_buffers_with_timestamp(indio_dev, image,
+					   iio_get_time_ns());
+
+	iio_trigger_notify_done(indio_dev->trig);
+
+	kfree(image);
+
+	if (retval < 0)
+		return retval;
+	return IRQ_HANDLED;
+}
+
+int fp_tc_init_iio(struct iio_dev *indio_dev)
+{
+	int ret;
+
+	indio_dev->channels = fp_tc_channels;
+	indio_dev->num_channels = ARRAY_SIZE(fp_tc_channels);
+	indio_dev->info = &fp_tc_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+
+	/* no interrupts for this trigger */
+	ret = iio_triggered_buffer_setup(indio_dev,
+					 NULL,
+					 &fp_tc_buffer_handler,
+					 NULL);
+	if (ret < 0) {
+		dev_err(&indio_dev->dev, "Unable to setup triggered buffer\n");
+		return ret;
+	}
+
+	ret = iio_device_register(indio_dev);
+	if (ret < 0) {
+		dev_err(&indio_dev->dev, "Unable to register iio device\n");
+		iio_triggered_buffer_cleanup(indio_dev);
+		return ret;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(fp_tc_init_iio);
+
+void fp_tc_remove_iio(struct iio_dev *indio_dev)
+{
+	iio_device_unregister(indio_dev);
+}
+EXPORT_SYMBOL(fp_tc_remove_iio);
diff --git a/drivers/iio/fingerprint/fp_tc.h b/drivers/iio/fingerprint/fp_tc.h
new file mode 100644
index 0000000..ba4901d
--- /dev/null
+++ b/drivers/iio/fingerprint/fp_tc.h
@@ -0,0 +1,22 @@
+#ifndef FP_TC_H
+#define FP_TC_H
+
+#define FP_TC_SCAN_HEIGHT	384
+#define FP_TC_SCAN_WIDTH	144
+#define FP_TC_SCAN_BIT_DEPTH	8
+/* horizontal orientation */
+#define FP_TC_SCAN_ORIENTATION	0
+/* color scheme is black on white */
+#define FP_TC_SCAN_COLOR_SCHEME	0
+
+struct usb_fp_tc;
+
+struct fp_tc_data {
+	struct usb_fp_tc *uft;
+	u8 scan_result;
+	int (*fp_tc_get_data)(struct iio_dev *indio_dev, u8 *data);
+};
+int fp_tc_init_iio(struct iio_dev *indio_dev);
+void fp_tc_remove_iio(struct iio_dev *indio_dev);
+
+#endif
diff --git a/drivers/iio/fingerprint/fp_tc_usb.c b/drivers/iio/fingerprint/fp_tc_usb.c
new file mode 100644
index 0000000..9768807
--- /dev/null
+++ b/drivers/iio/fingerprint/fp_tc_usb.c
@@ -0,0 +1,618 @@
+/*
+ * UPEK TouchChip USB Fingerprint sensor driver
+ * Copyright (c) 2014, Intel Corporation.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/irq.h>
+#include <linux/usb.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/trigger_consumer.h>
+#include <linux/iio/triggered_buffer.h>
+#include <linux/crc-itu-t.h>
+#include "fp_tc.h"
+#include "fp_tc_usb.h"
+
+static const struct usb_device_id fp_table_id[] = {
+	{USB_DEVICE(USB_FP_TC_VENDOR_ID, USB_FP_TC_PRODUCT_ID)},
+	{ }
+};
+MODULE_DEVICE_TABLE(usb, fp_table_id);
+
+static struct usb_driver fp_tc_usb_driver;
+
+/***************************** HELPERS *****************************/
+
+static const uint16_t crc_table[256] = {
+	0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
+	0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
+	0x1231, 0x0210, 0x3273, 0x2252, 0x52b5, 0x4294, 0x72f7, 0x62d6,
+	0x9339, 0x8318, 0xb37b, 0xa35a, 0xd3bd, 0xc39c, 0xf3ff, 0xe3de,
+	0x2462, 0x3443, 0x0420, 0x1401, 0x64e6, 0x74c7, 0x44a4, 0x5485,
+	0xa56a, 0xb54b, 0x8528, 0x9509, 0xe5ee, 0xf5cf, 0xc5ac, 0xd58d,
+	0x3653, 0x2672, 0x1611, 0x0630, 0x76d7, 0x66f6, 0x5695, 0x46b4,
+	0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe, 0xd79d, 0xc7bc,
+	0x48c4, 0x58e5, 0x6886, 0x78a7, 0x0840, 0x1861, 0x2802, 0x3823,
+	0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948, 0x9969, 0xa90a, 0xb92b,
+	0x5af5, 0x4ad4, 0x7ab7, 0x6a96, 0x1a71, 0x0a50, 0x3a33, 0x2a12,
+	0xdbfd, 0xcbdc, 0xfbbf, 0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a,
+	0x6ca6, 0x7c87, 0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0x0c60, 0x1c41,
+	0xedae, 0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49,
+	0x7e97, 0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51, 0x0e70,
+	0xff9f, 0xefbe, 0xdfdd, 0xcffc, 0xbf1b, 0xaf3a, 0x9f59, 0x8f78,
+	0x9188, 0x81a9, 0xb1ca, 0xa1eb, 0xd10c, 0xc12d, 0xf14e, 0xe16f,
+	0x1080, 0x00a1, 0x30c2, 0x20e3, 0x5004, 0x4025, 0x7046, 0x6067,
+	0x83b9, 0x9398, 0xa3fb, 0xb3da, 0xc33d, 0xd31c, 0xe37f, 0xf35e,
+	0x02b1, 0x1290, 0x22f3, 0x32d2, 0x4235, 0x5214, 0x6277, 0x7256,
+	0xb5ea, 0xa5cb, 0x95a8, 0x8589, 0xf56e, 0xe54f, 0xd52c, 0xc50d,
+	0x34e2, 0x24c3, 0x14a0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
+	0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e, 0xc71d, 0xd73c,
+	0x26d3, 0x36f2, 0x0691, 0x16b0, 0x6657, 0x7676, 0x4615, 0x5634,
+	0xd94c, 0xc96d, 0xf90e, 0xe92f, 0x99c8, 0x89e9, 0xb98a, 0xa9ab,
+	0x5844, 0x4865, 0x7806, 0x6827, 0x18c0, 0x08e1, 0x3882, 0x28a3,
+	0xcb7d, 0xdb5c, 0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a,
+	0x4a75, 0x5a54, 0x6a37, 0x7a16, 0x0af1, 0x1ad0, 0x2ab3, 0x3a92,
+	0xfd2e, 0xed0f, 0xdd6c, 0xcd4d, 0xbdaa, 0xad8b, 0x9de8, 0x8dc9,
+	0x7c26, 0x6c07, 0x5c64, 0x4c45, 0x3ca2, 0x2c83, 0x1ce0, 0x0cc1,
+	0xef1f, 0xff3e, 0xcf5d, 0xdf7c, 0xaf9b, 0xbfba, 0x8fd9, 0x9ff8,
+	0x6e17, 0x7e36, 0x4e55, 0x5e74, 0x2e93, 0x3eb2, 0x0ed1, 0x1ef0
+};
+
+
+static void fp_tc_img_cmd_fix_seq(unsigned char *cmd_buf, unsigned char seq)
+{
+	uint8_t byte;
+
+	byte = cmd_buf[5];
+	byte &= 0x0f;
+	byte |= (seq << 4);
+	cmd_buf[5] = byte;
+}
+
+static uint16_t udf_crc(unsigned char *buffer, size_t size)
+{
+	uint16_t crc = 0;
+
+	while (size--)
+		crc = (uint16_t) ((crc << 8) ^
+				  crc_table[((crc >> 8) & 0x00ff) ^ *buffer++]);
+	return crc;
+}
+
+static void fp_tc_img_cmd_update_crc(unsigned char *cmd_buf, size_t size)
+{
+	/*
+	 * CRC does not cover Ciao prefix (4 bytes) and CRC location (2 bytes)
+	 */
+	uint16_t crc = udf_crc(cmd_buf + 4, size - 6);
+
+	cmd_buf[size - 2] = (crc & 0x00ff);
+	cmd_buf[size - 1] = (crc & 0xff00) >> 8;
+}
+
+static int fp_tc_img_process_image_frame(unsigned char *image_buf,
+					 unsigned char *cmd_res)
+{
+	int offset = 8;
+	int len = ((cmd_res[5] & 0x0f) << 8) | (cmd_res[6]);
+
+	len -= 1;
+	if (cmd_res[7] == 0x2c) {
+		len -= 10;
+		offset += 10;
+	}
+	if (cmd_res[7] == 0x20)
+		len -= 4;
+	memcpy(image_buf, cmd_res + offset, len);
+
+	return len;
+}
+
+/*****************************************************************************/
+
+
+static int fp_tc_send_out_bulk(struct usb_fp_tc *dev, unsigned char *cmd,
+			       int cmd_size)
+{
+	unsigned int pipe;
+	int retval = 0;
+	int actual_len;
+
+	fp_tc_img_cmd_fix_seq(cmd, dev->seq);
+	fp_tc_img_cmd_update_crc(cmd, cmd_size);
+	pipe = usb_sndbulkpipe(dev->udev, dev->bulk_out_endpoint_addr);
+
+	retval = usb_bulk_msg(dev->udev, pipe, cmd, cmd_size,
+			      &actual_len, FP_TC_USB_BULK_TIMEOUT);
+	if (retval < 0)
+		dev_err(&dev->intf->dev, "%s - failed submitting URB_BULK urb, error %d\n",
+			__func__, retval);
+
+	return retval;
+}
+
+static int fp_tc_read_short_resp(struct usb_fp_tc *dev)
+{
+	unsigned int pipe;
+	int retval = 0;
+	unsigned char *buffer;
+	int actual_len;
+
+	pipe = usb_rcvbulkpipe(dev->udev, dev->bulk_in_endpoint_addr);
+
+	buffer = kzalloc(FP_TC_SHORT_RESP_SIZE, GFP_KERNEL);
+	if (!buffer)
+		return -ENOMEM;
+
+	retval = usb_bulk_msg(dev->udev, pipe, buffer, FP_TC_SHORT_RESP_SIZE,
+			      &actual_len,
+			      FP_TC_USB_BULK_TIMEOUT);
+	if (retval < 0)
+		dev_err(&dev->intf->dev, "%s - failed reading URB_BULK urb, error %d\n",
+			__func__, retval);
+
+	kfree(buffer);
+	return retval;
+}
+
+static int fp_tc_send_ctrl_bulk(struct usb_fp_tc *dev)
+{
+	int retval = 0;
+	unsigned char *buffer;
+
+	/* send control msg */
+	buffer = kzalloc(FP_TC_CTRL_SIZE, GFP_KERNEL);
+	if (!buffer)
+		return -ENOMEM;
+
+	retval = usb_control_msg(dev->udev,
+				 usb_sndctrlpipe(dev->udev, 0),
+				 FP_TC_CTRL_REQUEST,
+				 FP_TC_CTRL_REQUEST_TYPE,
+				 FP_TC_CTRL_VALUE,
+				 FP_TC_CTRL_INDEX,
+				 buffer,
+				 FP_TC_CTRL_SIZE,
+				 USB_CTRL_SET_TIMEOUT);
+	if (retval < 0)
+		dev_err(&dev->intf->dev, "%s - could not sent control msg, error %d\n",
+			__func__, retval);
+
+	kfree(buffer);
+	return retval;
+}
+
+static int prev_state;
+static int next_state;
+
+static int fp_tc_usb_activate(struct usb_fp_tc *dev)
+{
+	int retval = 0;
+
+	while (next_state != FP_TC_DONE) {
+		if (next_state != FP_TC_READ_SHORT_RESP)
+			prev_state = next_state;
+
+		switch (next_state) {
+		case FP_TC_CTRL_1:
+		case FP_TC_CTRL_2:
+			retval = fp_tc_send_ctrl_bulk(dev);
+			next_state = FP_TC_READ_SHORT_RESP;
+			break;
+		case FP_TC_INIT_1:
+			retval = fp_tc_send_out_bulk(dev, fp_tc_usb_init_1,
+						     sizeof(fp_tc_usb_init_1));
+			next_state = FP_TC_READ_SHORT_RESP;
+			break;
+		case FP_TC_INIT_2:
+			retval = fp_tc_send_out_bulk(dev, fp_tc_usb_init_2,
+						     sizeof(fp_tc_usb_init_2));
+			next_state = FP_TC_READ_SHORT_RESP;
+			break;
+		case FP_TC_INIT_3:
+			retval = fp_tc_send_out_bulk(dev, fp_tc_usb_init_3,
+						     sizeof(fp_tc_usb_init_3));
+			next_state = FP_TC_READ_SHORT_RESP;
+			break;
+		case FP_TC_INIT_4:
+			retval = fp_tc_send_out_bulk(dev, fp_tc_usb_init_4,
+						     sizeof(fp_tc_usb_init_4));
+			next_state = FP_TC_READ_SHORT_RESP;
+			dev->seq++;
+			break;
+		case FP_TC_READ_SHORT_RESP:
+			retval = fp_tc_read_short_resp(dev);
+			if (prev_state == FP_TC_INIT_4)
+				next_state = FP_TC_DONE;
+			else
+				next_state = ++prev_state;
+			break;
+		default:
+			dev_err(&dev->intf->dev, "%s - invalid state in activation sequence\n",
+				__func__);
+			return -EINVAL;
+		}
+
+		if (retval < 0)
+			goto exit;
+	}
+
+exit:
+	return retval;
+}
+
+static int fp_tc_deactivate(struct usb_fp_tc *dev)
+{
+	int retval = 0;
+
+	retval = fp_tc_send_out_bulk(dev, fp_tc_usb_deinit,
+				     sizeof(fp_tc_usb_deinit));
+	if (retval < 0)
+		return retval;
+	dev->seq++;
+	return fp_tc_read_short_resp(dev);
+}
+
+static int fp_tc_usb_process_capture(unsigned char *data, struct usb_fp_tc *dev,
+				     unsigned char *image,
+				     unsigned int *image_size,
+				     unsigned int *received_img)
+{
+	int retval;
+	unsigned int temp_seq;
+
+	switch (data[4]) {
+	case  FP_TC_FRAME_1:
+		switch (data[7]) {
+		case FP_TC_NO_FINGER:
+			retval =
+				fp_tc_send_out_bulk(dev, fp_tc_usb_ack_28,
+						    sizeof(fp_tc_usb_ack_28));
+			dev->seq++;
+			break;
+		case FP_TC_IMG_INFO_FRAME:
+			/* should we process the image information? */
+		case FP_TC_IMG_FRAME:
+			*image_size +=
+				fp_tc_img_process_image_frame(image +
+							      *image_size,
+							      data);
+
+			retval =
+				fp_tc_send_out_bulk(dev, fp_tc_usb_ack,
+						    sizeof(fp_tc_usb_ack));
+			dev->seq++;
+			break;
+		case FP_TC_LAST_IMG_FRAME:
+			*image_size +=
+				fp_tc_img_process_image_frame(image +
+							      *image_size,
+							      data);
+			*received_img = 1;
+			fp_tc_deactivate(dev);
+			break;
+		default:
+			dev_warn(&dev->intf->dev, "Unknown response %d\n",
+				 data[7]);
+			break;
+		}
+		break;
+	case FP_TC_FRAME_2:
+		temp_seq = dev->seq;
+		dev->seq = 0;
+		retval = fp_tc_send_out_bulk(dev, fp_tc_usb_ack_08,
+					     sizeof(fp_tc_usb_ack_08));
+		dev->seq = temp_seq;
+		break;
+	default:
+		dev_warn(&dev->intf->dev, "Unknown response%d\n",
+			 data[4]);
+	}
+
+	return retval;
+}
+
+static int fp_tc_usb_capture(struct usb_fp_tc *dev, unsigned char *image)
+{
+	unsigned int pipe;
+	int retval;
+	unsigned int actual_len;
+	unsigned int response_size;
+	unsigned int received_img;
+	/* buffer to hold the image */
+	unsigned char *data;
+	/* image size */
+	unsigned int image_size;
+	/* useful to know if we have any more data to read */
+	unsigned int response_rest;
+
+	retval		= 0;
+	received_img	= 0;
+	response_rest	= 0;
+	image_size	= 0;
+
+	retval = fp_tc_send_out_bulk(dev, fp_tc_usb_init_capture,
+				     sizeof(fp_tc_usb_init_capture));
+	if (retval < 0)
+		return retval;
+	dev->seq++;
+
+	data = kzalloc(FP_TC_MAX_RESP_SIZE, GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	while (!received_img) {
+		/*
+		 * Read out the response to an init_capture or
+		 * after capturing a frame
+		 */
+		pipe = usb_rcvbulkpipe(dev->udev, dev->bulk_in_endpoint_addr);
+		if (!response_rest) {
+			retval = usb_bulk_msg(dev->udev, pipe, data,
+					      FP_TC_SHORT_RESP_SIZE,
+					      &actual_len,
+					      FP_TC_USB_BULK_TIMEOUT);
+		} else {
+			retval = usb_bulk_msg(dev->udev, pipe,
+					      data + FP_TC_SHORT_RESP_SIZE,
+					      FP_TC_MAX_RESP_SIZE -
+					      FP_TC_SHORT_RESP_SIZE,
+					      &actual_len,
+					      FP_TC_USB_BULK_TIMEOUT);
+		}
+
+		if (retval < 0) {
+			dev_err(&dev->intf->dev, "%s - failed reading URB_BULK urb, error %d\n",
+				__func__, retval);
+			goto exit;
+		}
+
+		if (actual_len == 0)
+			continue;
+
+		if (!response_rest) {
+			response_size = ((data[5] & 0x0f) << 8) + data[6];
+			response_size += 9;
+			if (response_size > actual_len) {
+				response_rest = response_size - actual_len;
+				continue;
+			}
+		}
+		response_rest = 0;
+
+		fp_tc_usb_process_capture(data, dev, image, &image_size,
+					  &received_img);
+		if (retval < 0)
+			goto exit;
+	}
+
+	return 0;
+
+exit:
+	kfree(data);
+	return retval;
+}
+
+static int fp_tc_usb_get_data(struct iio_dev *indio_dev, u8 *image)
+{
+	struct usb_fp_tc *dev;
+	struct fp_tc_data *data;
+	int retval;
+	int nr_retries = 0;
+
+	data = iio_priv(indio_dev);
+	dev = data->uft;
+
+	do {
+		next_state = FP_TC_CTRL_1;
+		prev_state = FP_TC_CTRL_1;
+		retval = fp_tc_usb_activate(dev);
+	} while (nr_retries < FP_TC_USB_RETRIES && retval < 0);
+	if (retval < 0)
+		goto exit;
+
+	nr_retries = 0;
+	do {
+		retval = fp_tc_usb_capture(dev, image);
+	} while (nr_retries < FP_TC_USB_RETRIES && retval < 0);
+	if (retval < 0)
+		goto exit;
+
+	data->scan_result = STATUS_FINGERPRINT_GOOD;
+	return 0;
+exit:
+	data->scan_result = STATUS_FINGERPRINT_FAIL;
+	return retval;
+}
+
+static void fp_tc_usb_delete(struct kref *kref)
+{
+	struct usb_fp_tc *dev;
+
+	dev = container_of(kref, struct usb_fp_tc, kref);
+
+	usb_put_dev(dev->udev);
+	/* free the device and any allocated buffers */
+	kfree(dev);
+}
+
+static int fp_tc_usb_release(struct inode *inode, struct file *file)
+{
+	struct usb_fp_tc *dev;
+
+	dev = file->private_data;
+	if (!dev)
+		return -ENODEV;
+
+	if (dev->intf)
+		usb_autopm_put_interface(dev->intf);
+
+	/* decrement usage count for the device */
+	kref_put(&dev->kref, fp_tc_usb_delete);
+
+	return 0;
+}
+
+static const struct file_operations fp_tc_usb_fops = {
+	.owner =	THIS_MODULE,
+	.release =	fp_tc_usb_release,
+};
+
+/*
+ * usb class driver in order to register and get minor from usb core
+ */
+static struct usb_class_driver fp_tc_usb_class = {
+	.name =		"fp_tc%d",
+	.fops =		&fp_tc_usb_fops,
+	.minor_base =	USB_FP_TC_MINOR_BASE,
+};
+
+static int fp_tc_usb_probe(struct usb_interface *intf,
+			   const struct usb_device_id *id)
+{
+	struct usb_fp_tc *dev;
+	struct fp_tc_data *data;
+	struct usb_host_interface *intf_desc;
+	struct usb_endpoint_descriptor *endpoint;
+	struct iio_dev *indio_dev;
+	struct usb_device *udev;
+	int retval = -ENOMEM;
+	int i;
+
+	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+	if (!dev)
+		return retval;
+
+	dev->seq = 0;
+	dev->intf = intf;
+	dev->udev = interface_to_usbdev(intf);
+
+	intf_desc = intf->cur_altsetting;
+	for (i = 0; i < intf_desc->desc.bNumEndpoints; ++i) {
+		endpoint = &intf_desc->endpoint[i].desc;
+
+		if (!dev->bulk_in_endpoint_addr &&
+		    usb_endpoint_is_bulk_in(endpoint)) {
+			/* we found a bulk in endpoint */
+			dev->bulk_in_endpoint_addr = endpoint->bEndpointAddress;
+		}
+
+		if (!dev->bulk_out_endpoint_addr &&
+		    usb_endpoint_is_bulk_out(endpoint)) {
+			/* we found a bulk out endpoint */
+			dev->bulk_out_endpoint_addr =
+				endpoint->bEndpointAddress;
+		}
+	}
+
+	if (!(dev->bulk_in_endpoint_addr && dev->bulk_out_endpoint_addr)) {
+		dev_err(&intf->dev,
+			"Could not find both bulk-in and bulk-out endpoints\n");
+		retval = -ENODEV;
+		goto error;
+	}
+
+	/* save our data pointer in this interface device */
+	usb_set_intfdata(intf, dev);
+
+	/* Register device now */
+	retval = usb_register_dev(intf, &fp_tc_usb_class);
+	if (retval) {
+		dev_err(&intf->dev, "Unable to get a minor for this device.\n");
+		usb_set_intfdata(intf, NULL);
+		goto error;
+	}
+
+	dev_info(&intf->dev, "USB Fingerprint driver attached to %d\n",
+		 intf->minor);
+
+	udev = dev->udev;
+	indio_dev = devm_iio_device_alloc(&udev->dev, sizeof(*data));
+	if (!indio_dev)
+		goto error;
+
+	data = iio_priv(indio_dev);
+	dev_set_drvdata(&udev->dev, indio_dev);
+	data->uft = dev;
+
+	indio_dev->dev.parent = &udev->dev;
+	indio_dev->name = fp_tc_usb_driver.name;
+
+	data->fp_tc_get_data = fp_tc_usb_get_data;
+	data->scan_result = STATUS_UNKNOWN;
+
+	retval = fp_tc_init_iio(indio_dev);
+	if (retval < 0)
+		goto error;
+
+	return 0;
+
+error:
+	if (dev)
+		kref_put(&dev->kref, fp_tc_usb_delete);
+	return retval;
+}
+
+
+static void fp_tc_usb_disconnect(struct usb_interface *intf)
+{
+	struct usb_fp_tc *dev;
+	struct iio_dev *indio_dev;
+
+	dev = usb_get_intfdata(intf);
+	usb_set_intfdata(intf, NULL);
+
+	/* give back our minor */
+	usb_deregister_dev(intf, &fp_tc_usb_class);
+
+	/* decrement our usage count */
+	kref_put(&dev->kref, fp_tc_usb_delete);
+
+	dev_info(&intf->dev, "USB Fingerprint TouchChip #%d now disconnected",
+		 intf->minor);
+
+	indio_dev = dev_get_drvdata(&intf->dev);
+	if (!indio_dev)
+		dev_err(&intf->dev, "Could not get drvdata\n");
+		return;
+
+	fp_tc_remove_iio(indio_dev);
+}
+
+static struct usb_driver fp_tc_usb_driver = {
+	.name =		"fingerprint_tc",
+	.probe =	fp_tc_usb_probe,
+	.disconnect =	fp_tc_usb_disconnect,
+	.id_table =	fp_table_id,
+};
+
+static __init int fp_tc_init(void)
+{
+	usb_register(&fp_tc_usb_driver);
+	return 0;
+}
+
+static __exit void fp_tc_exit(void)
+{
+	usb_deregister(&fp_tc_usb_driver);
+}
+module_init(fp_tc_init);
+module_exit(fp_tc_exit);
+
+MODULE_AUTHOR("Teodora Baluta <teodora.baluta@intel.com");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("UPEK TouchChip Fingerprint driver");
diff --git a/drivers/iio/fingerprint/fp_tc_usb.h b/drivers/iio/fingerprint/fp_tc_usb.h
new file mode 100644
index 0000000..5f26e82
--- /dev/null
+++ b/drivers/iio/fingerprint/fp_tc_usb.h
@@ -0,0 +1,144 @@
+#ifndef FP_TC_USB_H
+#define FP_TC_USB_H
+
+#define USB_FP_TC_VENDOR_ID	0x147e
+#define USB_FP_TC_PRODUCT_ID	0x2020
+
+#define USB_FP_TC_MINOR_BASE	254
+
+/* Control message settings */
+#define FP_TC_CTRL_REQUEST	0x0c
+#define FP_TC_CTRL_REQUEST_TYPE	0x40
+#define FP_TC_CTRL_VALUE	0x0100
+#define FP_TC_CTRL_INDEX	0x0400
+#define FP_TC_CTRL_SIZE		1
+
+/* USB timeouts */
+#define FP_TC_USB_BULK_TIMEOUT	4000
+#define FP_TC_USB_CTRL_TIMEOUT	4000
+
+/* Capture frame sizes */
+#define FP_TC_SHORT_RESP_SIZE	64
+#define FP_TC_MAX_RESP_SIZE	2052
+
+/* Identify the type of frame sent out by the device */
+#define FP_TC_FRAME_1		0x00
+#define FP_TC_FRAME_2		0x08
+#define FP_TC_NO_FINGER		0x28
+#define FP_TC_IMG_INFO_FRAME	0x2c
+#define FP_TC_IMG_FRAME		0x24
+#define FP_TC_LAST_IMG_FRAME	0x20
+
+/* USB activate frames are done in a certain sequence */
+#define FP_TC_CTRL_1		1
+#define FP_TC_INIT_1		2
+#define FP_TC_INIT_2		3
+#define FP_TC_CTRL_2		4
+#define FP_TC_INIT_3		5
+#define FP_TC_INIT_4		6
+#define FP_TC_READ_SHORT_RESP	7
+#define FP_TC_DONE		8
+
+#define FP_TC_USB_RETRIES	5
+
+struct usb_fp_tc {
+	/* the usb device for this device */
+	struct usb_device	*udev;
+	/* the interface for this device */
+	struct usb_interface	*intf;
+	/* the address of the bulk in endpoint */
+	__u8			bulk_in_endpoint_addr;
+	/* the address of the bulk out endpoint */
+	__u8			bulk_out_endpoint_addr;
+	/* keep count */
+	struct kref		kref;
+	/* sequence number for communication with device */
+	unsigned char		seq;
+};
+
+static unsigned char fp_tc_usb_init_1[] = {
+'C', 'i', 'a', 'o',
+0x04,
+0x00, 0x0d,
+0x01, 0x00, 0x46, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
+0x01, 0x00, 0x00, 0x00,
+0xda, 0xc1
+};
+
+static unsigned char fp_tc_usb_init_2[] = {
+0x43, 0x69, 0x61, 0x6f,
+0x07,
+0x00, 0x01,
+0x01,
+0x3d, 0x72
+};
+
+static unsigned char fp_tc_usb_init_3[] = {
+'C', 'i', 'a', 'o',
+0x04,
+0x00, 0x0d,
+0x01, 0x00, 0xbc, 0x02, 0x00, 0x00, 0x00, 0x00, 0x01,
+0x01, 0x00, 0x00, 0x00,
+0x55, 0x2f
+};
+
+static unsigned char fp_tc_usb_init_4[] = {
+'C', 'i', 'a', 'o',
+0x00,
+0x00, 0x07,
+0x28, 0x04, 0x00, 0x00, 0x00, 0x06, 0x04,
+0xc0, 0xd6
+};
+
+static unsigned char fp_tc_usb_deinit[] = {
+'C', 'i', 'a', 'o',
+0x07,
+0x00, 0x01,
+0x01,
+0x3d,
+0x72
+};
+
+static unsigned char fp_tc_usb_init_capture[] = {
+'C', 'i', 'a', 'o',
+0x00,
+0x00, 0x0e, /* Seq = 7, len = 0x00e */
+0x28, /* CMD = 0x28 */
+0x0b, 0x00,  /* Inner len = 0x000b */
+0x00, 0x00,
+0x0e, /* SUBCMD = 0x0e */
+0x02,
+0xfe, 0xff, 0xff, 0xff, /* timeout = -2 = 0xfffffffe = infinite time */
+0x02,
+0x00, /* Wait for acceptable finger */
+0x02,
+0x14, 0x9a /* CRC */
+};
+
+static unsigned char fp_tc_usb_ack_28[] = {
+'C', 'i', 'a', 'o',
+0x00,
+0x80, 0x08, /* Seq = 8, len = 0x008 */
+0x28, /* CMD = 0x28 */
+0x05, 0x00, /* Inner len = 0x0005 */
+0x00, 0x00, 0x00, 0x30, 0x01,
+0x6a, 0xc4 /* CRC */
+};
+
+/* No seq should be put in there */
+static unsigned char fp_tc_usb_ack_08[] = {
+'C', 'i', 'a', 'o',
+0x09,
+0x00, 0x00, /* Seq = 0, len = 0x0 */
+0x91, 0x9e /* CRC */
+};
+
+static unsigned char fp_tc_usb_ack[] = {
+'C', 'i', 'a', 'o',
+0x00,
+0x50, 0x01, /* Seq = 5, len = 0x001 */
+0x30,
+0xac, 0x5b /* CRC */
+};
+
+#endif
-- 
1.9.1

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

[Jonathan Cameron]

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

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

[Baluta, Teodora]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4311 bytes --]

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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Baluta, Teodora]

SGVsbG8sDQoNCk9uIFZpLCAyMDE0LTEyLTA1IGF0IDAyOjE1ICswMDAwLCBKb25hdGhhbiBDYW1l
cm9uIHdyb3RlOg0KPiBPbiAwNC8xMi8xNCAxMzowMCwgVGVvZG9yYSBCYWx1dGEgd3JvdGU6DQo+
ID4gVGhpcyBwYXRjaHNldCBhZGRzIHN1cHBvcnQgZm9yIGZpbmdlcnByaW50IHNlbnNvcnMgdGhy
b3VnaCB0aGUgSUlPIGludGVyZmFjZS4NCj4gPiBUaGlzIHdheSB1c2Vyc3BhY2UgYXBwbGljYXRp
b25zIGNvbGxlY3QgaW5mb3JtYXRpb24gaW4gYSB1bmlmb3JtIHdheS4gQWxsDQo+ID4gcHJvY2Vz
c2luZyB3b3VsZCBiZSBkb25lIGluIHRoZSB1cHBlciBsYXllcnMgYXMgc3VnZ2VzdGVkIGluIFsw
XS4NCj4gPiANCj4gPiBJbiBvcmRlciB0byB0ZXN0IG91dCB0aGlzIHByb3Bvc2FsLCBhIG1pbmlt
YWwgaW1wbGVtZW50YXRpb24gZm9yIFVQRUsncw0KPiA+IFRvdWNoQ2hpcCBGaW5nZXJwcmludCBT
ZW5zb3IgdmlhIFVTQiBpcyBhbHNvIGF2YWlsYWJsZS4gQWx0aG91Z2ggdGhlcmUgaXMgYW4NCj4g
PiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiBpbiB1c2Vyc3BhY2UgZm9yIFVTQiBmaW5nZXJwcmlu
dCBkZXZpY2VzLCBpbmNsdWRpbmcgdGhpcw0KPiA+IHBhcnRpY3VsYXIgZGV2aWNlLCB0aGUgZHJp
dmVyIHJlcHJlc2VudHMgYSBwcm9vZiBvZiBjb25jZXB0IG9mIGhvdyBmaW5nZXJwcmludA0KPiA+
IHNlbnNvcnMgY291bGQgYmUgaW50ZWdyYXRlZCBpbiB0aGUgSUlPIGZyYW1ld29yayByZWdhcmRs
ZXNzIG9mIHRoZSB1c2VkIGJ1cy4gRm9yDQo+ID4gbG93ZXIgcG93ZXIgcmVxdWlyZW1lbnRzLCB0
aGUgU1BJIGJ1cyBpcyBwcmVmZXJyZWQgYW5kIGEga2VybmVsIGRyaXZlcg0KPiA+IGltcGxlbWVu
dGF0aW9uIG1ha2VzIG1vcmUgc2Vuc2UuDQo+IA0KPiBTbyB3aHkgbm90IHY0bD8gIFRoZXNlIGFy
ZSBlZmZlY3RpdmVseSBpbWFnZSBzZW5zb3JzLi4gDQoNCldlbGwsIGhlcmUncyB3aHkgSSBkb24n
dCB0aGluayB2NGwgd291bGQgYmUgdGhlIGJlc3Qgb3B0aW9uOg0KDQotIGFuIGltYWdlIHNjYW5u
ZXIgY291bGQgYmUgaW1wbGVtZW50ZWQgaW4gdGhlIHY0bCBzdWJzeXN0ZW0sIGJ1dCBpdA0Kc2Vl
bXMgZmFyIG1vcmUgY29tcGxpY2F0ZWQgZm9yIGEgc2ltcGxlIGZpbmdlcnByaW50IHNjYW5uZXIg
LSBpdCB1c3VhbGx5DQpoYXMgZHJpdmVycyBmb3Igd2ViY2FtcywgVFZzIG9yIHZpZGVvIHN0cmVh
bWluZyBkZXZpY2VzLiBUaGUgdjRsDQpzdWJzeXN0ZW0gKHdpdGggYWxsIGl0cyBzdXBwb3J0IGZv
ciBjb2xvcnNwYWNlLCBkZWNvZGVycywgaW1hZ2UNCmNvbXByZXNzaW9uLCBmcmFtZSBjb250cm9s
KSBzZWVtcyBhIGJpdCBvZiBhbiBvdmVya2lsbCBmb3IgYSB2ZXJ5DQpzdHJhaWdodGZvcndhcmQg
ZmluZ2VycHJpbnQgaW1hZ2luZyBzZW5zb3IuDQoNCi0gYSBmaW5nZXJwcmludCBkZXZpY2UgY291
bGQgYWxzbyBzZW5kIG91dCBhIHByb2Nlc3NlZCBpbmZvcm1hdGlvbiwgbm90DQpqdXN0IHRoZSBp
bWFnZSBvZiBhIGZpbmdlcnByaW50LiBUaGlzIG1lYW5zIHRoYXQgdGhlIHByb2Nlc3NpbmcgaXMg
ZG9uZQ0KaW4gaGFyZHdhcmUgLSB0aGUgVVBFSyBUb3VjaFN0cmlwIGNoaXBzZXQgaW4gbGliZnBy
aW50IGhhcyB0aGlzIGJlaGF2aW9yDQooc2VlIFswXSkuIFNvLCB0aGUgSUlPIGZyYW1ld29yayB3
b3VsZCBzdXBwb3J0IGEgdW5pZm9ybSB3YXkgb2YgaGFuZGxpbmcNCmZpbmdlcnByaW50IGRldmlj
ZXMgdGhhdCBlaXRoZXIgZG8gcHJvY2Vzc2luZyBpbiBzb2Z0d2FyZSBvciBpbg0KaGFyZHdhcmUu
DQoNClRoZSB3YXkgSSBzZWUgaXQgbm93LCBmb3IgcHJvY2Vzc2VkIGZpbmdlcnByaW50IGluZm9y
bWF0aW9uLCBhbiBJSU8NCmRldmljZSBjb3VsZCBoYXZlIGFuIElJT19GSU5HRVJQUklOVCBjaGFu
bmVsIHdpdGggYSBtb2RpZmllciBhbmQgb25seQ0KdGhlIHNlbnNpdGl2aXR5IHRocmVzaG9sZCBh
dHRyaWJ1dGUgc2V0LiBXZSB3b3VsZCBhbHNvIG5lZWQgdHdvDQp0cmlnZ2Vyczogb25lIGZvciBl
bnJvbGxtZW50IGFuZCBvbmUgZm9yIHRoZSB2ZXJpZmljYXRpb24gbW9kZSB0bw0KY29udHJvbCB0
aGUgZGV2aWNlIGZyb20gYSB1c2Vyc3BhY2UgYXBwbGljYXRpb24uDQoNClRoYW5rcywNClRlb2Rv
cmENCg0KWzBdIGh0dHA6Ly93d3cuZnJlZWRlc2t0b3Aub3JnL3dpa2kvU29mdHdhcmUvZnByaW50
L2xpYmZwcmludC91cGVrdHMvDQoNCg0KPiA+IA0KPiA+IEEgc3lzZnMgdHJpZ2dlciBpcyBlbmFi
bGVkIGFuZCB0aGUgZGV2aWNlIHN0YXJ0cyBzY2FubmluZy4gQXMgc29vbiBhcyBhbiBpbWFnZQ0K
PiA+IGlzIGF2YWlsYWJsZSBpdCBpcyB3cml0dGVuIGluIHRoZSBjaGFyYWN0ZXIgZGV2aWNlIC9k
ZXYvaWlvOmRldmljZVguDQo+ID4gDQo+ID4gVXNlcnNwYWNlIGFwcGxpY2F0aW9ucyB3aWxsIGJl
IGFibGUgdG8gY2FsY3VsYXRlIHRoZSBleHBlY3RlZCBpbWFnZSBzaXplIHVzaW5nDQo+ID4gdGhl
IGZpbmdlcnByaW50IGF0dHJpYnV0ZXMgaGVpZ2h0LCB3aWR0aCBhbmQgYml0IGRlcHRoLiBPdGhl
ciBhdHRyaWJ1dGVzDQo+ID4gaW50cm9kdWNlZCBmb3IgdGhlIGZpbmdlcnByaW50IGNoYW5uZWwg
aW4gSUlPIHJlcHJlc2VudCBpbmZvcm1hdGlvbiB0aGF0IGFpZHMgaW4NCj4gPiB0aGUgZmluZ2Vy
cHJpbnQgaW1hZ2UgcHJvY2Vzc2luZy4gQmVzaWRlcyB0aGVzZSwgdGhlIHByb3Bvc2VkIGludGVy
ZmFjZSBvZmZlcnMNCj4gPiB1c2Vyc3BhY2UgYSB3YXkgdG8gcmVhZCBhIGZlZWRiYWNrIGFmdGVy
IGEgc2NhbiAobGlrZSB0aGUgc3dpcGUgd2FzIHRvbyBzbG93IG9yDQo+ID4gdG9vIGZhc3QpIHRo
cm91Z2ggYSBtb2RpZmllZCBmaW5nZXJwcmludF9zdGF0dXMgY2hhbm5lbC4NCj4gPiANCj4gPiBb
MF0gaHR0cDovL3d3dy5zcGluaWNzLm5ldC9saXN0cy9saW51eC1paW8vbXNnMTE0NjMuaHRtbA0K
PiA+IA0KPiA+IFRlb2RvcmEgQmFsdXRhICgzKToNCj4gPiAgIGlpbzogY29yZTogYWRkIHN1cHBv
cnQgZm9yIGZpbmdlcnByaW50IGRldmljZXMNCj4gPiAgIGlpbzogY29yZTogY2hhbmdlIGNoYW5u
ZWwncyBzdG9yYWdlYml0cy9yZWFsYml0cyB0byB1MzINCj4gPiAgIGlpbzogZmluZ2VycHJpbnQ6
IGFkZCBmaW5nZXJwcmludCBzZW5zb3IgdmlhIFVTQg0KPiA+IA0KPiA+ICBEb2N1bWVudGF0aW9u
L0FCSS90ZXN0aW5nL3N5c2ZzLWJ1cy1paW8gfCAgNTEgKysrDQo+ID4gIGRyaXZlcnMvaWlvL0tj
b25maWcgICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQo+ID4gIGRyaXZlcnMvaWlvL01ha2Vm
aWxlICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQo+ID4gIGRyaXZlcnMvaWlvL2ZpbmdlcnBy
aW50L0tjb25maWcgICAgICAgICB8ICAxNSArDQo+ID4gIGRyaXZlcnMvaWlvL2ZpbmdlcnByaW50
L01ha2VmaWxlICAgICAgICB8ICAgNSArDQo+ID4gIGRyaXZlcnMvaWlvL2ZpbmdlcnByaW50L2Zw
X3RjLmMgICAgICAgICB8IDE2MiArKysrKysrKysNCj4gPiAgZHJpdmVycy9paW8vZmluZ2VycHJp
bnQvZnBfdGMuaCAgICAgICAgIHwgIDIyICsrDQo+ID4gIGRyaXZlcnMvaWlvL2ZpbmdlcnByaW50
L2ZwX3RjX3VzYi5jICAgICB8IDYxOCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0K
PiA+ICBkcml2ZXJzL2lpby9maW5nZXJwcmludC9mcF90Y191c2IuaCAgICAgfCAxNDQgKysrKysr
KysNCj4gPiAgZHJpdmVycy9paW8vaW5kdXN0cmlhbGlvLWNvcmUuYyAgICAgICAgIHwgICA5ICsN
Cj4gPiAgaW5jbHVkZS9saW51eC9paW8vaWlvLmggICAgICAgICAgICAgICAgIHwgIDExICstDQo+
ID4gIGluY2x1ZGUvbGludXgvaWlvL3R5cGVzLmggICAgICAgICAgICAgICB8ICAxMCArDQo+ID4g
IDEyIGZpbGVzIGNoYW5nZWQsIDEwNDcgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4g
PiAgY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMvaWlvL2ZpbmdlcnByaW50L0tjb25maWcNCj4g
PiAgY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMvaWlvL2ZpbmdlcnByaW50L01ha2VmaWxlDQo+
ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL2lpby9maW5nZXJwcmludC9mcF90Yy5jDQo+
ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL2lpby9maW5nZXJwcmludC9mcF90Yy5oDQo+
ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL2lpby9maW5nZXJwcmludC9mcF90Y191c2Iu
Yw0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy9paW8vZmluZ2VycHJpbnQvZnBfdGNf
dXNiLmgNCj4gPiANCj4gDQoNCg==

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]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 6016 bytes --]

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
> 

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Baluta, Teodora]

T24gVmksIDIwMTQtMTItMjYgYXQgMTE6MTMgKzAwMDAsIEpvbmF0aGFuIENhbWVyb24gd3JvdGU6
DQo+IE9uIDE4LzEyLzE0IDE2OjUxLCBMYXJzLVBldGVyIENsYXVzZW4gd3JvdGU6DQo+ID4gQWRk
aW5nIFY0TCBmb2xrcyB0byBDYyBmb3IgbW9yZSBpbnB1dC4NCj4gVGhhbmtzIExhcnMgLSB3ZSBk
ZWZpbml0ZWx5IHdvdWxkIG5lZWQgdGhlIHY0bCBndXlzIHRvIGFncmVlIHRvIGEgZHJpdmVyIGxp
a2UNCj4gdGhpcyBnb2luZyBpbiBJSU8uIChub3QgdGhhdCBJJ20gY29udmluY2VkIGl0IHNob3Vs
ZCEpDQo+ID4gDQo+ID4gT24gMTIvMDgvMjAxNCAwMzoxMCBQTSwgQmFsdXRhLCBUZW9kb3JhIHdy
b3RlOg0KPiA+PiBIZWxsbywNCj4gPj4NCj4gPj4gT24gVmksIDIwMTQtMTItMDUgYXQgMDI6MTUg
KzAwMDAsIEpvbmF0aGFuIENhbWVyb24gd3JvdGU6DQo+ID4+PiBPbiAwNC8xMi8xNCAxMzowMCwg
VGVvZG9yYSBCYWx1dGEgd3JvdGU6DQo+ID4+Pj4gVGhpcyBwYXRjaHNldCBhZGRzIHN1cHBvcnQg
Zm9yIGZpbmdlcnByaW50IHNlbnNvcnMgdGhyb3VnaCB0aGUgSUlPIGludGVyZmFjZS4NCj4gPj4+
PiBUaGlzIHdheSB1c2Vyc3BhY2UgYXBwbGljYXRpb25zIGNvbGxlY3QgaW5mb3JtYXRpb24gaW4g
YSB1bmlmb3JtIHdheS4gQWxsDQo+ID4+Pj4gcHJvY2Vzc2luZyB3b3VsZCBiZSBkb25lIGluIHRo
ZSB1cHBlciBsYXllcnMgYXMgc3VnZ2VzdGVkIGluIFswXS4NCj4gPj4+Pg0KPiA+Pj4+IEluIG9y
ZGVyIHRvIHRlc3Qgb3V0IHRoaXMgcHJvcG9zYWwsIGEgbWluaW1hbCBpbXBsZW1lbnRhdGlvbiBm
b3IgVVBFSydzDQo+ID4+Pj4gVG91Y2hDaGlwIEZpbmdlcnByaW50IFNlbnNvciB2aWEgVVNCIGlz
IGFsc28gYXZhaWxhYmxlLiBBbHRob3VnaCB0aGVyZSBpcyBhbg0KPiA+Pj4+IGV4aXN0aW5nIGlt
cGxlbWVudGF0aW9uIGluIHVzZXJzcGFjZSBmb3IgVVNCIGZpbmdlcnByaW50IGRldmljZXMsIGlu
Y2x1ZGluZyB0aGlzDQo+ID4+Pj4gcGFydGljdWxhciBkZXZpY2UsIHRoZSBkcml2ZXIgcmVwcmVz
ZW50cyBhIHByb29mIG9mIGNvbmNlcHQgb2YgaG93IGZpbmdlcnByaW50DQo+ID4+Pj4gc2Vuc29y
cyBjb3VsZCBiZSBpbnRlZ3JhdGVkIGluIHRoZSBJSU8gZnJhbWV3b3JrIHJlZ2FyZGxlc3Mgb2Yg
dGhlIHVzZWQgYnVzLiBGb3INCj4gPj4+PiBsb3dlciBwb3dlciByZXF1aXJlbWVudHMsIHRoZSBT
UEkgYnVzIGlzIHByZWZlcnJlZCBhbmQgYSBrZXJuZWwgZHJpdmVyDQo+ID4+Pj4gaW1wbGVtZW50
YXRpb24gbWFrZXMgbW9yZSBzZW5zZS4NCj4gPj4+DQo+ID4+PiBTbyB3aHkgbm90IHY0bD8gIFRo
ZXNlIGFyZSBlZmZlY3RpdmVseSBpbWFnZSBzZW5zb3JzLi4NCj4gPj4NCj4gPj4gV2VsbCwgaGVy
ZSdzIHdoeSBJIGRvbid0IHRoaW5rIHY0bCB3b3VsZCBiZSB0aGUgYmVzdCBvcHRpb246DQo+ID4+
DQo+ID4+IC0gYW4gaW1hZ2Ugc2Nhbm5lciBjb3VsZCBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgdjRs
IHN1YnN5c3RlbSwgYnV0IGl0DQo+ID4+IHNlZW1zIGZhciBtb3JlIGNvbXBsaWNhdGVkIGZvciBh
IHNpbXBsZSBmaW5nZXJwcmludCBzY2FubmVyIC0gaXQgdXN1YWxseQ0KPiA+PiBoYXMgZHJpdmVy
cyBmb3Igd2ViY2FtcywgVFZzIG9yIHZpZGVvIHN0cmVhbWluZyBkZXZpY2VzLiBUaGUgdjRsDQo+
ID4+IHN1YnN5c3RlbSAod2l0aCBhbGwgaXRzIHN1cHBvcnQgZm9yIGNvbG9yc3BhY2UsIGRlY29k
ZXJzLCBpbWFnZQ0KPiA+PiBjb21wcmVzc2lvbiwgZnJhbWUgY29udHJvbCkgc2VlbXMgYSBiaXQg
b2YgYW4gb3ZlcmtpbGwgZm9yIGEgdmVyeQ0KPiA+PiBzdHJhaWdodGZvcndhcmQgZmluZ2VycHJp
bnQgaW1hZ2luZyBzZW5zb3IuDQo+IFdoaWxzdCB0aG9zZSBhcmUgdGhlcmUsIEkgd291bGQgZG91
YnQgdGhlIGlycmVsZXZhbnQgYml0cyB3b3VsZCBwdXQgbXVjaA0KPiBidXJkZW4gb24gYSBmaW5n
ZXJwcmludCBzY2FubmluZyBkcml2ZXIuICBCZWVuIGEgd2hpbGUgc2luY2UgSSBkaWQNCj4gYW55
dGhpbmcgaW4gdGhhdCBhcmVhIHRob3VnaCBzbyBJIGNvdWxkIGJlIHdyb25nIQ0KPiA+Pg0KPiA+
PiAtIGEgZmluZ2VycHJpbnQgZGV2aWNlIGNvdWxkIGFsc28gc2VuZCBvdXQgYSBwcm9jZXNzZWQg
aW5mb3JtYXRpb24sIG5vdA0KPiA+PiBqdXN0IHRoZSBpbWFnZSBvZiBhIGZpbmdlcnByaW50LiBU
aGlzIG1lYW5zIHRoYXQgdGhlIHByb2Nlc3NpbmcgaXMgZG9uZQ0KPiA+PiBpbiBoYXJkd2FyZSAt
IHRoZSBVUEVLIFRvdWNoU3RyaXAgY2hpcHNldCBpbiBsaWJmcHJpbnQgaGFzIHRoaXMgYmVoYXZp
b3INCj4gPj4gKHNlZSBbMF0pLiBTbywgdGhlIElJTyBmcmFtZXdvcmsgd291bGQgc3VwcG9ydCBh
IHVuaWZvcm0gd2F5IG9mIGhhbmRsaW5nDQo+ID4+IGZpbmdlcnByaW50IGRldmljZXMgdGhhdCBl
aXRoZXIgZG8gcHJvY2Vzc2luZyBpbiBzb2Z0d2FyZSBvciBpbg0KPiA+PiBoYXJkd2FyZS4NCj4g
VGhpcyBpcyBtb3JlIGludGVyZXN0aW5nLCBidXQgZG9lcyB0aGF0IG1hcCB3ZWxsIHRvIElJTyBz
dHlsZQ0KPiBjaGFubmVscyBhbnl3YXk/ICBJZiBub3Qgd2UgYXJlIGdvaW5nIHRvIGVuZCB1cCB3
aXRoIGEgd2hvbGUgbmV3DQo+IGludGVyZmFjZSB3aGljaCBldmVyIHN1YnN5c3RlbSBpcyB1c2Vk
IGZvciB0aGUgaW1hZ2Ugc2lkZSBvZiB0aGluZ3MuDQo+ID4+DQo+ID4+IFRoZSB3YXkgSSBzZWUg
aXQgbm93LCBmb3IgcHJvY2Vzc2VkIGZpbmdlcnByaW50IGluZm9ybWF0aW9uLCBhbiBJSU8NCj4g
Pj4gZGV2aWNlIGNvdWxkIGhhdmUgYW4gSUlPX0ZJTkdFUlBSSU5UIGNoYW5uZWwgd2l0aCBhIG1v
ZGlmaWVyIGFuZCBvbmx5DQo+ID4+IHRoZSBzZW5zaXRpdml0eSB0aHJlc2hvbGQgYXR0cmlidXRl
IHNldC4gV2Ugd291bGQgYWxzbyBuZWVkIHR3bw0KPiA+PiB0cmlnZ2Vyczogb25lIGZvciBlbnJv
bGxtZW50IGFuZCBvbmUgZm9yIHRoZSB2ZXJpZmljYXRpb24gbW9kZSB0bw0KPiA+PiBjb250cm9s
IHRoZSBkZXZpY2UgZnJvbSBhIHVzZXJzcGFjZSBhcHBsaWNhdGlvbi4NCj4gU3VyZSAtIHdoYXQg
eW91IHByb3Bvc2VkIHdvdWxkIHdvcmsuICBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciBpdCBpcw0K
PiB0aGUgYmVzdCB3YXkgdG8gZG8gaXQuDQoNCkFueSB0aG91Z2h0cyBvbiB0aGlzIGZyb20gdGhl
IHY0bCBjb21tdW5pdHk/DQoNClRoYW5rcywNClRlb2RvcmENCg0KPiANCj4gDQo+ID4+DQo+ID4+
IFRoYW5rcywNCj4gPj4gVGVvZG9yYQ0KPiA+Pg0KPiA+PiBbMF0gaHR0cDovL3d3dy5mcmVlZGVz
a3RvcC5vcmcvd2lraS9Tb2Z0d2FyZS9mcHJpbnQvbGliZnByaW50L3VwZWt0cy8NCj4gPj4NCj4g
Pj4NCj4gPj4+Pg0KPiA+Pj4+IEEgc3lzZnMgdHJpZ2dlciBpcyBlbmFibGVkIGFuZCB0aGUgZGV2
aWNlIHN0YXJ0cyBzY2FubmluZy4gQXMgc29vbiBhcyBhbiBpbWFnZQ0KPiA+Pj4+IGlzIGF2YWls
YWJsZSBpdCBpcyB3cml0dGVuIGluIHRoZSBjaGFyYWN0ZXIgZGV2aWNlIC9kZXYvaWlvOmRldmlj
ZVguDQo+ID4+Pj4NCj4gPj4+PiBVc2Vyc3BhY2UgYXBwbGljYXRpb25zIHdpbGwgYmUgYWJsZSB0
byBjYWxjdWxhdGUgdGhlIGV4cGVjdGVkIGltYWdlIHNpemUgdXNpbmcNCj4gPj4+PiB0aGUgZmlu
Z2VycHJpbnQgYXR0cmlidXRlcyBoZWlnaHQsIHdpZHRoIGFuZCBiaXQgZGVwdGguIE90aGVyIGF0
dHJpYnV0ZXMNCj4gPj4+PiBpbnRyb2R1Y2VkIGZvciB0aGUgZmluZ2VycHJpbnQgY2hhbm5lbCBp
biBJSU8gcmVwcmVzZW50IGluZm9ybWF0aW9uIHRoYXQgYWlkcyBpbg0KPiA+Pj4+IHRoZSBmaW5n
ZXJwcmludCBpbWFnZSBwcm9jZXNzaW5nLiBCZXNpZGVzIHRoZXNlLCB0aGUgcHJvcG9zZWQgaW50
ZXJmYWNlIG9mZmVycw0KPiA+Pj4+IHVzZXJzcGFjZSBhIHdheSB0byByZWFkIGEgZmVlZGJhY2sg
YWZ0ZXIgYSBzY2FuIChsaWtlIHRoZSBzd2lwZSB3YXMgdG9vIHNsb3cgb3INCj4gPj4+PiB0b28g
ZmFzdCkgdGhyb3VnaCBhIG1vZGlmaWVkIGZpbmdlcnByaW50X3N0YXR1cyBjaGFubmVsLg0KPiA+
Pj4+DQo+ID4+Pj4gWzBdIGh0dHA6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvbGludXgtaWlvL21z
ZzExNDYzLmh0bWwNCj4gPj4+Pg0KPiA+Pj4+IFRlb2RvcmEgQmFsdXRhICgzKToNCj4gPj4+PiAg
ICBpaW86IGNvcmU6IGFkZCBzdXBwb3J0IGZvciBmaW5nZXJwcmludCBkZXZpY2VzDQo+ID4+Pj4g
ICAgaWlvOiBjb3JlOiBjaGFuZ2UgY2hhbm5lbCdzIHN0b3JhZ2ViaXRzL3JlYWxiaXRzIHRvIHUz
Mg0KPiA+Pj4+ICAgIGlpbzogZmluZ2VycHJpbnQ6IGFkZCBmaW5nZXJwcmludCBzZW5zb3Igdmlh
IFVTQg0KPiA+Pj4+DQo+ID4+Pj4gICBEb2N1bWVudGF0aW9uL0FCSS90ZXN0aW5nL3N5c2ZzLWJ1
cy1paW8gfCAgNTEgKysrDQo+ID4+Pj4gICBkcml2ZXJzL2lpby9LY29uZmlnICAgICAgICAgICAg
ICAgICAgICAgfCAgIDEgKw0KPiA+Pj4+ICAgZHJpdmVycy9paW8vTWFrZWZpbGUgICAgICAgICAg
ICAgICAgICAgIHwgICAxICsNCj4gPj4+PiAgIGRyaXZlcnMvaWlvL2ZpbmdlcnByaW50L0tjb25m
aWcgICAgICAgICB8ICAxNSArDQo+ID4+Pj4gICBkcml2ZXJzL2lpby9maW5nZXJwcmludC9NYWtl
ZmlsZSAgICAgICAgfCAgIDUgKw0KPiA+Pj4+ICAgZHJpdmVycy9paW8vZmluZ2VycHJpbnQvZnBf
dGMuYyAgICAgICAgIHwgMTYyICsrKysrKysrKw0KPiA+Pj4+ICAgZHJpdmVycy9paW8vZmluZ2Vy
cHJpbnQvZnBfdGMuaCAgICAgICAgIHwgIDIyICsrDQo+ID4+Pj4gICBkcml2ZXJzL2lpby9maW5n
ZXJwcmludC9mcF90Y191c2IuYyAgICAgfCA2MTggKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysNCj4gPj4+PiAgIGRyaXZlcnMvaWlvL2ZpbmdlcnByaW50L2ZwX3RjX3VzYi5oICAgICB8
IDE0NCArKysrKysrKw0KPiA+Pj4+ICAgZHJpdmVycy9paW8vaW5kdXN0cmlhbGlvLWNvcmUuYyAg
ICAgICAgIHwgICA5ICsNCj4gPj4+PiAgIGluY2x1ZGUvbGludXgvaWlvL2lpby5oICAgICAgICAg
ICAgICAgICB8ICAxMSArLQ0KPiA+Pj4+ICAgaW5jbHVkZS9saW51eC9paW8vdHlwZXMuaCAgICAg
ICAgICAgICAgIHwgIDEwICsNCj4gPj4+PiAgIDEyIGZpbGVzIGNoYW5nZWQsIDEwNDcgaW5zZXJ0
aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4gPj4+PiAgIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2
ZXJzL2lpby9maW5nZXJwcmludC9LY29uZmlnDQo+ID4+Pj4gICBjcmVhdGUgbW9kZSAxMDA2NDQg
ZHJpdmVycy9paW8vZmluZ2VycHJpbnQvTWFrZWZpbGUNCj4gPj4+PiAgIGNyZWF0ZSBtb2RlIDEw
MDY0NCBkcml2ZXJzL2lpby9maW5nZXJwcmludC9mcF90Yy5jDQo+ID4+Pj4gICBjcmVhdGUgbW9k
ZSAxMDA2NDQgZHJpdmVycy9paW8vZmluZ2VycHJpbnQvZnBfdGMuaA0KPiA+Pj4+ICAgY3JlYXRl
IG1vZGUgMTAwNjQ0IGRyaXZlcnMvaWlvL2ZpbmdlcnByaW50L2ZwX3RjX3VzYi5jDQo+ID4+Pj4g
ICBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy9paW8vZmluZ2VycHJpbnQvZnBfdGNfdXNiLmgN
Cj4gPj4+Pg0KPiA+Pj4NCj4gPj4NCj4gPj4gTu+/ve+/ve+/ve+/ve+/vXLvv73vv71577+977+9
77+9Yu+/vVjvv73vv73Hp3bvv71e77+9Kd66ey5u77+9K++/ve+/ve+/ve+/vXvvv73vv70qIu+/
ve+/vV5u77+9cu+/ve+/ve+/vXrvv70a77+977+9aO+/ve+/ve+/ve+/vSbvv73vv70e77+9R++/
ve+/ve+/vWjvv70DKO+/vemaju+/vd2iaiLvv73vv70a77+9G23vv73vv73vv73vv73vv71677+9
3pbvv73vv73vv71m77+977+977+9aO+/ve+/ve+/vX7vv71tbWw9PQ0KPiA+Pg0KPiA+IA0KPiA+
IC0tIA0KPiA+IFRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1
bnN1YnNjcmliZSBsaW51eC1paW8iIGluDQo+ID4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1h
am9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcNCj4gPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRw
Oi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwNCj4gDQoNCg==

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]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 6991 bytes --]

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
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Baluta, Teodora]

SGksDQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5LCBTeWx3ZXN0ZXIhIEkgYW0gY29uc2lkZXJpbmcg
djRsMiBub3cgYW5kIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucy9jb21tZW50cyBiZWxvdy4NCg0KPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsaW51eC1paW8tb3duZXJAdmdlci5r
ZXJuZWwub3JnIFttYWlsdG86bGludXgtaWlvLQ0KPiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9u
IEJlaGFsZiBPZiBTeWx3ZXN0ZXIgTmF3cm9ja2kNCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkg
MTUsIDIwMTUgNzozOCBQTQ0KPiBUbzogQmFsdXRhLCBUZW9kb3JhOyBKb25hdGhhbiBDYW1lcm9u
DQo+IENjOiBNYXVybyBDYXJ2YWxobyBDaGVoYWI7IExhcnMtUGV0ZXIgQ2xhdXNlbjsgTGludXgg
S2VybmVsIE1haWxpbmcgTGlzdDsNCj4gbGludXgtaWlvOyBMTU1MOyBIYW5zIFZlcmt1aWwNCj4g
U3ViamVjdDogUmU6IFtSRkMgUEFUQ0ggMC8zXSBJbnRyb2R1Y2UgSUlPIGludGVyZmFjZSBmb3Ig
ZmluZ2VycHJpbnQgc2Vuc29ycw0KPiANCj4gT24gMTQvMDEvMTUgMTg6MTQsIEJhbHV0YSwgVGVv
ZG9yYSB3cm90ZToNCj4gPiBPbiBWaSwgMjAxNC0xMi0yNiBhdCAxMToxMyArMDAwMCwgSm9uYXRo
YW4gQ2FtZXJvbiB3cm90ZToNCj4gPj4gT24gMTgvMTIvMTQgMTY6NTEsIExhcnMtUGV0ZXIgQ2xh
dXNlbiB3cm90ZToNCj4gPj4+IEFkZGluZyBWNEwgZm9sa3MgdG8gQ2MgZm9yIG1vcmUgaW5wdXQu
DQo+ID4+DQo+ID4+IFRoYW5rcyBMYXJzIC0gd2UgZGVmaW5pdGVseSB3b3VsZCBuZWVkIHRoZSB2
NGwgZ3V5cyB0byBhZ3JlZSB0byBhDQo+ID4+IGRyaXZlciBsaWtlIHRoaXMgZ29pbmcgaW4gSUlP
LiAobm90IHRoYXQgSSdtIGNvbnZpbmNlZCBpdCBzaG91bGQhKQ0KPiA+Pg0KPiA+Pj4gT24gMTIv
MDgvMjAxNCAwMzoxMCBQTSwgQmFsdXRhLCBUZW9kb3JhIHdyb3RlOg0KPiA+Pj4+IEhlbGxvLA0K
PiA+Pj4+DQo+ID4+Pj4gT24gVmksIDIwMTQtMTItMDUgYXQgMDI6MTUgKzAwMDAsIEpvbmF0aGFu
IENhbWVyb24gd3JvdGU6DQo+ID4+Pj4+IE9uIDA0LzEyLzE0IDEzOjAwLCBUZW9kb3JhIEJhbHV0
YSB3cm90ZToNCj4gPj4+Pj4+IFRoaXMgcGF0Y2hzZXQgYWRkcyBzdXBwb3J0IGZvciBmaW5nZXJw
cmludCBzZW5zb3JzIHRocm91Z2ggdGhlIElJTw0KPiBpbnRlcmZhY2UuDQo+ID4+Pj4+PiBUaGlz
IHdheSB1c2Vyc3BhY2UgYXBwbGljYXRpb25zIGNvbGxlY3QgaW5mb3JtYXRpb24gaW4gYSB1bmlm
b3JtDQo+ID4+Pj4+PiB3YXkuIEFsbCBwcm9jZXNzaW5nIHdvdWxkIGJlIGRvbmUgaW4gdGhlIHVw
cGVyIGxheWVycyBhcyBzdWdnZXN0ZWQNCj4gaW4gWzBdLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IElu
IG9yZGVyIHRvIHRlc3Qgb3V0IHRoaXMgcHJvcG9zYWwsIGEgbWluaW1hbCBpbXBsZW1lbnRhdGlv
biBmb3INCj4gPj4+Pj4+IFVQRUsncyBUb3VjaENoaXAgRmluZ2VycHJpbnQgU2Vuc29yIHZpYSBV
U0IgaXMgYWxzbyBhdmFpbGFibGUuDQo+ID4+Pj4+PiBBbHRob3VnaCB0aGVyZSBpcyBhbiBleGlz
dGluZyBpbXBsZW1lbnRhdGlvbiBpbiB1c2Vyc3BhY2UgZm9yIFVTQg0KPiA+Pj4+Pj4gZmluZ2Vy
cHJpbnQgZGV2aWNlcywgaW5jbHVkaW5nIHRoaXMgcGFydGljdWxhciBkZXZpY2UsIHRoZSBkcml2
ZXINCj4gPj4+Pj4+IHJlcHJlc2VudHMgYSBwcm9vZiBvZiBjb25jZXB0IG9mIGhvdyBmaW5nZXJw
cmludCBzZW5zb3JzIGNvdWxkIGJlDQo+ID4+Pj4+PiBpbnRlZ3JhdGVkIGluIHRoZSBJSU8gZnJh
bWV3b3JrIHJlZ2FyZGxlc3Mgb2YgdGhlIHVzZWQgYnVzLiBGb3INCj4gPj4+Pj4+IGxvd2VyIHBv
d2VyIHJlcXVpcmVtZW50cywgdGhlIFNQSSBidXMgaXMgcHJlZmVycmVkIGFuZCBhIGtlcm5lbA0K
PiBkcml2ZXIgaW1wbGVtZW50YXRpb24gbWFrZXMgbW9yZSBzZW5zZS4NCj4gPj4+Pj4NCj4gPj4+
Pj4gU28gd2h5IG5vdCB2NGw/ICBUaGVzZSBhcmUgZWZmZWN0aXZlbHkgaW1hZ2Ugc2Vuc29ycy4u
DQo+ID4+Pj4NCj4gPj4+PiBXZWxsLCBoZXJlJ3Mgd2h5IEkgZG9uJ3QgdGhpbmsgdjRsIHdvdWxk
IGJlIHRoZSBiZXN0IG9wdGlvbjoNCj4gPj4+Pg0KPiA+Pj4+IC0gYW4gaW1hZ2Ugc2Nhbm5lciBj
b3VsZCBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgdjRsIHN1YnN5c3RlbSwgYnV0DQo+ID4+Pj4gaXQg
c2VlbXMgZmFyIG1vcmUgY29tcGxpY2F0ZWQgZm9yIGEgc2ltcGxlIGZpbmdlcnByaW50IHNjYW5u
ZXIgLSBpdA0KPiA+Pj4+IHVzdWFsbHkgaGFzIGRyaXZlcnMgZm9yIHdlYmNhbXMsIFRWcyBvciB2
aWRlbyBzdHJlYW1pbmcgZGV2aWNlcy4NCj4gPj4+PiBUaGUgdjRsIHN1YnN5c3RlbSAod2l0aCBh
bGwgaXRzIHN1cHBvcnQgZm9yIGNvbG9yc3BhY2UsIGRlY29kZXJzLA0KPiA+Pj4+IGltYWdlIGNv
bXByZXNzaW9uLCBmcmFtZSBjb250cm9sKSBzZWVtcyBhIGJpdCBvZiBhbiBvdmVya2lsbCBmb3Ig
YQ0KPiA+Pj4+IHZlcnkgc3RyYWlnaHRmb3J3YXJkIGZpbmdlcnByaW50IGltYWdpbmcgc2Vuc29y
Lg0KPiA+DQo+ID4+IFdoaWxzdCB0aG9zZSBhcmUgdGhlcmUsIEkgd291bGQgZG91YnQgdGhlIGly
cmVsZXZhbnQgYml0cyB3b3VsZCBwdXQNCj4gPj4gbXVjaCBidXJkZW4gb24gYSBmaW5nZXJwcmlu
dCBzY2FubmluZyBkcml2ZXIuICBCZWVuIGEgd2hpbGUgc2luY2UgSQ0KPiA+PiBkaWQgYW55dGhp
bmcgaW4gdGhhdCBhcmVhIHRob3VnaCBzbyBJIGNvdWxkIGJlIHdyb25nIQ0KPiANCj4gSU1PIFY0
TCBpcyBtdWNoIGJldHRlciBmaXQgZm9yIHRoaXMga2luZCBvZiBkZXZpY2VzIHRoYW4gSUlPLiBZ
b3UgY2FuIHVzZSBqdXN0IGENCj4gc3Vic2V0IG9mIHRoZSBBUEksIGl0IHNob3VsZG4ndCB0YWtl
IG11Y2ggZWZmb3J0IHRvIHdyaXRlIGEgc2ltcGxlDQo+IHY0bDIgY2FwdHVyZSBkcml2ZXIsIHN1
cHBvcnRpbmcgZml4ZWQgKHByb2JhYmx5IHZlbmRvci9jaGlwIHNwZWNpZmljKSBpbWFnZQ0KPiBm
b3JtYXQuICBJJ20gbm90IHN1cmUgaWYgaXQncyBiZXR0ZXIgdG8gdXNlIHRoZSB2NGwyIGNvbnRy
b2xzIFsxXSwgZGVmaW5lIGEgbmV3DQo+IHY0bDIgY29udHJvbHMgY2xhc3MgZm9yIHRoZSBmaW5n
ZXJwcmludCBzY2FubmVyIHByb2Nlc3NpbmcgZmVhdHVyZXMsIHJhdGhlciB0aGFuDQo+IHRyeWlu
ZyB0byBwYXNzIHJhdyBkYXRhIHRvIHVzZXIgc3BhY2UgYW5kIGludGVycHJldCBpdCB0aGVuIGlu
IHNvbWUgbGlicmFyeS4gIEkNCj4ga25vdyB0aGVyZSBoYXMgYmVlbiByZXNpc3RhbmNlIHRvIGFs
bG93aW5nIHBhc3NpbmcgdW5rbm93biBiaW5hcnkgYmxvYnMgdG8NCj4gdXNlciBzcGFjZSwgZHVl
IHRvIHBvc3NpYmxlIGFidXNlcy4NCj4gDQo+IFsxXSBEb2N1bWVudGF0aW9uL3ZpZGVvNGxpbnV4
L3Y0bDItY29udHJvbHMudHh0DQo+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICANClRoZSBmaW5nZXJwcmludCBzZW5zb3IgYWN0cyBtb3JlIGxp
a2UgYSBzY2FubmVyIGRldmljZSwgc28gdGhlIGNsb3Nlc3QgdHlwZSBpcyB0aGUgVjRMMl9DQVBf
VklERU9fQ0FQVFVSRS4gSG93ZXZlciwgdGhpcyBpcyBub3QgYSBwZXJmZWN0IG1hdGNoIGJlY2F1
c2UgdGhlIGRyaXZlciBvbmx5IHNlbmRzIGFuIGltYWdlLCBvbmNlLCB3aGVuIHRyaWdnZXJlZC4g
V291bGQgaXQgYmUgYSBiZXR0ZXIgYWx0ZXJuYXRpdmUgdG8gZGVmaW5lIGEgbmV3IGNhcGFiaWxp
dHkgdHlwZT8gT3IgaXQgd291bGQgYmUgYWNjZXB0YWJsZSB0byBzaW1wbHkgaGF2ZSBhIHZpZGVv
IGRldmljZSB3aXRoIG5vIGZyYW1lIGJ1ZmZlciBvciBmcmFtZSByYXRlIGFuZCB0aGUgdXNlciBz
cGFjZSBhcHBsaWNhdGlvbiB0byByZWFkIGZyb20gdGhlIGNoYXJhY3RlciBkZXZpY2UgL2Rldi92
aWRlb1g/DQoNCj4gPj4+PiAtIGEgZmluZ2VycHJpbnQgZGV2aWNlIGNvdWxkIGFsc28gc2VuZCBv
dXQgYSBwcm9jZXNzZWQgaW5mb3JtYXRpb24sDQo+ID4+Pj4gbm90IGp1c3QgdGhlIGltYWdlIG9m
IGEgZmluZ2VycHJpbnQuIFRoaXMgbWVhbnMgdGhhdCB0aGUgcHJvY2Vzc2luZw0KPiA+Pj4+IGlz
IGRvbmUgaW4gaGFyZHdhcmUgLSB0aGUgVVBFSyBUb3VjaFN0cmlwIGNoaXBzZXQgaW4gbGliZnBy
aW50IGhhcw0KPiA+Pj4+IHRoaXMgYmVoYXZpb3IgKHNlZSBbMF0pLiBTbywgdGhlIElJTyBmcmFt
ZXdvcmsgd291bGQgc3VwcG9ydCBhDQo+ID4+Pj4gdW5pZm9ybSB3YXkgb2YgaGFuZGxpbmcgZmlu
Z2VycHJpbnQgZGV2aWNlcyB0aGF0IGVpdGhlciBkbw0KPiA+Pj4+IHByb2Nlc3NpbmcgaW4gc29m
dHdhcmUgb3IgaW4gaGFyZHdhcmUuDQo+IA0KPiBZb3UgY2FuIHVzZSB0aGUgdjRsMiBjb250cm9s
cyBBUEkgZm9yIHRoYXQsIHdoaWNoIGFsc28gc3VwcG9ydHMgZXZlbnRzLg0KPiBUaGUgY29udHJv
bHMgY291bGQgYmUgbWFkZSByZWFkIG9ubHkuDQo+IEl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRv
IGxpc3Qgd2hhdCBraW5kIG9mIGZlYXR1cmVzIHRoZXNlIGNvdWxkIGJlLg0KDQpMb29raW5nIHRo
cm91Z2ggdGhlIGNvbnRyb2xzIEFQSSwgdGhleSBzZWVtIHRvIGJlIGEgZ29vZCBmaXQuDQoNCj4g
DQo+ID4+IFRoaXMgaXMgbW9yZSBpbnRlcmVzdGluZywgYnV0IGRvZXMgdGhhdCBtYXAgd2VsbCB0
byBJSU8gc3R5bGUNCj4gPj4gY2hhbm5lbHMgYW55d2F5PyAgSWYgbm90IHdlIGFyZSBnb2luZyB0
byBlbmQgdXAgd2l0aCBhIHdob2xlIG5ldw0KPiA+PiBpbnRlcmZhY2Ugd2hpY2ggZXZlciBzdWJz
eXN0ZW0gaXMgdXNlZCBmb3IgdGhlIGltYWdlIHNpZGUgb2YgdGhpbmdzLg0KPiA+Pj4+DQo+ID4+
Pj4gVGhlIHdheSBJIHNlZSBpdCBub3csIGZvciBwcm9jZXNzZWQgZmluZ2VycHJpbnQgaW5mb3Jt
YXRpb24sIGFuIElJTw0KPiA+Pj4+IGRldmljZSBjb3VsZCBoYXZlIGFuIElJT19GSU5HRVJQUklO
VCBjaGFubmVsIHdpdGggYSBtb2RpZmllciBhbmQNCj4gPj4+PiBvbmx5IHRoZSBzZW5zaXRpdml0
eSB0aHJlc2hvbGQgYXR0cmlidXRlIHNldC4gV2Ugd291bGQgYWxzbyBuZWVkDQo+ID4+Pj4gdHdv
DQo+ID4+Pj4gdHJpZ2dlcnM6IG9uZSBmb3IgZW5yb2xsbWVudCBhbmQgb25lIGZvciB0aGUgdmVy
aWZpY2F0aW9uIG1vZGUgdG8NCj4gPj4+PiBjb250cm9sIHRoZSBkZXZpY2UgZnJvbSBhIHVzZXJz
cGFjZSBhcHBsaWNhdGlvbi4NCj4gDQo+IFRoaXMgY291bGQgYmUgYWxsIHdlbGwgaGFuZGxlZCB3
aXRoIHRoZSB2NGwyIGNvbnRyb2xzLCBmb3IgaW5zdGFuY2Ugc2VlIHdoYXQNCj4gZmVhdHVyZXMg
YXJlIGF2YWlsYWJsZSBpbiB0aGUgQ2FtZXJhIEZsYXNoIGNvbnRyb2xzIHN1YnNldA0KPiANCj4g
aHR0cDovL2xpbnV4dHYub3JnL2Rvd25sb2Fkcy92NGwtZHZiLWFwaXMvZXh0ZW5kZWQtY29udHJv
bHMuaHRtbCNmbGFzaC0NCj4gY29udHJvbHMNCj4gDQo+ID4+IFN1cmUgLSB3aGF0IHlvdSBwcm9w
b3NlZCB3b3VsZCB3b3JrLiAgVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgaXQgaXMNCj4gPj4gdGhl
IGJlc3Qgd2F5IHRvIGRvIGl0Lg0KPiA+DQo+ID4gQW55IHRob3VnaHRzIG9uIHRoaXMgZnJvbSB0
aGUgdjRsIGNvbW11bml0eT8NCj4gDQo+IEkgd291bGQgdHJ5IGl0IHdpdGggVjRMMiwgaXQgc2Vl
bXMgdG8gbWUgbW9zdCBzdWl0YWJsZSBzdWJzeXN0ZW0gZm9yIHN1Y2gNCj4gZGV2aWNlcyB0byBt
ZS4gIFRoZSBxdWVzdGlvbiBpcyB3aGF0IGVuZHMgdXAgaW4gdGhlIGtlcm5lbCBhbmQgd2hhdCBp
biB1c2VyDQo+IHNwYWNlLiAgQW55d2F5IElNTyBWNEwyIEFQSSBpcyBxdWl0ZSBmbGV4aWJsZSB3
aXRoIHJlZ2FyZHMgdG8gdGhhdCwgZHVlIHRvDQo+IHdpZGUgcmFuZ2Ugb2YgZGV2aWNlcyBpdCBu
ZWVkcyB0byBjb3Zlci4NCj4gDQo+ID4+Pj4gWzBdDQo+ID4+Pj4gaHR0cDovL3d3dy5mcmVlZGVz
a3RvcC5vcmcvd2lraS9Tb2Z0d2FyZS9mcHJpbnQvbGliZnByaW50L3VwZWt0cy8NCj4gPj4+Pg0K
PiA+Pj4+Pj4gQSBzeXNmcyB0cmlnZ2VyIGlzIGVuYWJsZWQgYW5kIHRoZSBkZXZpY2Ugc3RhcnRz
IHNjYW5uaW5nLiBBcw0KPiA+Pj4+Pj4gc29vbiBhcyBhbiBpbWFnZSBpcyBhdmFpbGFibGUgaXQg
aXMgd3JpdHRlbiBpbiB0aGUgY2hhcmFjdGVyIGRldmljZQ0KPiAvZGV2L2lpbzpkZXZpY2VYLg0K
PiA+Pj4+Pj4NCj4gPj4+Pj4+IFVzZXJzcGFjZSBhcHBsaWNhdGlvbnMgd2lsbCBiZSBhYmxlIHRv
IGNhbGN1bGF0ZSB0aGUgZXhwZWN0ZWQNCj4gPj4+Pj4+IGltYWdlIHNpemUgdXNpbmcgdGhlIGZp
bmdlcnByaW50IGF0dHJpYnV0ZXMgaGVpZ2h0LCB3aWR0aCBhbmQgYml0DQo+ID4+Pj4+PiBkZXB0
aC4gT3RoZXIgYXR0cmlidXRlcyBpbnRyb2R1Y2VkIGZvciB0aGUgZmluZ2VycHJpbnQgY2hhbm5l
bCBpbg0KPiA+Pj4+Pj4gSUlPIHJlcHJlc2VudCBpbmZvcm1hdGlvbiB0aGF0IGFpZHMgaW4gdGhl
IGZpbmdlcnByaW50IGltYWdlDQo+ID4+Pj4+PiBwcm9jZXNzaW5nLiBCZXNpZGVzIHRoZXNlLCB0
aGUgcHJvcG9zZWQgaW50ZXJmYWNlIG9mZmVycw0KPiA+Pj4+Pj4gdXNlcnNwYWNlIGEgd2F5IHRv
IHJlYWQgYSBmZWVkYmFjayBhZnRlciBhIHNjYW4gKGxpa2UgdGhlIHN3aXBlIHdhcw0KPiB0b28g
c2xvdyBvciB0b28gZmFzdCkgdGhyb3VnaCBhIG1vZGlmaWVkIGZpbmdlcnByaW50X3N0YXR1cyBj
aGFubmVsLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFswXSBodHRwOi8vd3d3LnNwaW5pY3MubmV0L2xp
c3RzL2xpbnV4LWlpby9tc2cxMTQ2My5odG1sDQo+IA0KPiAtLQ0KPiBUbyB1bnN1YnNjcmliZSBm
cm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgtaWlvIiBpbiB0
aGUgYm9keQ0KPiBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZyBNb3Jl
IG1ham9yZG9tbyBpbmZvIGF0DQo+IGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWlu
Zm8uaHRtbA0K

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]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1834 bytes --]

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

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Baluta, Teodora]

SGkgRmxvcmlhbiwNCg0KVGhhbmtzIGZvciB0aGUgcmVwbHkhDQoNCk9uIFZpLCAyMDE1LTAxLTIz
IGF0IDE3OjQ2ICswMTAwLCBGbG9yaWFuIEVjaHRsZXIgd3JvdGU6DQo+IEhlbGxvIFRlb2RvcmEs
DQo+IA0KPiBPbiAyMy4wMS4yMDE1IDE0OjA1LCBCYWx1dGEsIFRlb2RvcmEgd3JvdGU6DQo+ID4g
VGhlIGZpbmdlcnByaW50IHNlbnNvciBhY3RzIG1vcmUgbGlrZSBhIHNjYW5uZXIgZGV2aWNlLCBz
byB0aGUNCj4gPiBjbG9zZXN0IHR5cGUgaXMgdGhlIFY0TDJfQ0FQX1ZJREVPX0NBUFRVUkUuIEhv
d2V2ZXIsIHRoaXMgaXMgbm90IGENCj4gPiBwZXJmZWN0IG1hdGNoIGJlY2F1c2UgdGhlIGRyaXZl
ciBvbmx5IHNlbmRzIGFuIGltYWdlLCBvbmNlLCB3aGVuDQo+ID4gdHJpZ2dlcmVkLiBXb3VsZCBp
dCBiZSBhIGJldHRlciBhbHRlcm5hdGl2ZSB0byBkZWZpbmUgYSBuZXcNCj4gPiBjYXBhYmlsaXR5
IHR5cGU/IE9yIGl0IHdvdWxkIGJlIGFjY2VwdGFibGUgdG8gc2ltcGx5IGhhdmUgYSB2aWRlbw0K
PiA+IGRldmljZSB3aXRoIG5vIGZyYW1lIGJ1ZmZlciBvciBmcmFtZSByYXRlIGFuZCB0aGUgdXNl
ciBzcGFjZQ0KPiA+IGFwcGxpY2F0aW9uIHRvIHJlYWQgZnJvbSB0aGUgY2hhcmFjdGVyIGRldmlj
ZSAvZGV2L3ZpZGVvWD8NCj4gU29ycnkgaWYgSSBqdW1wIGluIGhlcmUgcmlnaHQgaW4gdGhlIG1p
ZGRsZSBvZiB0aGlzIGRpc2N1c3Npb24sIGJ1dCBzb21lDQo+IHRpbWUgYWdvLCBJIHdyb3RlIGEg
ZmluZ2VycHJpbnQgc2Vuc29yIGRyaXZlciBmb3IgdGhlIFNpZW1lbnMgSUQgTW91c2UNCj4gKHN0
aWxsIHBhcnQgb2YgdGhlIGtlcm5lbCBBRkFJQ1QpIHdoaWNoIGFjdHMgYXMgYSBtaXNjIGRldmlj
ZSBhbmQganVzdA0KPiBjcmVhdGVzIGEgY2hhcmFjdGVyIGRldmljZSBub2RlIHRoYXQgY2FuIGJl
IHVzZWQgdG8gZGlyZWN0bHkgcmVhZCBhIFBHTQ0KPiBmaWxlLg0KDQpJIGFncmVlIHRoYXQgaXQg
d291bGQgYmUgdGhlIHNpbXBsZXN0IGFwcHJvYWNoIGlmIHlvdSB3YW50IGEgVVNCDQpmaW5nZXJw
cmludCBkcml2ZXIgaW4ga2VybmVsIHNwYWNlLCBidXQgSSB3YXMgbG9va2luZyBmb3IgYSB3YXkg
dG8NCnN1cHBvcnQgZmluZ2VycHJpbnQgZGV2aWNlcyByZWdhcmRsZXNzIG9mIGJ1cyAodGhlcmUn
cyBhbHNvIGZpbmdlcnByaW50DQpkZXZpY2VzIHRoYXQgdXNlIFNQSSkgYW5kIHByb3ZpZGUgYSBj
b21tb24gaW50ZXJmYWNlIGZvciB1c2VyIHNwYWNlDQphcHBsaWNhdGlvbnMuDQoNClRoZSBhY3R1
YWwgZHJpdmVyIGZvciBVUEVLJ3MgVG91Y2hDaGlwIHNlbnNvciBpcyBqdXN0IGEgcHJvb2Ygb2Yg
Y29uY2VwdA0Kb24gaG93IHRoZSBpbnRlcmZhY2Ugd291bGQgd29yaywgcmF0aGVyIHRoYW4gdGhl
IGZpbmFsIGdvYWwuIFRoZXJlJ3MNCmFscmVhZHkgYSBsaWJyYXJ5IHRoYXQgZW5hYmxlcyBVU0It
b25seSBmaW5nZXJwcmludCBkZXZpY2VzIChsaWJmcHJpbnQpLg0KPiANCj4gTWF5YmUgdGhpcyB3
b3VsZCBiZSBhIHNsaWdodGx5IHNpbXBsZXIgYXBwcm9hY2ggdGhhbiBwdWxsaW5nIGluIGFsbCB0
aGUNCj4gc3RyZWFtaW5nLW9wdGltaXplZCBmZWF0dXJlcyBvZiBWNEwyPw0KDQpJIGFncmVlIHRo
YXQgZm9yIGEgZmluZ2VycHJpbnQgZGV2aWNlLCB0aGUgVjRMMiBzdWJzeXN0ZW0gb2ZmZXJzIHRv
bw0KbXVjaCAodGhlIGluaXRpYWwgUkZDIGlzIGZvciBJSU8pLg0KDQpUaGFua3MsDQpUZW9kb3Jh
DQoNCg==

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