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��������+%������w��{.n�����{��(��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
