[fprint] elan patch + poc 0x903 and 0x0C03
Vasily Khoruzhick
anarsoul at gmail.com
Tue Jan 30 00:40:28 UTC 2018
I suggest improving enrollment procedure. It should stitch big image
from several small images and use it later for comparison (using
whatever algorithm - minutiae algo also may work).
On Mon, Jan 29, 2018 at 7:38 AM, 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
>>
> _______________________________________________
> fprint mailing list
> fprint at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
More information about the fprint
mailing list