[fprint] elan patch + poc 0x903 and 0x0C03
Igor Filatov
ia.filatov at gmail.com
Mon Jan 29 21:12:56 UTC 2018
I'm pretty sure it would need to be in C. You shouldn't need to REwrite a
lot of code. It would depend on the algorithm but I'm guessing libfprint
would interface with it pretty much like it does with nbis: get image from
driver, submit image to nbis to get minutiae, compare to saved minutiae (
https://github.com/iafilatov/libfprint/blob/elan/libfprint/img.c#L270 and
on). So assuming your algo is based on some kind of image similarity, you'd
need to, in a similar fashion, know how to build a reference image (that
covers a large area of the finger) and how to compare other images with it
(assuming you need to move and/or rotate).
On Mon, Jan 29, 2018 at 10:52 PM TeEmZe <timo at teemze.de> wrote:
> Hi,
>
>
>
> Let’s assume I’d like to take a look at it (I am indeed quite interested).
> Would I have to write the algorithm in C (I am, as mentioned, not quite
> good in C and I don’t think that C is the perfect language for algorithmic)?
> And would I have to rewrite the existing code or could I just replace a
> library?
>
>
>
> Kind regards,
>
>
>
> Timo
>
>
>
> *From:* Igor Filatov [mailto:ia.filatov at gmail.com]
> *Sent:* Monday, 29 January 2018 20:26
>
>
> *To:* Hans de Goede <hdegoede at redhat.com>
>
> *Cc:* konachan.700 at gmail.com; Sebastien Bechet <
> sebastien.bechet at osinix.com>; TeEmZe <timo at teemze.de>;
> fprint at lists.freedesktop.org
>
>
> *Subject:* Re: [fprint] elan patch + poc 0x903 and 0x0C03
>
>
>
> Well yes, treating these readers as swipe devices does seem awkward. But
> that was the only way of making it work short of implementing a new
> recognition algo, which seemed like too much at the time. In fact, the
> current one is also a 3rd party lib. The authors of libfprint have
> considered an alternative approach for smaller sensors but there weren't
> any usable libs (
> https://www.freedesktop.org/wiki/Software/fprint/libfprint/Imaging_performance/#possiblesolutions
> ).
>
>
>
> As for the stitching code, it assumes that frame height is small. A couple
> of px originally but works for a couple dozen px as well (but not *that*
> well). 96px is probably too much but you can try tweaking the frame margin.
> The height needs to be narrow enough for the stitching to work and wide
> enough to make sure there are no gaps, given the device's "frame rate". But
> even if that works, we're left with 96px of width which means you really
> need to make sure you enroll the same area of the finger which you verify...
>
>
>
> With a bit of getting used to, my 144x64 scanner works more or less ok for
> me. Could be better, but still. This is why I decided to keep working on
> this driver. But then, there's a driver for a 64x64 device (
> https://www.freedesktop.org/wiki/Software/fprint/libfprint/aes4000/) so
> why not?
>
>
>
>
>
> On Mon, Jan 29, 2018 at 5:38 PM Hans de Goede <hdegoede at redhat.com> wrote:
>
> Hi,
>
> On 23-01-18 22:58, Igor Filatov wrote:
> > I've updated the driver to support the devices known so far. Please see
> if it works for you. Please send me your logs if not. I've enabled all
> commands for all devices (except 0x4031 which I've enabled only on my
> 0x0907 -- no idea what it does, but the response is 0x01).
> >
> > There's a bit mask in each command which you can use to enable/disable
> commands for a particular device.
> >
> > As for calibration, the driver doesn't expect 0x03 because not all
> devices seem to return 0x03 or 0x01. Instead it will retry *only* if the
> response is 0x03 and until it's different.
> >
> > I've enabled reset & fuse load for my device. Although I haven't seen it
> done by the original driver, it doesn't seem to hurt. So please see if it
> cause problems for you. Let's disable it only for devices where it does.
> >
> > https://github.com/iafilatov/libfprint
>
> This works for me with both the 0c16 and 0c26 readers I've access too.
>
> But we really need someone (any takers?) to implement a different type
> of recognition algorithm for these, not using minutia and then not treat
> them as swipe readers. Basically what we need is some form of image
> correlation
> algorithm. Perhaps the stitching code (which does not seem to do a very
> good
> job IMHO) can be used, to see if 2 images can be made to mostly overlap
> with an acceptable shift.
>
> Note that when I last looking into this I did a quick duckduckgo search
> on low resolution fingerprint recognition and there are a number of
> academic papers on how this can be done using image correlation, so
> ideally some-one would go and implement something like this.
>
> Regards,
>
> Hans
>
> > On Fri, Jan 19, 2018 at 3:33 PM TeEmZe <timo at teemze.de <mailto:
> timo at teemze.de>> wrote:
> >
> > Hi,
> >
> > Sadly I won't be able to get the data until next week, as I
> currently don't have access to the Laptop. I'll notify you as soon as I
> manage to get the data.
> >
> > Regards,
> >
> > Timo
> >
> > -----Original Message-----
> > From: Hans de Goede [mailto:hdegoede at redhat.com <mailto:
> hdegoede at redhat.com>]
> > Sent: Thursday, 18 January 2018 16:14
> > To: Sebastien Bechet <sebastien.bechet at osinix.com <mailto:
> sebastien.bechet at osinix.com>>; Igor Filatov <ia.filatov at gmail.com <mailto:
> ia.filatov at gmail.com>>
> > Cc: TeEmZe <timo at teemze.de <mailto:timo at teemze.de>>;
> konachan.700 at gmail.com <mailto:konachan.700 at gmail.com>;
> fprint at lists.freedesktop.org <mailto:fprint at lists.freedesktop.org>
> > Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03
> >
> > Hi,
> >
> > On 18-01-18 16:03, Sebastien Bechet wrote:
> > > Thank you Igor. Hans, you can try again with last version.
> >
> > Not tested, but looking at the code, it will loop in the
> calibration, my 2 devices both need a:
> >
> > if (result == 0x03) break;
> >
> > Directly after the:
> >
> > printf("Calibration Status: 0x%x\n", result);
> >
> > Line, currently the code only checks for result == 0x03 for the
> result of the get_cmd_status command, while it should check (for my
> devices) the result of the get_cmd_calibration command.
> >
> > Regards,
> >
> > Hans
> >
> >
> >
> > >
> > > I also tried to remove reset+fuseload then calibration not working
> > > anymore for 0x0903. It seems it is a part for calibration (same
> pdf
> > > file for reset _and_ calibration or .... reset _then_
> calibration?).
> > >
> > > https://github.com/sbechet/elanfp
> > >
> > > Konata and timo, can you give us width, height, firmware version
> and
> > > calibration status using elanfp.c please?
> >
> >
> > >
> > >
> > >
> > > Le jeudi 18 janvier 2018 à 14:02 +0000, Igor Filatov a écrit :
> > >>> square and seems to contain the image 3 times
> > >> Could be because convert is hardcoded at 96x96.
> > >>
> > >> On Thu, 18 Jan 2018, 12:04 Hans de Goede, <hdegoede at redhat.com
> <mailto:hdegoede at redhat.com>>
> > >> wrote:
> > >>> Hi,
> > >>>
> > >>> On 18-01-18 10:48, Sébastien Béchet wrote:
> > >>>> On 17-01-18 19:21, Igor Filatov wrote:
> > >>>>> We didn't have the spec before so I had no idea how different
> > >>> devices worked. Especially given that some commands which worked
> > >>> fine for me produced errors one other devices. Now that we have
> the
> > >>> docs I'll work on adapting the driver. Naturally, any info you
> have
> > >>> is welcome and so is any help with testing.
> > >>>>
> > >>>> I have done the [synthesis](
> https://github.com/sbechet/elanfp/blo
> > >>> b/master/README.md) about all informations we have a prepare
> > >>> questions for KT.
> > >>>
> > >>> My 0x0c16 id reader has firmware version 1.56, resolution 96x96
> > >>>
> > >>> I also have bought a stand-alone USB reader for when I would
> find
> > >>> time to work on this, this has an usb-id of: 0x0c26.
> > >>>
> > >>> After aking these changes:
> > >>>
> > >>> --- elanfp.c~ 2018-01-18 10:58:59.919912347 +0100
> > >>> +++ elanfp.c 2018-01-18 11:01:50.346280668 +0100
> > >>> @@ -71,7 +71,8 @@
> > >>> (desc.idVendor == 0x04f3) && (desc.idProduct
> ==
> > >>> 0x0903) ||
> > >>> (desc.idVendor == 0x04f3) && (desc.idProduct
> ==
> > >>> 0x0907) ||
> > >>> (desc.idVendor == 0x04f3) && (desc.idProduct
> ==
> > >>> 0x0c03) ||
> > >>> - (desc.idVendor == 0x04f3) && (desc.idProduct ==
> > >>> 0x0c16) ) {
> > >>> + (desc.idVendor == 0x04f3) && (desc.idProduct ==
> > >>> 0x0c16) ||
> > >>> + (desc.idVendor == 0x04f3) && (desc.idProduct ==
> > >>> 0x0c26) ) {
> > >>> r0 = 0;
> > >>> printf("Device with vid %x pid %x found.\n",
> > >>> desc.idVendor, desc.idProduct);
> > >>> break;
> > >>> @@ -156,7 +157,7 @@
> > >>> printf("CMD Get Image Size sent\n");
> > >>> }
> > >>> r0 = libusb_bulk_transfer(handle, BULK_EP3_IN, img_buf,
> 4,
> > >>> &transferred, 0);
> > >>> - printf("Width x height = %dx%d\n", img_buf[0], img_buf[2]);
> > >>> + printf("Width x height = %dx%d\n", (unsigned
> char)img_buf[0],
> > >>> (unsigned char)img_buf[2]);
> > >>>
> > >>> /* calibration */
> > >>>
> > >>> @@ -180,6 +181,7 @@
> > >>> }
> > >>> r0 = libusb_bulk_transfer(handle, BULK_EP3_IN,
> &result,
> > >>> 1, &transferred, 0);
> > >>> printf("Calibration Status: 0x%x\n", result);
> > >>> + if (result == 0x03) break;
> > >>>
> > >>> r0 = libusb_bulk_transfer(handle, BULK_EP1_OUT,
> > >>> get_cmd_status, 2, &transferred, 0);
> > >>> if((r0 == 0) && (transferred == 2)) {
> > >>>
> > >>> This one works with the POC too, although for some reason the
> > >>> generated out.png is square and seems to contain the image 3
> times?
> > >>>
> > >>> This one has firmware version 1.64, resolution 64x144 and as
> shown
> > >>> in the necessary changes this one does report a calibration
> status
> > >>> of 0x03 when it is done with the calibration, I think we should
> add
> > >>> an extra column for this to the hardware report table.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Hans
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fprint/attachments/20180129/d8233847/attachment-0001.html>
More information about the fprint
mailing list