Re: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@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
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
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 signature.asc Description: OpenPGP digital signature
RE: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors
Hi, Thanks for the reply, Sylwester! I am considering v4l2 now and I have some questions/comments below. -Original Message- From: linux-iio-ow...@vger.kernel.org [mailto:linux-iio- ow...@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 +, 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 +, 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
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 +, 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 +, 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
On Vi, 2014-12-26 at 11:13 +, 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 +, 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
Re: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors
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 +, 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���h�� �G���h�(�階�ݢj���m�z�ޖ���f���h���~�mml==
--
To unsubscribe from this list: send the line unsubscribe linux-iio in
the
Re: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors
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 +, 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���h�� �G���h�(�階�ݢj���m�z�ޖ���f���h���~�mml==
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
