from:"Igor Filatov"

[fprint] Elan 0x0907 driver

2017-10-18 Thread Igor Filatov

Hi list,

I've written a driver for Elan 0x0907 fp scanner. I don't know which
model it is but it's marketed under various names for ex. Cobo C2
https://hardzone.es/app/uploads/2017/04/Cobo-C2-01.jpg. You can get it
on AliExpress for about $25.

https://github.com/iafilatov/libfprint/commit/e19f7e339c65e5d001f3117b4a3308ee9234e492

It seems to work in general but there are some issues. First, it's
technically a touch sensor but the images it produces are so small I
never got more than 5 minutiae from them. So I'm using it as a swipe
device instead. But it needs a steady swipe to produce a relatively
decent image (I'm getting best results when staring the swipe from the
finger tip). And I suspect that the motion compensation subroutines
weren't built for this kind of use so the image has rough edges which
could harden minutiae detection (dunno, it's my guess). I had to lower
the threshold to 20.

I'd really appreciate feedback about the driver. I wonder if it's
worth trying to improve the image assembling logic to get more
reliable verification.
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] How can I add a new fingerprint reader?

2017-11-08 Thread Igor Filatov

Hi Konata,

The commands your reader uses look similar to the ones from an Elan
reader 0x04f3:0x0907
that I wrote a driver for some time ago.

https://lists.freedesktop.org/archives/fprint/2017-October/000892.html
https://github.com/iafilatov/libfprint/blob/elan/libfprint/drivers/elan.h
https://github.com/iafilatov/libfprint/blob/elan/libfprint/drivers/elan.c

It's possible that your reader uses the same or a similar protocol.
The ins and outs are the same
and it also has 2-byte "pixels" in raw data.

Try adding your pid to id_table and see if it works. You'll also need
to tweak ELAN_RAW_FRAME_*
and ELAN_FRAME_* (see elan_save_frame for why there are 2 sets of
dimensions). Also note
that the driver tries to use the device as a swipe sensor because the
images are too small. If
everything else works, you can try tweaking ELAN_MIN(MAX)_FRAMES - if
it's 1 and 1,
it _should_ behave as a touch sensor.

Good luck!

On Wed, Nov 8, 2017 at 10:16 AM Konata Izumi  wrote:
>
> Hello!
>
> I have a laptop with a Elan fingerprint reader:
>
> vid 0x04f3 pid 0x0c03
>
> I wrote a standalone app for reading fingerprints from reader,
> but i don't know what can i do to add a reader driver support to the fprintd 
> library.
>
> Please, help me add this driver to library.
>
> Code in attach.
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] USB ID 04f3:0903 "Elan Microelectronics Corp."

2017-11-08 Thread Igor Filatov

> When I dump USB bus, i only see these cmds :
> - init = cmd 000c give 60006000 as answer (96x96)  (response in 3)
> - read = cmd 0009 give image data in two parts (5184 bytes then 13376
> bytes) (response in 2)
> - wait = cmd 403f (response in 1)
> - ledof = cmd 000b (response in 1)


Hm, so 000c gives you the resolution. That's helpful. My response is
40009000. So it should be possible to write a generic driver for such
devices.

Are you observing USB traffic of the original driver? I think there
should also be a calibration of a couple of 4023 followed by 0009 to
read data and 4024 to save (names mine). Without it wait for finger
(403f) doesn't work correctly.

2017-11-08 16:39 GMT+02:00 Sebastien Bechet :
> Hello,
>
> I just discover Konata Izumi and Igor Filatov work
>
> Igor Filatov : 0x04f3:0x0907 (144x64 16 bits)
> Konata Izumi : 0x04f3:0x0c03 (96x96 16 bits)
>
> I have a : 0x04f3:0x903 (96x96 16 bits)
>
> And Konata Izmui elanfp.c work for me when changing 0x0c03 to 0x0903.
>
> When I dump USB bus, i only see these cmds :
> - init = cmd 000c give 60006000 as answer (96x96)  (response in 3)
> - read = cmd 0009 give image data in two parts (5184 bytes then 13376
> bytes) (response in 2)
> - wait = cmd 403f (response in 1)
> - ledof = cmd 000b (response in 1)
>
> For me 0x0903 and 0x0C03 are two versions of the same hardware.
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint



-- 
Igor Filatov
ia.fila...@gmail.com
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] USB ID 04f3:0903 "Elan Microelectronics Corp."

2017-11-08 Thread Igor Filatov

> 1. windows boot (000c*1, 0009*2, then 403f)

Those 009's could be the calibration. Could you send me your traces?
Also pls do one where you wait a few seconds after the led goes on
before putting the finger on the sensor.

> 2. record a fingerprint
> Windows driver do multiple cmd 9, then, 403f, then again with this
> pattern (I have done one try, i think it can change, with record
> quality) :

I noticed that when enrolling on win the device would keep scanning
the finger (4031, 403f, 0009, read, 4031... or just 0009, read, 0009,
read...) until you lift the finger, even after the enroll stage has
passed. The quality of raw images doesn't change so maybe the driver
does some stuff to improve them internally (or maybe it just
simplified their code...)



-- Forwarded message -
From: Sebastien Bechet 
Date: Wed, Nov 8, 2017 at 6:15 PM
Subject: Re: [fprint] USB ID 04f3:0903 "Elan Microelectronics Corp."
To: 


> Are you observing USB traffic of the original driver? I think there
> should also be a calibration of a couple of 4023 followed by 0009 to
> read data and 4024 to save (names mine). Without it wait for finger
> (403f) doesn't work correctly.

Yes of the original driver as explain here:
https://lists.freedesktop.org/archives/fprint/2017-March/000875.html
(I think it was 20160516-Elan driver)

I have done four traces:

1. windows boot (000c*1, 0009*2, then 403f)

2. record a fingerprint
Windows driver do multiple cmd 9, then, 403f, then again with this
pattern (I have done one try, i think it can change, with record
quality) :

cmd9*1 then 403f
cmd9*7 then ..
cmd9*7 then ..
*9 then ..
.8
7 7 7 7 7 7 7 1 1 5 7 6 6 6 1 4 7


3. test a fingerprint

cmd9*17 then 403f then 000b

4. windows shutdown

noop


I never see 4023 or 4024 cmd.


___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] USB ID 04f3:0903 "Elan Microelectronics Corp."

2017-11-08 Thread Igor Filatov

> Maybe I can try tomorrow.

Got your traces. I'll reply here so that the info is available on the list.

Ok, your traces already show that 403f and read is "wait for finger"
which returns 55 when finger is on. Just like the other devices we
have. Interestingly, there seem to be no separate calibration
commands. But it does 1 read at init and one before capture so maybe
those are used for calibration somehow (assuming the device needs it
but I think it does). And in general the device is less chatty.

Images are in 2 blocks probably because it's vbox+win and linux is
doing async io on USB so the entire image isn't retrieved in 1 read.
So that shouldn't count towards differences.

It also looks like your 'open' trace contains start of finger capture
(for enrollment of verification). Maybe you could instead trace the
moment when the device is plugged in separately? Unplug device, start
trace, plug in, stop trace. Then the capture separately: unplug
device, plug in device, wait 5 sec, start trace, unlock with fp, stop
trace. That would give a bit more info.

If you feel like it you could try adding your device to id_table in
elan.c and see if it works (remember to tweak dimensions in elan.h as
well). Maybe some extra commands the driver sends will just be ignored
by the device... The ones that matter are the same.

2017-11-08 18:54 GMT+02:00 Sebastien Bechet :
>> Those 009's could be the calibration. Could you send me your traces?
>
> Certainly, i send it to you in your private email.
>
>> Also pls do one where you wait a few seconds after the led goes on
>> before putting the finger on the sensor.
>
> mhmm, it's not simple for me to test again (2017 march rip).
> Maybe I can try tomorrow.
>
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint



-- 
Igor Filatov
ia.fila...@gmail.com
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] USB ID 04f3:0903 "Elan Microelectronics Corp."

2017-11-09 Thread Igor Filatov

> Maybe driver authors use device with [Focus > stacking](
https://en.wikipedia.org/wiki/Focus_stacking) ?

> Can it help to have more minutiae?

With these devices the scanned area is so small that not many minutiae can
be found there. I got like 5 o so with my finger and that's what I can
visually confirm looking at the scanned images. It's not about image
quality. I think original drivers could be using a different algorithm.

Looks like your device doesn't react normally to 402a (not unexpected).
It's the third init command in elan.h. Try removing it. Actually, you can
try removing all commands not found in you traces. Just don't remove the
arrays with commands for now, leave empty if needed.

It doesn't seem to complicated to adapt the driver based on your traces but
don't think I'll have any time for it soon…


On 9 Nov 2017 18:32, "Sébastien Béchet"  wrote:

As you ask, i tried [these changes](https://github.com/sb
echet/libfprint/commit/dd5275f8dcdc24e8d94a3b936516c4242d8bf008) for a
first try with `--enable-debug-log` in configure.

```
$ fprintd-list sbechet
found 1 devices
Device at /net/reactivated/Fprint/Device/0
Using device /net/reactivated/Fprint/Device/0
User sbechet has no fingers enrolled for ElanTech Fingerprint Sensor.
```

`journalctl -f` said:


```
nov. 09 17:23:09 mycomputer dbus-daemon[283]: [system] Activating via
systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
requested by ':1.233' (uid=1000 pid=2305 comm="fprintd-list sbechet ")
nov. 09 17:23:09 mycomputer fprintd[2306]: fp:debug [fp_init]
[...]
nov. 09 17:23:09 mycomputer fprintd[2306]: fp:debug [register_driver]
registered driver elan
nov. 09 17:23:09 mycomputer fprintd[2306]: fp:debug
[find_supporting_driver] driver elan supports USB device 04f3:0903
nov. 09 17:23:09 mycomputer fprintd[2306]: fp:debug
[find_supporting_driver] selected driver elan supports USB device 04f3:0903
```

Then I try enrollement:

```
$ fprintd-enroll
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
Enroll result: enroll-disconnected
```

journalctl:

```
nov. 09 17:27:35 mycomputer fprintd[2379]: user 'sbechet' claiming the
device: 0
nov. 09 17:27:35 mycomputer fprintd[2379]: async:debug [fp_async_dev_open]
nov. 09 17:27:35 mycomputer fprintd[2379]: now monitoring fd 15
nov. 09 17:27:35 mycomputer fprintd[2379]: device 0 claim status 0
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [dev_init]
nov. 09 17:27:35 mycomputer fprintd[2379]: async:debug
[fpi_drvcb_open_complete] status 0
nov. 09 17:27:35 mycomputer fprintd[2379]: start enrollment device 0 finger
7
nov. 09 17:27:35 mycomputer fprintd[2379]: async:debug
[fp_async_enroll_start] starting enrollment
nov. 09 17:27:35 mycomputer fprintd[2379]: fp:debug [generic_acquire_start]
action 1
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [dev_activate]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_dev_reset]
nov. 09 17:27:35 mycomputer fprintd[2379]: drv:debug [__ssm_call_handler]
0x55f20425fb70 entering state 0
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_run_cmds]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_run_next_cmd]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_cb]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_read]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_cb]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_done]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_run_next_cmd]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_cb]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_read]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_cb]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_done]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_run_next_cmd]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_cb]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_read]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_cb]
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [elan_cmd_cb]
unexpected transfer length
nov. 09 17:27:35 mycomputer fprintd[2379]: drv:debug [fpi_ssm_mark_aborted]
error -71 from state 0
nov. 09 17:27:35 mycomputer fprintd[2379]: drv:debug
[fpi_ssm_mark_completed] 0x55f20425fb70 completed with status -71
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [init_complete]
nov. 09 17:27:35 mycomputer fprintd[2379]: fp:debug
[fpi_imgdev_session_error] error -71
nov. 09 17:27:35 mycomputer fprintd[2379]: async:error
[fpi_drvcb_enroll_stage_completed] BUG at async.c:161
nov. 09 17:27:35 mycomputer fprintd[2379]: async:debug
[fpi_drvcb_enroll_stage_completed] result -71
nov. 09 17:27:35 mycomputer fprintd[2379]: enroll_stage_cb: result -71
nov. 09 17:27:35 mycomputer fprintd[2379]: elan:debug [dev_deinit]
nov. 09 17:27:35 mycomputer fprintd[2379]: async:debug
[fpi_drvcb_close_comp

Re: [fprint] Libfprint for Xiaomi

2018-01-08 Thread Igor Filatov

Hi Timo,

Unfortunately, libfprint doesn't support your reader. Elan devices
that I've seen people mention so far seem to have quite simple
protocols so it should be relatively easy to write one yourself if you
know some C (a bit harder if you don't). If you're willing to try I'm
sure people on this list will support you but I doubt that someone
will have the resources to write one on request.

2018-01-08 18:19 GMT+02:00 TeEmZe :
> Hello developers,
>
>
>
> I have a question regarding the libfprint library. I have a Xiaomi notebook
> with a fingerprint reader from Elan Microelectronics Corp (device 04f3:0c1a)
> running on Ubuntu. I already tried multiple packages for using it’s
> fingerprint device, but non detected it.
>
> Is it possible to use the libfprint library for this device? And if so, how
> do I use it?
>
> I’d be very thankful for a hint into the right direction, as I’m struggling
> with this problem for quite some while now.
>
> I’d also be ready to compile and test the driver on the laptop or help you
> otherwise as much as I can.
>
>
>
> Best regards
>
>
>
> Timo
>
>
>
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>



-- 
Igor Filatov
ia.fila...@gmail.com
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Libfprint for Xiaomi

2018-01-08 Thread Igor Filatov

You'll have to start by finding out how the device communicates with
the host. Probably the only feasible way to do it is capturing the
traffic under the original Windows driver. Doesn't matter if it's a
normal install or a VM. See
https://wiki.wireshark.org/CaptureSetup/USB. You'll need to find out
the commands the driver sends when you connect the device and during
the imaging phase and write a driver that would do the same. Easy,
right? :)

There's already a driver in libfprint for another Elan device
(https://cgit.freedesktop.org/libfprint/libfprint/tree/libfprint/drivers/elan.c)
and it's quite possible that your device needs similar commands. You
can use it as a reference. See elan.h for the commands and compare
them to what you see in your device traces. You can quickly hack up a
prototype in Python with pyusb
(https://github.com/pyusb/pyusb/blob/master/docs/tutorial.rst#lets-get-it-started)
or just use it to send commands and observe responses. The goal at
this point is to find out how to get an image from your scanner. Once
you can do it you're half way through. If your reader is similar to
the supported one, you could be 70% through.

Things might get complicated of course but much can be said until more
is known about your reader.

2018-01-08 19:17 GMT+02:00 TeEmZe :
> Hello,
>
> I'm willing to try it, but I don't know much C. I am however familiar with 
> programming in general (mainly Java and C#) and would be willing to learn the 
> necessary part of C to accomplish this.
> I do however not have unlimited access to the laptop with the reader, which 
> could increase the difficulty.
> I also have absolutely no idea at where to start, as I never did anything 
> like this before. Some help would be very much appreciated here.
>
> Cheers
>
> Timo
>
> -Original Message-
> From: Igor Filatov [mailto:ia.fila...@gmail.com]
> Sent: Monday, 8 January 2018 18:02
> To: TeEmZe 
> Cc: fprint@lists.freedesktop.org
> Subject: Re: [fprint] Libfprint for Xiaomi
>
> Hi Timo,
>
> Unfortunately, libfprint doesn't support your reader. Elan devices that I've 
> seen people mention so far seem to have quite simple protocols so it should 
> be relatively easy to write one yourself if you know some C (a bit harder if 
> you don't). If you're willing to try I'm sure people on this list will 
> support you but I doubt that someone will have the resources to write one on 
> request.
>
> 2018-01-08 18:19 GMT+02:00 TeEmZe :
>> Hello developers,
>>
>>
>>
>> I have a question regarding the libfprint library. I have a Xiaomi
>> notebook with a fingerprint reader from Elan Microelectronics Corp
>> (device 04f3:0c1a) running on Ubuntu. I already tried multiple
>> packages for using it’s fingerprint device, but non detected it.
>>
>> Is it possible to use the libfprint library for this device? And if
>> so, how do I use it?
>>
>> I’d be very thankful for a hint into the right direction, as I’m
>> struggling with this problem for quite some while now.
>>
>> I’d also be ready to compile and test the driver on the laptop or help
>> you otherwise as much as I can.
>>
>>
>>
>> Best regards
>>
>>
>>
>> Timo
>>
>>
>>
>>
>> ___
>> fprint mailing list
>> fprint@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/fprint
>>
>
>
>
> --
> Igor Filatov
> ia.fila...@gmail.com
>



-- 
Igor Filatov
ia.fila...@gmail.com
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-15 Thread Igor Filatov

Hi Sébastien, thanks for the patches!

I don't quite understand what happens though. You've replaced a number
of stages by plain image read commands (CALIBRATE, CAPTURE_START,
DEACTIVATE) which don't seem to do anything but read and discard the
image. Maybe it's fine to not do anything at all at those phases? My
scanner needed to "scan the air" a few times for calibration and such
reads always follow other specific commands (0x4023, 0x4024). Did you
try to just skip the reads instead?

Do 0903 and 0c03 have leds? If they do, how do you turn them on and off?

Also the orientation. IIRC 0903 is square. Do you swipe the finger on
it? Square sensors could cause problems because it's impossible to
know how they are oriented relatively to the user. Stitching of frames
could fail if the assumptions in the driver are wrong.


2018-01-15 17:34 GMT+02:00 Sébastien Béchet :
> Hello,
>
> I take time to create a POC for 04f3:0903 Elan Microelectronics Corp driver.
>
> I think it is working too for 0x0C03.
>
> Can someone test it (poc_0903_0C03.diff)?
>
> I found a bug in elan.c (see bugframesup30.diff) and a small typo
> (typo.diff).
>
> Thank you.
>
>
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>



-- 
Igor Filatov
ia.fila...@gmail.com
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-16 Thread Igor Filatov

Hi Sebastien,

Thanks for your work. Please try
https://github.com/iafilatov/libfprint/commit/fec2a1f3cffca1b1da2f9e379745db344bab2ab5
and see if it works for you. Also please tell me if you don't want
your email mentioned in the header.

2018-01-16 13:37 GMT+02:00 Sébastien Béchet :
> Hello Igor,
>
> On 2018-01-15 17:38, Igor Filatov wrote:
>>
>> I don't quite understand what happens though. You've replaced a number
>> of stages by plain image read commands (CALIBRATE, CAPTURE_START,
>> DEACTIVATE) which don't seem to do anything but read and discard the
>> image. Maybe it's fine to not do anything at all at those phases? My
>> scanner needed to "scan the air" a few times for calibration and such
>> reads always follow other specific commands (0x4023, 0x4024). Did you
>> try to just skip the reads instead?
>
>
> It is working when we skip the "scan the air" read command. Nevertheless the
> binary driver abuses the read: there must be a good reason? Do you think we
> can avoid calibrate_states?
>
>> Do 0903 and 0c03 have leds? If they do, how do you turn them on and off?
>
>
> - No LED for 04f3:0903. Device is integrated with the trackpad.
>   See here :
> https://dlcdnimgs.asus.com/websites/global/products/jlHvIhXRAPm1WpRr/V1/images/main/response.png
> - I don't know for 04f3:0c03. Konata?
> - BUT i have a good news: it seems 0x0b working. The bugframesup30.diff bug
> misled me (this is a _must_ patch)
>
>> Also the orientation. IIRC 0903 is square. Do you swipe the finger on
>> it? Square sensors could cause problems because it's impossible to
>> know how they are oriented relatively to the user. Stitching of frames
>> could fail if the assumptions in the driver are wrong.
>
>
> I tried examples / img_capture this morning. The orientation is good for
> 04f3:0903.
> Konata, can you try for 04f3:0c03?
>
> Igor, do you think i can try to adapt POC to orginal driver? What is the
> best solution?
>
> What do you think about this patch? Last problem for me is ELAN_FRAME_MARGIN
>
> Bye



-- 
Igor Filatov
ia.fila...@gmail.com
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-17 Thread Igor Filatov

Wow, thanks, Hans! This should be really useful. I'll take a closer look
later today.

On Wed, 17 Jan 2018, 09:57 Hans de Goede,  wrote:

> Hi Sébastien and Igor,
>
> I too have an Elan fingerprint reader tucked away in a corner
> of my touchpad, my model is: 04f3:0c16 .
>
> Since I've a contact inside Elantech from my work on touchpads,
> I've been communicating with them to get some specifications
> and they have provided me with some command reference info,
> which I'm allowed to share!  :
>
> https://fedorapeople.org/~jwrdegoede/elan-fingerprint/
>
> Unfortunately I have not yet had time to look at supporting
> my own reader and it does not look like I will have time for
> this soon. Still this should be helpful for you and Igor.
>
> Note that in calibration mode you are supposed to wait for the
> reader to give a certain reply rather then try X times.
>
> While I still hoping to have time for this soon I did ask
> some questions to clarify some things from the docs I got,
> the answers to which might be helpful:
>
> 1) Should the commands be executed in the order listed?
> [ELAN] : No, they are not sequence command.
> I think "Get image data(0x0009)" is the most important command for
> your developing.
>
> 2) The last 2 steps / commands get reg data / set reg are not exactly
> clear, do I need those at all?
> [ELAN] : No, they are used for control-register read/write. You don't need
> them, it's internal usage.
>
> 3) How should I get the actual image data when I'm done with the pre-scan
> polling?
> [ELAN]: You can use "get Image command ( 00 09)" to get Image data. (BTW,
> it's the ADC value, not offset value)
> Please refer to Pre_Scan_flow.pdf for more information.
>
> Sébastien, question, are you using yours in swipe mode, like Igor is?
>
> Regards,
>
> Hans
>
>
>
> On 16-01-18 17:09, Igor Filatov wrote:
> > Hi Sebastien,
> >
> > Thanks for your work. Please try
> >
> https://github.com/iafilatov/libfprint/commit/fec2a1f3cffca1b1da2f9e379745db344bab2ab5
> > and see if it works for you. Also please tell me if you don't want
> > your email mentioned in the header.
> >
> > 2018-01-16 13:37 GMT+02:00 Sébastien Béchet  >:
> >> Hello Igor,
> >>
> >> On 2018-01-15 17:38, Igor Filatov wrote:
> >>>
> >>> I don't quite understand what happens though. You've replaced a number
> >>> of stages by plain image read commands (CALIBRATE, CAPTURE_START,
> >>> DEACTIVATE) which don't seem to do anything but read and discard the
> >>> image. Maybe it's fine to not do anything at all at those phases? My
> >>> scanner needed to "scan the air" a few times for calibration and such
> >>> reads always follow other specific commands (0x4023, 0x4024). Did you
> >>> try to just skip the reads instead?
> >>
> >>
> >> It is working when we skip the "scan the air" read command.
> Nevertheless the
> >> binary driver abuses the read: there must be a good reason? Do you
> think we
> >> can avoid calibrate_states?
> >>
> >>> Do 0903 and 0c03 have leds? If they do, how do you turn them on and
> off?
> >>
> >>
> >> - No LED for 04f3:0903. Device is integrated with the trackpad.
> >>See here :
> >>
> https://dlcdnimgs.asus.com/websites/global/products/jlHvIhXRAPm1WpRr/V1/images/main/response.png
> >> - I don't know for 04f3:0c03. Konata?
> >> - BUT i have a good news: it seems 0x0b working. The bugframesup30.diff
> bug
> >> misled me (this is a _must_ patch)
> >>
> >>> Also the orientation. IIRC 0903 is square. Do you swipe the finger on
> >>> it? Square sensors could cause problems because it's impossible to
> >>> know how they are oriented relatively to the user. Stitching of frames
> >>> could fail if the assumptions in the driver are wrong.
> >>
> >>
> >> I tried examples / img_capture this morning. The orientation is good for
> >> 04f3:0903.
> >> Konata, can you try for 04f3:0c03?
> >>
> >> Igor, do you think i can try to adapt POC to orginal driver? What is the
> >> best solution?
> >>
> >> What do you think about this patch? Last problem for me is
> ELAN_FRAME_MARGIN
> >>
> >> Bye
> >
> >
> >
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-17 Thread Igor Filatov

Looks like o1ca as well https://github.com/iafilatov/libfprint/pull/4
I wonder if we can get a list of ids if devices like these.

2018-01-17 12:50 GMT+02:00 Sébastien Béchet :
> Hello,
>
> In attachment what I understood from the documentation.
>
> must work for
>
> 0x04f3,0x0903
> 0x04f3,0x0907
> 0x04f3,0x0C03
> 0x04f3,0x0C16
>
> Please try it.
>



-- 
Igor Filatov
ia.fila...@gmail.com
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-17 Thread Igor Filatov

For me this is either 0x01 or 0x03, just like in the docs. But I do
remember that I could never make it behave like Windows driver did, e.g.
return same values when I sent the same commands in the same order. But I
didn't know I had to give it some time, so that could be the problem.

And I've never seen the Win driver do reset or fuse load. I wonder what's
it for...

On Wed, Jan 17, 2018 at 4:59 PM Hans de Goede  wrote:

> Hi,
>
> On 17-01-18 14:46, Sébastien Béchet wrote:
> > Hello,
> >
> > I have done more test and find a functionnal calibration method.
> >
> > Strangely, the calibration return returns Mean_H and not the expected
> status. I need to read the "FP Status" register for the calibration to work
> in the next step.
> >
> > Also, i added 0x04f3:0x01cA to the test list.
> >
> > Hans, can you help us to find a recent list of ids?
> >
> > All work now for me:
> >
> > $ sudo ./elanfp
> > Device with vid 4f3 pid 903 found.
> > Config number is 1
> > CMD RESET sent
> > CMD Fuse Load sent
> > CMD VERSION sent
> > FP Bridge FW Version 1.53
> > CMD Get Image Size sent
> > width x height = 96x96
> > CMD Get Calibration Mean sent
> > calibration mean value: 33792 (0x8400)
> > CMD CALIBRATION sent
> > Calibration Status: 0x84
>
> So for me, this is actually 0x03 and if I don't
> add a break condition on this being 0x03 then
> the code never leaves the calibration loop for me,
> keep in minds that I asked Elan for docs for
> *my* model fingerprint reader, although all these
> are alike they are not 100% the same...
>
> With that all said, good job! With this one small
> change the program works for me.
>
> Regards,
>
> Hans
>
>
> > CMD STATUS sent
> > Status: 0x1
> > CMD Get Calibration Mean sent
> > calibration mean value: 256 (0x100)
> > CMD Wait For Finger sent
> > Received 0x55
> > CMD Get Image sent
> > Received 18432
> >
> >
> > If others confirm maybe Igor can modify the driver?
> >
> > On 2018-01-17 12:12, Igor Filatov wrote:
> >> Looks like o1ca as well https://github.com/iafilatov/libfprint/pull/4
> >> I wonder if we can get a list of ids if devices like these.
> >>
> >> 2018-01-17 12:50 GMT+02:00 Sébastien Béchet <
> sebastien.bec...@osinix.com>:
> >>> Hello,
> >>>
> >>> In attachment what I understood from the documentation.
> >>>
> >>> must work for
> >>>
> >>> 0x04f3,0x0903
> >>> 0x04f3,0x0907
> >>> 0x04f3,0x0C03
> >>> 0x04f3,0x0C16
> >>>
> >>> Please try it.
> >>>
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-17 Thread Igor Filatov

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.

On Wed, 17 Jan 2018, 20:13 TeEmZe,  wrote:

> Hi,
>
> I now logged the communication of the Windows driver in a VM on the Xiaomi
> Laptop with the fingerprint sensor 04F3:0C1A. It seems to use nearly the
> same commands as stated in the documentation Hans got. That means, I logged
> the process of enrolling a new fingerprint. Here it firstly send a 4031 (I
> don't know what that one does, as I couldn't find it in the commands doc
> Hans found), then a 403F (Pre-Scan), the device answered with 55 (object),
> then again the driver sent 4031, then 0009 (GET Image Data), to which the
> device probably answered with the image data. This repeated a few times and
> at the end the driver sent 000B (Stop).
>
> I don't know, how valuable this information is for you. Igor told me about
> a week ago, that I should build the driver on my own, but now you all seem
> to be into the development of a driver which works for me too. Is it even
> logical anymore for me to develop one on my own? And if not, can I be
> helpful otherwise, maybe with testing?
>
> I'd appreciate some response.
>
> Regards,
>
> Timo
>
> -Original Message-
> From: fprint [mailto:fprint-boun...@lists.freedesktop.org] On Behalf Of
> Hans de Goede
> Sent: Wednesday, 17 January 2018 16:26
> To: Igor Filatov 
> Cc: fprint@lists.freedesktop.org; Sébastien Béchet <
> sebastien.bec...@osinix.com>
> Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03
>
> Hi,
>
> On 17-01-18 16:22, Igor Filatov wrote:
> > For me this is either 0x01 or 0x03, just like in the docs. But I do
> remember that I could never make it behave like Windows driver did, e.g.
> return same values when I sent the same commands in the same order. But I
> didn't know I had to give it some time, so that could be the problem.
> >
> > And I've never seen the Win driver do reset or fuse load. I wonder
> what's it for...
>
> Right, I don't think those are necessary.
>
> Regards.
>
> Hans
>
>
>
> >
> > On Wed, Jan 17, 2018 at 4:59 PM Hans de Goede  <mailto:hdego...@redhat.com>> wrote:
> >
> > Hi,
> >
> > On 17-01-18 14:46, Sébastien Béchet wrote:
> >  > Hello,
> >  >
> >  > I have done more test and find a functionnal calibration method.
> >  >
> >  > Strangely, the calibration return returns Mean_H and not the
> expected status. I need to read the "FP Status" register for the
> calibration to work in the next step.
> >  >
> >  > Also, i added 0x04f3:0x01cA to the test list.
> >  >
> >  > Hans, can you help us to find a recent list of ids?
> >  >
> >  > All work now for me:
> >  >
> >  > $ sudo ./elanfp
> >  > Device with vid 4f3 pid 903 found.
> >  > Config number is 1
> >  > CMD RESET sent
> >  > CMD Fuse Load sent
> >  > CMD VERSION sent
> >  > FP Bridge FW Version 1.53
> >  > CMD Get Image Size sent
> >  > width x height = 96x96
> >  > CMD Get Calibration Mean sent
> >  > calibration mean value: 33792 (0x8400)
> >  > CMD CALIBRATION sent
> >  > Calibration Status: 0x84
> >
> > So for me, this is actually 0x03 and if I don't
> > add a break condition on this being 0x03 then
> > the code never leaves the calibration loop for me,
> > keep in minds that I asked Elan for docs for
> > *my* model fingerprint reader, although all these
> > are alike they are not 100% the same...
> >
> > With that all said, good job! With this one small
> > change the program works for me.
> >
> > Regards,
> >
> > Hans
> >
> >
> >  > CMD STATUS sent
> >  > Status: 0x1
> >  > CMD Get Calibration Mean sent
> >  > calibration mean value: 256 (0x100)
> >  > CMD Wait For Finger sent
> >  > Received 0x55
> >  > CMD Get Image sent
> >  > Received 18432
> >  >
> >  >
> >  > If others confirm maybe Igor can modify the driver?
> >  >
> >  > On 2018-01-17 12:12, Igor Filatov wrote:
> >  >> L

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-18 Thread Igor Filatov

> 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,  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/blob/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 making these changes:
>
> --- elanfp.c~   2018-01-18 10:58:59.919912347 +0100
> +++ elanfp.c2018-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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-23 Thread Igor Filatov

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


On Fri, Jan 19, 2018 at 3:33 PM TeEmZe  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:hdego...@redhat.com]
> Sent: Thursday, 18 January 2018 16:14
> To: Sebastien Bechet ; Igor Filatov <
> ia.fila...@gmail.com>
> Cc: TeEmZe ; konachan@gmail.com;
> fprint@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, 
> >> 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.c2018-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) ) {
> &

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-24 Thread Igor Filatov

I have a feeling that for 0903 commands 4023 and 4024 mean something
different. I-byte mean is weird. given 2-byte "pixels".

On Wed, 24 Jan 2018, 11:59 Sébastien Béchet, 
wrote:

> Hello Igor,
>
> This hack for firmware <= 0x0153 working.
>
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-24 Thread Igor Filatov

Sebastien,

Are you sure it's about firmware versions, not the devices themselves? Do
we have 0x0903 with different firmware?

On Wed, Jan 24, 2018 at 12:10 PM Sébastien Béchet <
sebastien.bec...@osinix.com> wrote:

> For sure.
>
> Better code in attachment (correctly remove 4024 access for 0903).
>
>
> On 2018-01-24 11:03, Igor Filatov wrote:
> > I have a feeling that for 0903 commands 4023 and 4024 mean something
> > different. I-byte mean is weird. given 2-byte "pixels".
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-24 Thread Igor Filatov

Updated the driver. Skipping calibration for 0x0903 till we know more. I'll
ask Kt soon but I need to prepare first because I have a few Qs of my own.

On Wed, Jan 24, 2018 at 4:33 PM Sébastien Béchet <
sebastien.bec...@osinix.com> wrote:

> I do not know. I am not the right person I updated the questions with
> our latest comments. Maybe you can ask directly kt@elan?
>
> see
> [questions](
> https://github.com/sbechet/elanfp/#preparation-of-questions-for-ktelan).
>
>
> On 2018-01-24 13:50, Igor Filatov wrote:
> > Sebastien,
> >
> > Are you sure it's about firmware versions, not the devices themselves?
> > Do we have 0x0903 with different firmware?
> >
> > On Wed, Jan 24, 2018 at 12:10 PM Sébastien Béchet
> >  wrote:
> >
> >> For sure.
> >>
> >> Better code in attachment (correctly remove 4024 access for 0903).
> >>
> >> On 2018-01-24 11:03, Igor Filatov wrote:
> >>> I have a feeling that for 0903 commands 4023 and 4024 mean
> >> something
> >>> different. I-byte mean is weird. given 2-byte "pixels".
>
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-26 Thread Igor Filatov

Hi Timo,

Please post the output of the command(s) that fail(s). For the driver
please run ./autogen.sh, then make, then examples/img_capture.

On Sat, 27 Jan 2018, 02:32 TeEmZe,  wrote:

> Hi,
>
>
>
> I tried running elanfp.c to get the device specifications Igor wanted,
> however I got back a *Segmentation fault *signal. Is it me who’s doing
> something wrong there?
>
> I also tried compiling / installing the driver from GitHub. However, when
> I run *./configure* I get back the message *No such file or directory*.
> How should I compile this project?
>
> I’d love to test the current state of the driver, but I’ll need some
> advice here.
>
>
>
> Regards,
>
>
>
> Timo
>
>
>
> *From:* Igor Filatov [mailto:ia.fila...@gmail.com]
> *Sent:* Tuesday, 23 January 2018 22:59
> *To:* Hans de Goede ; konachan@gmail.com;
> Sebastien Bechet ; TeEmZe 
> *Cc:* fprint@lists.freedesktop.org
>
>
> *Subject:* Re: [fprint] elan patch + poc 0x903 and 0x0C03
>
>
>
> 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
>
>
>
> On Fri, Jan 19, 2018 at 3:33 PM TeEmZe  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:hdego...@redhat.com]
> Sent: Thursday, 18 January 2018 16:14
> To: Sebastien Bechet ; Igor Filatov <
> ia.fila...@gmail.com>
> Cc: TeEmZe ; konachan@gmail.com;
> fprint@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 +, 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, 
> >> 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 firmwa

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-27 Thread Igor Filatov

Hi Timo, thanks for the logs!

Note to self: next time check spam folder when waiting for someone's logs.

Yes, it works, but your log shows that only 2 frames were captured. The
driver wants no less than 7 which is why capture has failed. Try a longer
swipe.

On a side note, The number is semi-arbitrary and I've picked it for my
device with the same narrow 64px sensor. It could make sense having a
smaller minimum for 96x96 sensors. So I'm asking you, gentlemen, to please
try and see how many frames are ok for a natural swipe on your devices.
Observe the size of the resulting image relative to the finger size and the
number of minutiae.

4031 turns on the LED. It's not needed on devices without one.

On another side note, day-to-day usage shows that sometimes a blinking LED
is the only indication that you need to scan your finger now...



On Sat, Jan 27, 2018 at 5:38 PM TeEmZe  wrote:

> Hi,
>
>
>
>
>
> Just for the case that the output of *elanfp.c* is still relevant:
>
>
>
> Device with vid 4f3 pid c1a found.
>
> Config number is 1
>
> CMD RESET sent
>
> CMD Fuse Load sent
>
> CMD VERSION sent
>
> FP Bridge FW Version 1.66
>
> CMD Get Image Size sent
>
> Width x Height = 64x144
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 7562 (0x1d8a)
>
> CMD CALIBRATION sent
>
> Calibration Status: 0x1
>
> CMD STATUS sent
>
> Status: 0xff
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 7562 (0x1d8a)
>
> CMD CALIBRATION sent
>
> Calibration Status: 0x1
>
> CMD STATUS sent
>
> Status: 0xff
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 7562 (0x1d8a)
>
> CMD CALIBRATION sent
>
> Calibration Status: 0x1
>
> CMD STATUS sent
>
> Status: 0xff
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 7562 (0x1d8a)
>
> CMD CALIBRATION sent
>
> Calibration Status: 0x1
>
> CMD STATUS sent
>
> Status: 0xff
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 7562 (0x1d8a)
>
> CMD CALIBRATION sent
>
> Calibration Status: 0x1
>
> CMD STATUS sent
>
> Status: 0xff
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 16383 (0x3fff)
>
> CMD CALIBRATION sent
>
> Calibration Status: 0x1
>
> CMD STATUS sent
>
> Status: 0xff
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 16383 (0x3fff)
>
> CMD CALIBRATION sent
>
> Calibration Status: 0x1
>
> CMD STATUS sent
>
> Status: 0xff
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 16383 (0x3fff)
>
> CMD CALIBRATION sent
>
> Calibration Status: 0x1
>
> CMD STATUS sent
>
> Status: 0xff
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 16383 (0x3fff)
>
> CMD CALIBRATION sent
>
> Calibration Status: 0x1
>
> CMD STATUS sent
>
> Status: 0xff
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 16383 (0x3fff)
>
> CMD CALIBRATION sent
>
> Calibration Status: 0x1
>
> CMD STATUS sent
>
> Status: 0xff
>
> CMD Get Calibration Mean sent
>
> calibration mean value: 2 (0x2)
>
> CMD Wait For Finger sent
>
> Received 0xa0
>
> CMD Get Image sent
>
> Received 18432
>
>
>
>
>
> It’s true that I said that 4031 was called before 403F, which actually was
> the case - here are my notes regarding this:
>
>
>
> -> 4031  ?
>
> -> 403F  Get Pre-Scan
>
> <- 55  1.3.3  Object
>
> -> 4031  ?
>
> -> 0009  Get Image Data
>
> <- ? 1.3.2  Image Data
>
> -> 0009  Get Image Data
>
> <- ? 1.3.2  Image Data
>
> -> 0009
>
> ...
>
> -> 4031
>
> -> 403F
>
> <- 55  1.3.3
>
> -> 4031
>
> -> 0009
>
> <- ?     1.3.2
>
> ...
>
> -> 4031
>
> -> 403F
>
> <- 55  1.3.3
>
> ...
>
> -> 4031
>
> -> 0009
>
> <- ?
>
> -> 000b
>
> -> 0009
>
> <- ?
>
> -> 4031
>
> ...
>
> -> 0009
>
> <- ?
>
> -> 000b Stop
>
>
>
>
>
> You say that it works – so haw exactl

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-27 Thread Igor Filatov

Yes, this time it worked. First of all, you should be able to open
finger.pgm in the same directory with an image viewer and see your finger.
Then you can try exmaples/enroll and examples/verify to enroll and verify
your fingerprint. If everything seems ok, install the driver with `sudo
make install`. You will need fprintd daemon and a PAM module for login,
sudo etc. On Debian/Ubuntu it's just `apt install libpam-fprintd`. Once
it's installed, run `fprintd-enroll`. That's it.

>
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-28 Thread Igor Filatov

1 out of 10 isn't practical so it shouldn't be like that. I'm getting
roughly 4 OKs out of 5 (which is still somewhat low and can be attributed
to the quality if images the scanner produces with swiping; I also have a
Validity sensor and it blows my Elan out of the water).

1. Try to get some visual feedback. There's a tool called fprint_demo. You
can enroll and verify there. It shows images and detected minutiae. There
aren't any good guidelines but in general try and see if the overall image
looks good. Areas where the frames intersect should look as seamless as
possible (seams produce false minutiae). The number of detected minutiae
should be at least over 30. If possible, please send images you get with
examples/img_capture. Which finger you scan doesn't matter (you can use
someone else's if you still happen to have one from Halloween).

2. These Elans need a slower and steadier swipe than dedicated swipe fp
readers. I mean the ones that were built for swipe. I think it takes me
about 3 seconds to do a swipe. Pay attention to the tip of the finger:
because the tip is curved it's hard to assemble a good image of it. I must
say it does take some practice...

On Sun, Jan 28, 2018 at 2:25 AM wp12880529-timo wp12880529-timo <
t...@teemze.de> wrote:

> Hi,
>
>
> the enroll process seems to work. However, when verifying it detects my
> finger in about 1 out of 10 tries. Is this a bug or is it normal?
>
>
> Regards
>
> Timo
>
> Igor Filatov  hat am 27. Januar 2018 um 18:52
> geschrieben:
>
>
> Yes, this time it worked. First of all, you should be able to open
> finger.pgm in the same directory with an image viewer and see your finger.
> Then you can try exmaples/enroll and examples/verify to enroll and verify
> your fingerprint. If everything seems ok, install the driver with `sudo
> make install`. You will need fprintd daemon and a PAM module for login,
> sudo etc. On Debian/Ubuntu it's just `apt install libpam-fprintd`. Once
> it's installed, run `fprintd-enroll`. That's it.
>
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
>
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-29 Thread Igor Filatov

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  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  t...@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:hdego...@redhat.com  hdego...@redhat.com>]
> > Sent: Thursday, 18 January 2018 16:14
> > To: Sebastien Bechet  sebastien.bec...@osinix.com>>; Igor Filatov  ia.fila...@gmail.com>>
> > Cc: TeEmZe mailto:t...@teemze.de>>;
> konachan@gmail.com <mailto:konachan@gmail.com>;
> fprint@lists.freedesktop.org <mailto:fprint@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,
> >
> >

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-29 Thread Igor Filatov

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  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.fila...@gmail.com]
> *Sent:* Monday, 29 January 2018 20:26
>
>
> *To:* Hans de Goede 
>
> *Cc:* konachan@gmail.com; Sebastien Bechet <
> sebastien.bec...@osinix.com>; TeEmZe ;
> fprint@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  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 a

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-30 Thread Igor Filatov

>From what I understand, you need to compare big images to big images for
the minutiae algo to work good. If the verification images are small, they
simply won't have enough minutiae.

I think Hans had a good point when he mentioned that the existing stitching
code could be used. libfprint has the advantage that it doesn't guarantee
interoperability between different scanners - that you can enroll with one
scanner and verify with another. It doesn't need to have a very generic
algorithm like the ones that academic papers focus on. The same device (and
we're not even talking about the same model - it's the same physical
device) produces very similar images all the time. There is already a
method to score an overlap of 2 images that's used for stitching. If the
rotation is taken care of, the rest should be possible. I was at some point
thinking whether minutiae can be used as sort of "anchor points" to find
approximate coordinates and angle (e.g. we have 3 similar minutiae which is
not enough to compare but we can match their coordinates on 2 scans and use
them to check for overlap).

This would still benefit greatly from an improved enrollment procedure,
though. I imagine the one where you tap the sensor instead of swiping, as
swiping stretches the skin and distorts the image. Such enrollment would
also need to compare frames along x, y and account for rotation...


On Tue, Jan 30, 2018 at 2:40 AM Vasily Khoruzhick 
wrote:

> 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 
> 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  >> <mailto:t...@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:hdego...@redhat.com
> >> <mailto:hdego...@redhat.com>]
> >> Sent: Thursday, 18 January 2018 16:14
> >> To: Sebastien Bechet  >> <mailto:sebastien.bec...@osinix.com>>; Igor Filatov <
> ia.fila...@gmail.com
> >> <mailto:ia.fila...@gmail.com>>
> >> Cc: TeEmZe mailto:t...@teemze.de>>;
> >> konachan@gmail.com <mailto:konachan@gmail.com>;
> >&

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-01-30 Thread Igor Filatov

Hi Timo,

Sure, give it a shot! And as I said earlier, remember that you don't need a
generic algo for any 2 fingerprints. The prints always come from the same
device.

On Tue, Jan 30, 2018 at 8:16 PM TeEmZe  wrote:

> Hi,
>
>
>
>
>
> I'll give it a shot in C, but will switch to Java before desperation.
>
> I'll try to implement the *Fingerprint Identification Using Cross
> Correlation of Field Orientation* – there are a few papers online.
>
> I’ll write a library which receives two images (the enrolled and the one
> to verify) and returns a number between 0 and 100 (the percentage of the
> match), while above 70 is considered a match.
>
>
>
> This might take a little bit of time, but I think I should be able to
> tackle this.
>
> Later I’ll need a few people to test it, obviously, and maybe a bit of
> help including it into the main project.
>
>
>
>
>
> Kind regards,
>
>
>
> Timo
>
>
>
> -Original Message-
> From: Hans de Goede [mailto:hdego...@redhat.com]
> Sent: Tuesday, 30 January 2018 10:39
> To: TeEmZe ; 'Igor Filatov' 
> Cc: konachan@gmail.com; 'Sebastien Bechet' <
> sebastien.bec...@osinix.com>; fprint@lists.freedesktop.org
> Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03
>
>
>
> Hi,
>
>
>
> On 29-01-18 21:52, TeEmZe 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?
>
>
>
> Ideally it would be in C and it would be stand-alone so that it can be
> added to libfprint as a second algorithm to use on low-res fp readers. But
> we don't need to get there in one step. If you are interested in working on
> this, and you can write something in say python which does a good job of
> matching and add some docs / comments clearly explaining all the steps of
> the algorithm you've come up with, then someone else can use that to
> implement the same algorithm in say C.
>
>
>
> We should probably also consider adding an external (C-lib) dependency for
> this to libfprint, rather then implementing everything needed from scratch,
> but that is all something to worry about later really. First we need a
> clearly described / documented algorithm which does a good job of matching
> (with example code please). Once we have that we can worry about
> integrating it into libfprint (IMHO).
>
>
>
> Regards,
>
>
>
> Hans
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
>
> > Kind regards,
>
> >
>
> > Timo
>
> >
>
> > *From:*Igor Filatov [mailto:ia.fila...@gmail.com ]
>
> > *Sent:* Monday, 29 January 2018 20:26
>
> > *To:* Hans de Goede 
>
> > *Cc:* konachan@gmail.com; Sebastien Bechet
>
> > ; TeEmZe ;
>
> > fprint@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  <mailto

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-02-04 Thread Igor Filatov

Hi everybody,

Base on the new info I got I've updated the driver in a few places:

1. Frames are cropped to 30px by height. I've received some examples of
images from 96px readers and it seems that the assembling procedure just
doesn't work for frames of greater height. I _think_ this is largely
because the skin stretches and deforms in a non-uniform way when you swipe.
E.g. the same part of the print is slightly different when it's near the
bottom of the frame than when it's near the top. Plus, there often seem to
be sensor artifacts near the edges, so.

2. Sensor reset is out. Devices do it when they power up. I'm not entirely
sure that it's absolutely not needed, though. I'm thinking about suspend &
resume, for one. But anyway, I've used my reader for long without any reset
and I'm suspending all the time and I haven't had any problems because of
it.

3. Some changes around calibration. You can get a calibration status of
0x01 (ongoing) and 0x03 (completed) from the device. But I've noticed that
very often the first response I get is 0x03, which later (~100 ms) changes
to 0x01, then back to 0x03. So now to make sure it actually completes, the
driver first wants to see 0x01 at least once and then it waits for 0x03.

4. KT has recommended a different frame extraction algo. First we subtract
the background which we got during calibration. This helps quite
significantly. Then we split values into 3 groups and apply a different
transformation to each group (see comments for detail). And this seems to
give slightly worse results on my reader than simple linear scaling like
there was before. So I've left both methods and it's possible to configure
the method for each device. YMMV.

Please see if it now works better/same/worse for you. I think verification
is now slightly better on my device but I need to use it for a couple of
days to know.

On Tue, Jan 30, 2018 at 8:31 PM Igor Filatov  wrote:

> Hi Timo,
>
> Sure, give it a shot! And as I said earlier, remember that you don't need
> a generic algo for any 2 fingerprints. The prints always come from the same
> device.
>
> On Tue, Jan 30, 2018 at 8:16 PM TeEmZe  wrote:
>
>> Hi,
>>
>>
>>
>>
>>
>> I'll give it a shot in C, but will switch to Java before desperation.
>>
>> I'll try to implement the *Fingerprint Identification Using Cross
>> Correlation of Field Orientation* – there are a few papers online.
>>
>> I’ll write a library which receives two images (the enrolled and the one
>> to verify) and returns a number between 0 and 100 (the percentage of the
>> match), while above 70 is considered a match.
>>
>>
>>
>> This might take a little bit of time, but I think I should be able to
>> tackle this.
>>
>> Later I’ll need a few people to test it, obviously, and maybe a bit of
>> help including it into the main project.
>>
>>
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> Timo
>>
>>
>>
>> -Original Message-
>> From: Hans de Goede [mailto:hdego...@redhat.com]
>> Sent: Tuesday, 30 January 2018 10:39
>> To: TeEmZe ; 'Igor Filatov' 
>> Cc: konachan@gmail.com; 'Sebastien Bechet' <
>> sebastien.bec...@osinix.com>; fprint@lists.freedesktop.org
>> Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03
>>
>>
>>
>> Hi,
>>
>>
>>
>> On 29-01-18 21:52, TeEmZe 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?
>>
>>
>>
>> Ideally it would be in C and it would be stand-alone so that it can be
>> added to libfprint as a second algorithm to use on low-res fp readers. But
>> we don't need to get there in one step. If you are interested in working on
>> this, and you can write something in say python which does a good job of
>> matching and add some docs / comments clearly explaining all the steps of
>> the algorithm you've come up with, then someone else can use that to
>> implement the same algorithm in say C.
>>
>>
>>
>> We should probably also consider adding an external (C-lib) dependency
>> for this to libfprint, rather then implementing everything needed from
>> scratch, but that is all something to worry about later really. First

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-02-09 Thread Igor Filatov

Hi Timo,

I've noticed this when working on the initial implementation - that rows at
bottom and top are bad (and I've seen a number of scans sent by different
people - it's never on the sides for some reason). That's why there was the
frame_margin param which means "cut this many px from top and bottom".
Actually, in recent commits this has changed and it just crops the frame to
max 50px by height. Since assembly doesn't really work for frames higher
than that.

But ultimately libfprint needs a different algo for small sensors. No
getting around it. Telling people they need to swipe even though they see
have a touch sensor isn't feasible and seems to already be failing in
practice. I've trained myself to swipe reliably but still... don't want to
spoil my karma with a driver that pretends to work but is hardly usable.



> Hi,
>>
>>
>>
>>
>>
>> I might actually have another solution.
>>
>> The fingerprint images, that are created by the swiping, are assembled
>> out of multiple images, the reader got, right?
>> I now realized that each of those images seems to have about one or two
>> rows of pixels at the top and at the bottom, which are simply black.
>> Those rows alter the image, so that similar fingers aren’t matching, as
>> the rows are at different positions in the image if the finger was moved
>> with a different speed – which is always the case.
>> So I think we should try changing the way we generate the image with the
>> swipe movement by cropping each image, of which the final image is
>> assembled, by two pixels at the top and the bottom.
>> I don’t know whether this solves all problems, but I can at imagine that
>> it’d at least improve it.
>> I am however still working on an alternative algorithm, which uses cross
>> correlation of field orientation, but I can imagine that this won’t be
>> necessary anymore.
>>
>>
>>
>> I don’t know the way you’re currently assembling the joined fingerprint
>> image, so maybe someone who does could give this a try?
>> I’ll be happy to test it afterwards.
>>
>>
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Timo
>>
>>
>>
>> *From:* fprint [mailto:fprint-boun...@lists.freedesktop.org] *On Behalf
>> Of *wp12880529-timo wp12880529-timo
>> *Sent:* Friday, 9 February 2018 03:30
>> *To:* Hans de Goede ; Sebastien Bechet <
>> sebastien.bec...@osinix.com>; Igor Filatov 
>> *Cc:* fprint@lists.freedesktop.org
>>
>>
>> *Subject:* Re: [fprint] elan patch + poc 0x903 and 0x0C03
>>
>>
>>
>> Hi Igor,
>>
>>
>>
>> I tried the new version, which doesn't seem to work significantly better
>> - it detects about 50% of the tries. I think the best solution will be
>> another algorithm, which I'm currently working on.
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Timo
>>
>> Igor Filatov  hat am 4. Februar 2018 um 16:07
>> geschrieben:
>>
>> Hi everybody,
>>
>>
>>
>> Base on the new info I got I've updated the driver in a few places:
>>
>>
>>
>> 1. Frames are cropped to 30px by height. I've received some examples of
>> images from 96px readers and it seems that the assembling procedure just
>> doesn't work for frames of greater height. I _think_ this is largely
>> because the skin stretches and deforms in a non-uniform way when you swipe.
>> E.g. the same part of the print is slightly different when it's near the
>> bottom of the frame than when it's near the top. Plus, there often seem to
>> be sensor artifacts near the edges, so.
>>
>>
>>
>> 2. Sensor reset is out. Devices do it when they power up. I'm not
>> entirely sure that it's absolutely not needed, though. I'm thinking about
>> suspend & resume, for one. But anyway, I've used my reader for long without
>> any reset and I'm suspending all the time and I haven't had any problems
>> because of it.
>>
>>
>>
>> 3. Some changes around calibration. You can get a calibration status of
>> 0x01 (ongoing) and 0x03 (completed) from the device. But I've noticed that
>> very often the first response I get is 0x03, which later (~100 ms) changes
>> to 0x01, then back to 0x03. So now to make sure it actually completes, the
>> driver first wants to see 0x01 at least once and then it waits for 0x03.
>>
>>
>>
>> 4. KT has recommended a different frame extraction algo. First we
>> subtract the background which we got during calibration. This helps quite
>> significantly. Then we split values into 3 groups and apply a different
>> transformation to each group (see comments for detail). And this seems to
>> give slightly worse results on my reader than simple linear scaling like
>> there was before. So I've left both methods and it's possible to configure
>> the method for each device. YMMV.
>>
>>
>>
>> Please see if it now works better/same/worse for you. I think
>> verification is now slightly better on my device but I need to use it for a
>> couple of days to know.
>>
>>
>>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-02-10 Thread Igor Filatov

Hi Timo,

I'll only be able to test closer to the end of next week... Although I'm
not sure I understand what you mean by "same region" here. Will it work if
the images have , say, 70% overlap? Because we can't expect users to scan
the very same area all the time.

On Sat, Feb 10, 2018 at 11:12 PM TeEmZe  wrote:

> Hi,
>
>
>
> I fixed the issue with differently sized images and managed to test it
> with another fingerprint, which shouldn’t match, and got 48%. This is good,
> as it means that it didn’t match.
>
> I think the algorithm is at a state, at which testing is required – all
> that’s left to do is some parameter optimizing, and those might already be
> optimized enough for the real world.
> Ok, that might not be 100%  true, as the image still has to be from the
> same region of the fingerprint, but this could be solved by taking multiple
> images at the enrol process and check all enrolled images for a match.
>
> So I’d be happy if some people could test it so that we can soon implement
> the algorithm into the actual tool.
>
>
>
> Kind regards
>
>
>
> Timo
>
>
>
> *From:* fprint [mailto:fprint-boun...@lists.freedesktop.org] *On Behalf
> Of *TeEmZe
> *Sent:* Friday, 9 February 2018 23:48
> *To:* 'Igor Filatov' ; fprint@lists.freedesktop.org
>
>
> *Subject:* Re: [fprint] elan patch + poc 0x903 and 0x0C03
>
>
>
> Hi Igor,
>
>
>
> I implemented the basis of an algorithm – you can take a look at it here
> <https://github.com/MetaColon/Libfprint/tree/master/Algorithm>.
> It is however far from finished or even optimised and is in need of some
> testing.
> I however don’t currently have the possibility to test it, so I’m asking
> you whether you could test it and maybe take a look at the todos written as
> comments in the source code.
>
> I had one image to test it with, and the result was 75%, which is good, as
> the paper I used as a reference said that it’s a match as soon as the
> percentage is above 70%.
>
>
>
> Kind regards
>
>
>
> Timo
>
>
>
> *From:* fprint [mailto:fprint-boun...@lists.freedesktop.org
> ] *On Behalf Of *Igor Filatov
> *Sent:* Friday, 9 February 2018 20:43
> *To:* fprint@lists.freedesktop.org
> *Subject:* Re: [fprint] elan patch + poc 0x903 and 0x0C03
>
>
>
> Hi Timo,
>
>
>
> I've noticed this when working on the initial implementation - that rows
> at bottom and top are bad (and I've seen a number of scans sent by
> different people - it's never on the sides for some reason). That's why
> there was the frame_margin param which means "cut this many px from top and
> bottom". Actually, in recent commits this has changed and it just crops the
> frame to max 50px by height. Since assembly doesn't really work for frames
> higher than that.
>
>
>
> But ultimately libfprint needs a different algo for small sensors. No
> getting around it. Telling people they need to swipe even though they see
> have a touch sensor isn't feasible and seems to already be failing in
> practice. I've trained myself to swipe reliably but still... don't want to
> spoil my karma with a driver that pretends to work but is hardly usable.
>
>
>
>
>
> Hi,
>
>
>
>
>
> I might actually have another solution.
>
> The fingerprint images, that are created by the swiping, are assembled out
> of multiple images, the reader got, right?
> I now realized that each of those images seems to have about one or two
> rows of pixels at the top and at the bottom, which are simply black.
> Those rows alter the image, so that similar fingers aren’t matching, as
> the rows are at different positions in the image if the finger was moved
> with a different speed – which is always the case.
> So I think we should try changing the way we generate the image with the
> swipe movement by cropping each image, of which the final image is
> assembled, by two pixels at the top and the bottom.
> I don’t know whether this solves all problems, but I can at imagine that
> it’d at least improve it.
> I am however still working on an alternative algorithm, which uses cross
> correlation of field orientation, but I can imagine that this won’t be
> necessary anymore.
>
>
>
> I don’t know the way you’re currently assembling the joined fingerprint
> image, so maybe someone who does could give this a try?
> I’ll be happy to test it afterwards.
>
>
>
>
>
> Kind regards
>
>
>
> Timo
>
>
>
> *From:* fprint [mailto:fprint-boun...@lists.freedesktop.org] *On Behalf
> Of *wp12880529-timo wp12880529-timo
> *Sent:* Friday, 9 February 2018 03:30
>

Re: [fprint] Verification help request (Egis Technology 1c7a:0570)

2018-02-11 Thread Igor Filatov

Hi,

1. You need to find out the correct format of returned data. By correct I
mean the one that allows to decode an image of a fingerprint. This is
necessary for the matching algorithm to work. The .pgm files in your repo
don't look like fingerprints, right? They look like noise because the
dimensions are incorrect.
2. Raw data is not fine. I've tried a few variant and it looks like your
device returns 8bit 114x57 images. And it returns 5 of them together. Not
sure, maybe the driver is supposed to combine them in some way.
3. libfrpint doesn't care that much about pixel dimensions. What is does
very much care about is the physical size of the fingerptint that a device
can scan. In your case it's very small. It won't work. Welcome to the
club... See the recent discussions in the mailing list about the Elan
driver I'm writing. It has the same problem tldr: libfprint uses a fp
matching algo that detects minutiae (notable elements of a fingerprint) and
needs to see 60+% of a print surface (from my observations, ymmv) to work
reliably. Your reader covers maybe 15%. That's not enough. Original drivers
for such devices for Windows, phones etc. probably have a different
matching algo.

On Sun, Feb 11, 2018 at 1:25 PM Indev  wrote:

> Hello,
>
> I am writing a driver for Egis Technology Inc. sensor (ID 1c7a:0570), but
> having few problems.
> First of all, i have no idea what is the model of my sensor. I've checked
> USB.org product lists as well as manufacturer's website and Acer website (I
> am using Acer Swift 1 SF-113-31 with this sensor integrated).
> I failed to find any kind of information about my device and started to
> write driver without that.
> I was managed to recreate driver exchange process and get data from the
> sensor.
> This is the press-type sensor and it returns 32512 bytes of data in one
> packet, which seem to be raw image data.
> I don't know what is the size of the returned image, so i've picked up the
> most suitable one for libfprint driver.
> Couple days ago i finished libfprint driver and it works fine, except of
> the fact that the verify_live example from libfprint is not able to do
> correct verification. It can't recognize same finger again and allows to
> pass verification by another finger, which is kinda funny.
>
> I have absolutely no experience with fingerprint scanner and I was hoping
> that someone here could help me.
> This is the repository of my driver: https://github.com/indev29/egis0570
> The 'scans' directory contains examples of fingerprint scans converted
> into different sized .pgm images as well as raw binary data, received from
> sensor.
> Directories names ("scans/finger_avg_NUM") indicate average color value,
> which is more, when i press harder on sensor.
>
> My questions are:
> 1. Should i use this raw image data in my libfprint driver or should i
> process it somehow first?
> 2. If raw data is fine, why am i not able to do verification correctly?
> 3. Does libfprint care about image size? Can the wrong image size be the
> thing in my case (i am using 254x128)
>
> Thanks in advance,
> Indev
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Verification help request (Egis Technology 1c7a:0570)

2018-02-14 Thread Igor Filatov

> Did i get you right, there is no way to use my device with libfprint
matching alorythm, unless I try to use my scanner as a swipe-type one?

No way it will work reliably every time. The used algo expects to find and
compare minutiae on the prints (https://www.uh.edu/engines/epi2529.htm)
which there are little to be found when the scan area is small. For ex, I
can see only 1 on scans/finger_avg_167. You need to reliably get 30+
(number based on my experience, not on a thorough evaluation of the algo).
And the number also depends on the area which you capture. For ex. the same
sized area of my finger can have 1-2, or it can have 20, depending on where
it is. Even if you manage to find such area on your finger and train
yourself to scan it all the time, other people won't be able to use your
driver.

> And i am curious why does it return several images instead of one?

This I don't know... It's possible that the pixels are not packed
row-after-row. E.g. the first row starts at idx 0 and ends at 113, the
second row starts at 114*57 and ends at 114*57 + 113 etc. Or it's just the
way your device works. However you chose to extract the image, make sure it
does NOT contain the same area more that once. Otherwise the scoring will
not work correctly and you can get many false positives.

On Wed, Feb 14, 2018 at 12:04 PM Indev  wrote:

> Did i get you right, there is no way to use my device with libfprint
> matching alorythm, unless I try to use my scanner as a swipe-type one?
> That's exactly what you did with your Elan driver, right?
> The scan area is indeed very small.
> And i am curious why does it return several images instead of one?
> Isn't it simplier to process in any case, especially when it is press-type
> sensor? Just saying.
>
>
> 2018-02-12 4:57 GMT+07:00 Igor Filatov :
>
>> Hi,
>>
>> 1. You need to find out the correct format of returned data. By correct I
>> mean the one that allows to decode an image of a fingerprint. This is
>> necessary for the matching algorithm to work. The .pgm files in your repo
>> don't look like fingerprints, right? They look like noise because the
>> dimensions are incorrect.
>> 2. Raw data is not fine. I've tried a few variant and it looks like your
>> device returns 8bit 114x57 images. And it returns 5 of them together. Not
>> sure, maybe the driver is supposed to combine them in some way.
>> 3. libfrpint doesn't care that much about pixel dimensions. What is does
>> very much care about is the physical size of the fingerptint that a device
>> can scan. In your case it's very small. It won't work. Welcome to the
>> club... See the recent discussions in the mailing list about the Elan
>> driver I'm writing. It has the same problem tldr: libfprint uses a fp
>> matching algo that detects minutiae (notable elements of a fingerprint) and
>> needs to see 60+% of a print surface (from my observations, ymmv) to work
>> reliably. Your reader covers maybe 15%. That's not enough. Original drivers
>> for such devices for Windows, phones etc. probably have a different
>> matching algo.
>>
>> On Sun, Feb 11, 2018 at 1:25 PM Indev  wrote:
>>
>>> Hello,
>>>
>>> I am writing a driver for Egis Technology Inc. sensor (ID 1c7a:0570),
>>> but having few problems.
>>> First of all, i have no idea what is the model of my sensor. I've
>>> checked USB.org product lists as well as manufacturer's website and Acer
>>> website (I am using Acer Swift 1 SF-113-31 with this sensor integrated).
>>> I failed to find any kind of information about my device and started to
>>> write driver without that.
>>> I was managed to recreate driver exchange process and get data from the
>>> sensor.
>>> This is the press-type sensor and it returns 32512 bytes of data in one
>>> packet, which seem to be raw image data.
>>> I don't know what is the size of the returned image, so i've picked up
>>> the most suitable one for libfprint driver.
>>> Couple days ago i finished libfprint driver and it works fine, except of
>>> the fact that the verify_live example from libfprint is not able to do
>>> correct verification. It can't recognize same finger again and allows to
>>> pass verification by another finger, which is kinda funny.
>>>
>>> I have absolutely no experience with fingerprint scanner and I was
>>> hoping that someone here could help me.
>>> This is the repository of my driver: https://github.com/indev29/egis0570
>>> The 'scans' directory contains examples of fingerprint scans converted
>>> into different sized .pgm im

Re: [fprint] [PATCH] imgdev: add support for FP_IMGDRV_NEEDS_REACTIVATION_BETWEEN_ENROLLS flag

2018-02-15 Thread Igor Filatov

I think it would be better if libfprint simply called dev_activate each
time it needed an image, including each enroll step, and then called
dev_deactivate when it's done. Drivers should know whether they need to
reactivate or not. But this will require changes to all the drivers of the
devices that return images... which should actually amount to a few deleted
lines.

On Fri, Feb 16, 2018 at 3:57 AM Marco Trevisan (Treviño) 
wrote:

> When a device has this flag set, it has to be re-activated at
> each enroll step, without performing any other cleanup.
>
> This allows to solve this such case in a cleaner way inside
> drivers.
> ---
>  libfprint/fp_internal.h |  1 +
>  libfprint/imgdev.c  | 30 +++---
>  2 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/libfprint/fp_internal.h b/libfprint/fp_internal.h
> index 74c5f7f..ea46b1e 100644
> --- a/libfprint/fp_internal.h
> +++ b/libfprint/fp_internal.h
> @@ -232,6 +232,7 @@ enum fp_print_data_type
> fpi_driver_get_data_type(struct fp_driver *drv);
>   /* flags for fp_img_driver.flags */
>  #define FP_IMGDRV_SUPPORTS_UNCONDITIONAL_CAPTURE (1 << 0)
> +#define FP_IMGDRV_NEEDS_REACTIVATION_BETWEEN_ENROLLS (1 << 1)
>   struct fp_img_driver {
> struct fp_driver driver;
> diff --git a/libfprint/imgdev.c b/libfprint/imgdev.c
> index 4408c23..20a1559 100644
> --- a/libfprint/imgdev.c
> +++ b/libfprint/imgdev.c
> @@ -27,6 +27,9 @@
>  #define BOZORTH3_DEFAULT_THRESHOLD 40
>  #define IMG_ENROLL_STAGES 5
>  +static int dev_activate(struct fp_img_dev *imgdev, enum
> fp_imgdev_state state);
> +static void dev_deactivate(struct fp_img_dev *imgdev);
> +
>  static int img_dev_open(struct fp_dev *dev, unsigned long driver_data)
>  {
> struct fp_img_dev *imgdev = g_malloc0(sizeof(*imgdev));
> @@ -124,6 +127,7 @@ void fpi_imgdev_report_finger_status(struct
> fp_img_dev *imgdev,
> int r = imgdev->action_result;
> struct fp_print_data *data = imgdev->acquire_data;
> struct fp_img *img = imgdev->acquire_img;
> +   struct fp_img_driver *imgdrv =
> fpi_driver_to_img_driver(imgdev->dev->drv);
> fp_dbg(present ? "finger on sensor" : "finger removed");
>  @@ -158,8 +162,14 @@ void fpi_imgdev_report_finger_status(struct
> fp_img_dev *imgdev,
> if (imgdev->action == IMG_ACTION_ENROLL &&
> r > 0 && r != FP_ENROLL_COMPLETE && r !=
> FP_ENROLL_FAIL) {
> imgdev->action_result = 0;
> -   imgdev->action_state =
> IMG_ACQUIRE_STATE_AWAIT_FINGER_ON;
> -   dev_change_state(imgdev,
> IMGDEV_STATE_AWAIT_FINGER_ON);
> +
> +   if (imgdrv->flags &
> FP_IMGDRV_NEEDS_REACTIVATION_BETWEEN_ENROLLS) {
> +   imgdev->action_state =
> IMG_ACQUIRE_STATE_DEACTIVATING;
> +   dev_deactivate(imgdev);
> +   } else {
> +   imgdev->action_state =
> IMG_ACQUIRE_STATE_AWAIT_FINGER_ON;
> +   dev_change_state(imgdev,
> IMGDEV_STATE_AWAIT_FINGER_ON);
> +   }
> }
> break;
> case IMG_ACTION_VERIFY:
> @@ -332,11 +342,16 @@ void fpi_imgdev_session_error(struct fp_img_dev
> *imgdev, int error)
>   void fpi_imgdev_activate_complete(struct fp_img_dev *imgdev, int status)
>  {
> +   struct fp_img_driver *imgdrv =
> fpi_driver_to_img_driver(imgdev->dev->drv);
> +
> fp_dbg("status %d", status);
> switch (imgdev->action) {
> case IMG_ACTION_ENROLL:
> -   fpi_drvcb_enroll_started(imgdev->dev, status);
> +   if (!(imgdrv->flags &
> FP_IMGDRV_NEEDS_REACTIVATION_BETWEEN_ENROLLS) ||
> +   imgdev->dev->state != DEV_STATE_ENROLLING) {
> +   fpi_drvcb_enroll_started(imgdev->dev, status);
> +   }
> break;
> case IMG_ACTION_VERIFY:
> fpi_drvcb_verify_started(imgdev->dev, status);
> @@ -360,10 +375,19 @@ void fpi_imgdev_activate_complete(struct
> fp_img_dev *imgdev, int status)
>   void fpi_imgdev_deactivate_complete(struct fp_img_dev *imgdev)
>  {
> +   struct fp_img_driver *imgdrv =
> fpi_driver_to_img_driver(imgdev->dev->drv);
> +
> fp_dbg("");
> switch (imgdev->action) {
> case IMG_ACTION_ENROLL:
> +   if ((imgdrv->flags &
> FP_IMGDRV_NEEDS_REACTIVATION_BETWEEN_ENROLLS) &&
> +   imgdev->dev->state == DEV_STATE_ENROLLING) {
> +   imgdev->action_state =
> IMG_ACQUIRE_STATE_ACTIVATING;
> +   dev_activate(imgdev, IMGDEV_STATE_AWAIT_FINGER_ON);
> +   return;
> +   }
> +
> fpi_drvcb_enroll_stopped(imgdev->dev);
> break;
> case IMG_ACTION_VERIFY:
> --
> 2.7.4
>
> ___
> fprint mailing list
> fprint@list

Re: [fprint] [PATCH] imgdev: add support for FP_IMGDRV_NEEDS_REACTIVATION_BETWEEN_ENROLLS flag

2018-02-16 Thread Igor Filatov

Here's what I'm doing which isn't clean either
https://github.com/iafilatov/libfprint/blob/elan/libfprint/drivers/elan.c#L525
but
allows to contain the ugliness to a small part of code. You actually don't
need to deactivate manually until libfprint calls dev_deactivate. You only
need to keep submitting images till dev_deactivate is called. How you do it
is up to you. The only quirk is that you need to give libfprint a chance to
do it asynchronously.

And I'm not sure but I think this is because initially there were no enroll
stages (just a theory) so everything was fine. And then the stages were
added and it became somewhat awkward. Maybe there should just be a callback
that the drivers should call after they've submitted the image, and
libfprint would either do nothing if it needs more images (and the drivers
would then repeat capture as they do now) or call dev_deactivate. I think
the drivers should already handle dev_deactivate properly on any stage. The
changes to the drivers should be minimal this way.

On Fri, Feb 16, 2018 at 3:08 PM Marco Trevisan (Treviño) 
wrote:

> Hi Igor,
>
> 2018-02-16 8:58 GMT+01:00 Igor Filatov :
> > I think it would be better if libfprint simply called dev_activate each
> time
> > it needed an image, including each enroll step, and then called
> > dev_deactivate when it's done. Drivers should know whether they need to
> > reactivate or not. But this will require changes to all the drivers of
> the
> > devices that return images... which should actually amount to a few
> deleted
> > lines.
>
> Yeah, well I thought about changing this in all the places, but I
> didn't want to break drivers that I could not test, so I though this
> was safer, although I recognize isn't the cleanest code. But if you
> think this flag is acceptable, we can probably add helper functions to
> keep this a bit nicer.
>
> At the beginning I was doing this at my driver level (see
> https://github.com/3v1n0/libfprint/commit/8cb5e6945cc26), but I didn't
> like to keep it there (nor I wanted to introduce other flags for the
> driver to keep the state, since imgdrv is supposed to do this already.
> So, while I could go back to that solution, I'd really prefer not to
> make the driver to handle such things.
>
> And yes, having this flag to be more generic to ENROLL only is
> something we can do too, let me know if there's any preference and I
> can look into that.
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Assembling of frames is broken

2018-03-04 Thread Igor Filatov

I confirm that this improves stitching. Especially with tall frames.

On Sat, Mar 3, 2018 at 12:07 AM Vasily Khoruzhick 
wrote:

> Hi Timur,
>
> On Wed, Feb 28, 2018 at 12:41 PM, Timur Celik  wrote:
> > Hello everybody,
> >
> > I have already discussed this with Igor. There are two different bugs in
> the
> > assembling of frames. I think this needs some attention because it made
> > libfprint unusable for me and it affects all sensors.
> >
> > In forward mode every frame stores the delta from the previous frame, in
> > reverse mode it stores the delta to the next frame. This causes images to
> > use the wrong delta while assembling in forward mode. The resulting
> > stitching artifacts may be subtle when the movement was continuous,
> because
> > the deltas will be similar.
>
> Thanks for report. I'll try to look into it this weekend.
>
> > ---
> > libfprint/assembling.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/libfprint/assembling.c b/libfprint/assembling.c
> > index 1052f99..bf2ff13 100644
> > --- a/libfprint/assembling.c
> > +++ b/libfprint/assembling.c
> > @@ -279,11 +279,18 @@ struct fp_img *fpi_assemble_frames(struct
> > fpi_frame_asmbl_ctx *ctx,
> >  do {
> >   fpi_frame = stripe->data;
> >
> > -   y += fpi_frame->delta_y;
> > -   x += fpi_frame->delta_x;
> > +   if(reverse) {
> > +   y += fpi_frame->delta_y;
> > +   x += fpi_frame->delta_x;
> > +   }
> >
> >   aes_blit_stripe(ctx, img, fpi_frame, x, y);
> >
> > +   if(!reverse) {
> > +   y += fpi_frame->delta_y;
> > +   x += fpi_frame->delta_x;
> > +   }
> > +
> >   stripe = g_slist_next(stripe);
> >   i++;
> >  } while (i < stripes_len);
> > --
> > 2.14.3
> >
> >
> > The second bug is in reverse mode. The last image is always misplaced
> > because the sign of the delta vector isn't corrected. This bug is always
> be
> > visible.
> >
> > ---
> > libfprint/assembling.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libfprint/assembling.c b/libfprint/assembling.c
> > index bf2ff13..0781006 100644
> > --- a/libfprint/assembling.c
> > +++ b/libfprint/assembling.c
> > @@ -131,8 +131,8 @@ static unsigned int do_movement_estimation(struct
> > fpi_frame_asmbl_ctx *ctx,
> >
> >   if (reverse) {
> >find_overlap(ctx, prev_stripe, cur_stripe, &min_error);
> > -   prev_stripe->delta_y = -prev_stripe->delta_y;
> > -   prev_stripe->delta_x = -prev_stripe->delta_x;
> > +   cur_stripe->delta_y = -cur_stripe->delta_y;
> > +   cur_stripe->delta_x = -cur_stripe->delta_x;
> >   }
> >   else
> >find_overlap(ctx, cur_stripe, prev_stripe, &min_error);
> > --
> > 2.14.3
> >
> >
> > I have opened a ticket on bugzilla
> > (https://bugs.freedesktop.org/show_bug.cgi?id=105027) and hope to see
> this
> > confirmed and merged soon.
> >
> > Timur
> >
> > ___
> > fprint mailing list
> > fprint@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/fprint
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] implementing on windows

2018-03-06 Thread Igor Filatov

I don't think it's possible. jlibfprint depends on libfprint which is
written for linux (posix?): libusb, glib etc.

On Tue, Mar 6, 2018 at 11:04 AM enock tum  wrote:

> I have implemented the libfprint on my linux and it is working perfectly.
> The problem comes when i want to transfer the project to a windows based
> server, it tells me that jlibfprint.dll not found and i cant seem to get a
> fix in the whole universe on it, please help me, thanks
>
> --
> Enock Tum
> Software Engineer
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_5248117170150041581_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Documentation for writing a new driver

2018-03-09 Thread Igor Filatov

Hi Mark,

There are no high-level docs, unfortunately. There's some valuable info in
comments in drv.c, sync.c, async.c, img.c etc. but it only covers specific
parts, not how they should interact.

There are 6 drivers for press-type sensors: aes3500.c, aes4000.c,
fdu2000.c, upektc.c, uru4000.c, vcom5s.c. But there isn't much difference
between press and swipe drivers. FP_SCAN_TYPE_* is used to determine which
messages to show ("please touch the sensor" vs. "please swipe..."), and I
think that's it. Besides that, all drivers essentially do the same thing:
obtain the fingerprint image and submit it. You can use any driver as a
reference.

On Fri, Mar 9, 2018 at 7:50 PM Mark Harfouche 
wrote:

> Hello all,
>
> I would like to develop a driver for the Validity 0091 sensor available on
> the Dell XPS13/15 9X60.
>
> I would say I have the driver reverse engineered to 95% (There might be a
> few things I still don’t understand from the internal state machine).
> https://github.com/hmaarrfk/Validity91
> WIP: https://github.com/freedesktop/libfprint
>
> I found the libfprint source, can compile it, and started creating my own
> driver.
>
> However, I am confused about the internal workings of libfprint and the
> functions I need to define.
> I tried to follow examples that were included, but it seemed that they
> were mostly “swipe”‘ sensors, and not capacitive style sensor.
> Is there any good documentation about the state machines I need to
> implement with regards to the functions
>
> .open = dev_open,
> .close = dev_close,
> .activate = dev_activate,
> .deactivate = dev_deactivate,
> .change_state = dev_change_state,
>
> Thanks,
>
> Mark
> 
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Documentation for writing a new driver

2018-03-09 Thread Igor Filatov

Not really. The same state is sent to dev_change_state after activation has
ended with fpi_imgdev_activate_complete. You can ignore it.


On Fri, Mar 9, 2018 at 8:51 PM Mark Harfouche 
wrote:

> Hi Igor,
>
> Thank you for your reply.
>
> I’m confused about the parameter sent to dev_activate. Is it useful? in
> uru4000.c (which seems to be the latest one written), the authors also seem
> to be confused
>
> /* FIXME: having state parameter here is kinda useless, will we ever
>  * see a scenario where the parameter is useful so early on in the activation
>  * process? asynchronity means that it'll only be used in a later function
>  * call. */static int dev_activate(struct fp_img_dev *dev, enum 
> fp_imgdev_state state)
> {
>
> Thanks,
>
> Mark
>
> On Fri, Mar 9, 2018 at 10:43 AM, Igor Filatov 
> wrote:
>
> Hi Mark,
>>
>> There are no high-level docs, unfortunately. There's some valuable info
>> in comments in drv.c, sync.c, async.c, img.c etc. but it only covers
>> specific parts, not how they should interact.
>>
>> There are 6 drivers for press-type sensors: aes3500.c, aes4000.c,
>> fdu2000.c, upektc.c, uru4000.c, vcom5s.c. But there isn't much difference
>> between press and swipe drivers. FP_SCAN_TYPE_* is used to determine which
>> messages to show ("please touch the sensor" vs. "please swipe..."), and I
>> think that's it. Besides that, all drivers essentially do the same thing:
>> obtain the fingerprint image and submit it. You can use any driver as a
>> reference.
>>
>>
>>
>> On Fri, Mar 9, 2018 at 7:50 PM Mark Harfouche 
>> wrote:
>>
>>> Hello all,
>>>
>>> I would like to develop a driver for the Validity 0091 sensor available
>>> on the Dell XPS13/15 9X60.
>>>
>>> I would say I have the driver reverse engineered to 95% (There might be
>>> a few things I still don’t understand from the internal state machine).
>>> https://github.com/hmaarrfk/Validity91
>>> WIP: https://github.com/freedesktop/libfprint
>>>
>>> I found the libfprint source, can compile it, and started creating my
>>> own driver.
>>>
>>> However, I am confused about the internal workings of libfprint and the
>>> functions I need to define.
>>> I tried to follow examples that were included, but it seemed that they
>>> were mostly “swipe”‘ sensors, and not capacitive style sensor.
>>> Is there any good documentation about the state machines I need to
>>> implement with regards to the functions
>>>
>>> .open = dev_open,
>>> .close = dev_close,
>>> .activate = dev_activate,
>>> .deactivate = dev_deactivate,
>>> .change_state = dev_change_state,
>>>
>>> Thanks,
>>>
>>> Mark
>>> 
>>> ___
>>> fprint mailing list
>>> fprint@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/fprint
>>>
>> 
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Documentation for writing a new driver

2018-03-10 Thread Igor Filatov

I've left something in https://github.com/hmaarrfk/libfprint/issues/4 because
it's easier to discuss when you can point at the code.

On Sat, Mar 10, 2018 at 3:06 AM Mark Harfouche 
wrote:

> Alright, I think I finally got somewhere.
>
> I can run img_capture successfully. I see two pgm files in my directory
> that look like fingerprints.
>
> This particular device can’t do the matching so it all has to be done on
> the host.
> I assume libfprint can do this?
>
> I can’t seem to run enroll. This is the output I get:
>
> This program will enroll your right index finger, unconditionally overwriting 
> any right-index print that was enrolled previously. If you want to continue, 
> press enter, otherwise hit Ctrl+C
>
> Found device claimed by Validity VFS7552 driver
> Opened device. It's now time to enroll your finger.
>
> You will need to successfully scan your finger 5 times to complete the 
> process.
>
> Scan your finger now.
> Wrote scanned image to enrolled.pgm
> Didn't quite catch that. Please try again.
>
> Scan your finger now.
> libusb: warning [handle_timeout] async cancel failed -5 errno=22
> Wrote scanned image to enrolled.pgm
> Didn't quite catch that. Please try again.
>
> What is:
>
> libusb: warning [handle_timeout] async cancel failed -5 errno=22
>
> Help would be appreciated, though I know it is difficult to debug other
> people’s hardware.
>
> Mark
> 
>
> On Fri, Mar 9, 2018 at 11:02 AM, Igor Filatov 
> wrote:
>
>> Not really. The same state is sent to dev_change_state after activation
>> has ended with fpi_imgdev_activate_complete. You can ignore it.
>>
>>
>> On Fri, Mar 9, 2018 at 8:51 PM Mark Harfouche 
>> wrote:
>>
>>> Hi Igor,
>>>
>>> Thank you for your reply.
>>>
>>> I’m confused about the parameter sent to dev_activate. Is it useful? in
>>> uru4000.c (which seems to be the latest one written), the authors also seem
>>> to be confused
>>>
>>> /* FIXME: having state parameter here is kinda useless, will we ever
>>>  * see a scenario where the parameter is useful so early on in the 
>>> activation
>>>  * process? asynchronity means that it'll only be used in a later function
>>>  * call. */static int dev_activate(struct fp_img_dev *dev, enum 
>>> fp_imgdev_state state)
>>> {
>>>
>>> Thanks,
>>>
>>> Mark
>>>
>>> On Fri, Mar 9, 2018 at 10:43 AM, Igor Filatov 
>>> wrote:
>>>
>>> Hi Mark,
>>>>
>>>> There are no high-level docs, unfortunately. There's some valuable info
>>>> in comments in drv.c, sync.c, async.c, img.c etc. but it only covers
>>>> specific parts, not how they should interact.
>>>>
>>>> There are 6 drivers for press-type sensors: aes3500.c, aes4000.c,
>>>> fdu2000.c, upektc.c, uru4000.c, vcom5s.c. But there isn't much difference
>>>> between press and swipe drivers. FP_SCAN_TYPE_* is used to determine which
>>>> messages to show ("please touch the sensor" vs. "please swipe..."), and I
>>>> think that's it. Besides that, all drivers essentially do the same thing:
>>>> obtain the fingerprint image and submit it. You can use any driver as a
>>>> reference.
>>>>
>>>>
>>>>
>>>> On Fri, Mar 9, 2018 at 7:50 PM Mark Harfouche 
>>>> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I would like to develop a driver for the Validity 0091 sensor
>>>>> available on the Dell XPS13/15 9X60.
>>>>>
>>>>> I would say I have the driver reverse engineered to 95% (There might
>>>>> be a few things I still don’t understand from the internal state machine).
>>>>> https://github.com/hmaarrfk/Validity91
>>>>> WIP: https://github.com/freedesktop/libfprint
>>>>>
>>>>> I found the libfprint source, can compile it, and started creating my
>>>>> own driver.
>>>>>
>>>>> However, I am confused about the internal workings of libfprint and
>>>>> the functions I need to define.
>>>>> I tried to follow examples that were included, but it seemed that they
>>>>> were mostly “swipe”‘ sensors, and not capacitive style sensor.
>>>>> Is there any good documentation about the state machines I need to
>>>>> implement with regards to the functions
>>>>>
>>>>> .open = dev_open,
>>>>> .close = dev_close,
>>>>> .activate = dev_activate,
>>>>> .deactivate = dev_deactivate,
>>>>> .change_state = dev_change_state,
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Mark
>>>>> 
>>>>> ___
>>>>> fprint mailing list
>>>>> fprint@lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/fprint
>>>>>
>>>> 
>>>
>>
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] libfprint ported to Meson and gtk-doc

2018-05-17 Thread Igor Filatov

Mine seems ok. The docs could use a short build&install guide though. I've
updated the readme in my repo https://github.com/iafilatov/libfprint. Meson
is great but from a user's perspective it doesn't beat `./configure &&
make`. And actually there's quite a few ones who want to try it out but
don't have that much experience with build systems.

I'd like to follow the updates in the new repo but it won't let me sign in.
Says my account is blocked...

On Thu, May 17, 2018 at 7:01 PM Bastien Nocera  wrote:

> Hello all,
>
> libfprint has been ported to Meson[1] (from autotools) and gtk-doc
> (from Doxygen) in git. This means that building libfprint is now much
> much faster, and the API documentation is now clearer.
>
> It would be great if driver authors could update their development
> branches and report any problems.
>
> Let me know if you run into any problems building the library, or spot
> any errors in the documentation.
>
> Other short-term plans include migrating libfprint and fprintd to
> freedesktop.org's gitlab instance[2], giving the website/wiki a
> refresh, and writing a guide to writing new drivers.
>
> Cheers
>
> [1]: http://mesonbuild.com/
> [2]: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/21
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] libfprint ported to Meson and gtk-doc

2018-05-17 Thread Igor Filatov

> From the user's perspective, users shouldn't have to build their own
> system libraries. From the developers point-of-view, the rules are
> actually readable, understandable, and it takes as long to build
> libfprint and the docs as it did just running configure. So I'm fine
> with the drawbacks :)

But they actually do it sometimes :) I understand there's no going back,
which is ok. Just saying that build and install docs would be a welcome
addition to the docs. Willing to help with it if needed.

On Fri, May 18, 2018 at 6:51 AM Bastien Nocera  wrote:

> On Thu, 2018-05-17 at 23:40 +0300, Igor Filatov wrote:
> > Mine seems ok. The docs could use a short build&install guide though.
> > I've updated the readme in my
> > repo https://github.com/iafilatov/libfprint. Meson is great but from
> > a user's perspective it doesn't beat `./configure && make`.
>
> From the user's perspective, users shouldn't have to build their own
> system libraries. From the developers point-of-view, the rules are
> actually readable, understandable, and it takes as long to build
> libfprint and the docs as it did just running configure. So I'm fine
> with the drawbacks :)
>
> >  And actually there's quite a few ones who want to try it out but
> > don't have that much experience with build systems.
>
> If anyone has problems updating the Makefile.am/configure.ac rules for
> their WIP drivers, let me know.
>
> FWIW, unless additional files or libraries are needed, you'd only need
> to add the driver name to "all_drivers" in the top-level meson.build,
> and add a conditional in the "foreach driver: drivers" loop in
> libfprint/meson.build.
>
> > I'd like to follow the updates in the new repo but it won't let me
> > sign in. Says my account is blocked...
>
> There's no new repo, it's not migrated yet.
>
> > On Thu, May 17, 2018 at 7:01 PM Bastien Nocera 
> > wrote:
> > > Hello all,
> > >
> > > libfprint has been ported to Meson[1] (from autotools) and gtk-doc
> > > (from Doxygen) in git. This means that building libfprint is now
> > > much
> > > much faster, and the API documentation is now clearer.
> > >
> > > It would be great if driver authors could update their development
> > > branches and report any problems.
> > >
> > > Let me know if you run into any problems building the library, or
> > > spot
> > > any errors in the documentation.
> > >
> > > Other short-term plans include migrating libfprint and fprintd to
> > > freedesktop.org's gitlab instance[2], giving the website/wiki a
> > > refresh, and writing a guide to writing new drivers.
> > >
> > > Cheers
> > >
> > > [1]: http://mesonbuild.com/
> > > [2]: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/
> > > 21
> > > ___
> > > fprint mailing list
> > > fprint@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Microsoft Modern Keyboard with Fingerprint ID

2018-05-21 Thread Igor Filatov

Sorry for a bit of off-topic but it looks like the new ms keyborad as a
small touch sensor which is unreliable with the current matching algo.
That's the problem we really need competent people and/or sponsorship for
first. Even if someone writes a driver for that kb, the experience will
still be so-so.

On Mon, May 21, 2018 at 10:58 PM Julien Nicoulaud <
julien.nicoul...@gmail.com> wrote:

> Thanks,
>
> It looks like it uses a in-house protocol for automatic bluetooth
> pairing, so it would probably be challenging to add support for this
> keyboard in bluetooth mode:
>
> https://askubuntu.com/questions/966097/microsoft-modern-keyboard-with-ubuntu
>
> Anyway, if you (or anyone competent) are interested in working on
> this, I can "sponsor" you by buying you one.
>
> Cheers,
> Julien
>
> 2018-05-11 13:13 GMT+02:00 Bastien Nocera :
> > On Thu, 2018-05-10 at 20:54 +0200, Julien Nicoulaud wrote:
> >> Hi,
> >>
> >> The supported devices list
> >> (https://www.freedesktop.org/wiki/Software/fprint/libfprint/Supported
> >> _devices/)
> >> has "MicrosoftKeyboard with Fingerprint Reader" as supported, but it
> >> also says "Last edited Fri 13 Sep 2013", so I'm not sure...
> >
> > That was a wired USB keyboard. I'm pretty sure it looked like this:
> > https://images-na.ssl-images-amazon.com/images/I/41JPVB3RF9L.jpg
> >
> >> Is this keyboard supported ?
> >>
> https://www.microsoft.com/accessories/en-us/products/keyboards/microsoft-modern-keyboard-with-fingerprint-id
> >
> > This is a Bluetooth/USB keyboard, likely a completely different one. I
> > have no idea how the Bluetooth fingerprint reader would work, but it's
> > something I'll keep in mind while adding support for more than just USB
> > devices to libfprint.
> >
> > Cheers
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Drivers API changes

2018-05-29 Thread Igor Filatov

Looks like G_DEBUG_HERE is only available in glib >= 2.50. Might set the
bar too high. For ex. latest Mint has 2.48 and the oldest Ubuntu LTS
(14.04) only has 2.40. I think the latter could be a good baseline.

On Tue, May 29, 2018 at 2:59 PM Bastien Nocera  wrote:

> Hey,
>
> In the process of writing and documenting the libfprint drivers API, I
> realised that drivers have access to library internals for no good
> reason, so I split off the internal library API from the drivers API.
>
> If you have an out-of-tree driver, the easiest would be to update your
> fork, and see where you get errors.
>
> Accessor functions were added for fields that were already in use by
> existing drivers, such as:
> - fpi_imgdev_get_usb_dev() and fpi_dev_get_usb_dev() instead of ->udev
> - fpi_dev_get_user_data()/fpi_dev_set_user_data() and
> fpi_imgdev_get_user_data()/fpi_imgdev_set_user_data() instead of
> accessing ->priv directly
> and similar.
>
> Let me know if any accessor is missing for your drivers. Note that
> there's a possibility that more changes are coming, especially as I
> don't like the way the user_data/priv is passed around, and fp_dev and
> fp_img_dev types need to duplicate access to some variables.
>
> But, hopefully, by the time I'm done with the above there will be a
> driver writing guide.
>
> Cheers
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-06-18 Thread Igor Filatov

I'd like to but I'm worried that people will have bad experience with these
devices (esp. 96x96 ones) and blame libfprint. And I still haven't had the
chance to pull in latest upstream, so...

On Mon, Jun 18, 2018 at 3:53 PM Bastien Nocera  wrote:

> On Wed, 2018-01-17 at 15:11 +0100, Sébastien Béchet wrote:
> > On 2018-01-17 12:12, Igor Filatov wrote:
> > > Looks like o1ca as well https://github.com/iafilatov/libfprint/pull
> > > /4
> >
> > Not o1ca but 0x0C1A. I create repository for POC:
> >
> > http://github.com/sbechet/elanfp
>
> Any plans on sending those changes from both trees up for merging on
> the freedesktop GitLab?
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-06-18 Thread Igor Filatov

Ok, I'll try to find some time to prepare a patch against upstream in the
coming days.

On Mon, Jun 18, 2018 at 4:22 PM Hans de Goede  wrote:

> Hi,
>
> On 18-06-18 15:03, Bastien Nocera wrote:
> > On Mon, 2018-06-18 at 15:01 +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 18-06-18 14:58, Igor Filatov wrote:
> >>> I'd like to but I'm worried that people will have bad experience
> >>> with these devices (esp. 96x96 ones) and blame libfprint. And I
> >>> still haven't had the chance to pull in latest upstream, so...
> >>
> >> Well ATM people are just blindly adding new USB-ids without
> >
> > Who's blindly doing that?
>
> Ok, blindly is not the right term, sorry. What I meant to say
> is that they are being submitted with what seems to be
> less thorough testing then what has been done by the people
> working on the code which is now in Igor's branch.
>
> e.g. the code in Igor's branch reads back the reader
> firmware version and basis calibration behavior on that.
>
> IIRC some readers have the same USB-id but a different fw
> version and you need to talk slightly different to the device
> based on the firmware version. So even if a USB-id added to
> the current code works for the submitter it may not work
> for all devices with that USB-id.
>
> Which is why I believe it is best to get the changes from
> Igor's branch upstream even though these readers still
> could use some more work.
>
> >> even getting all the improvements which have been done, so
> >> although I agree that these devices need more work
> >> (specifically a better match algorithm more suited for
> >> low res devices), I still think it would be good to at least
> >> get what we have upstream.
> >
> > I agree that even if we choose to disable those smaller resolution
> > devices, we probably want the code to drive them to be upstreamed.
>
> Agreed.
>
> Regards,
>
> Hans
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Enroll and verify fingerprint images

2018-06-19 Thread Igor Filatov

Not sure I understand what you're trying to do, but if you want a cli tool
to compare fingerprint images, you could write one using some functions in
img.c. But you might need to normalize your images first.


On Tue, 19 Jun 2018, 16:08 Bastien Nocera,  wrote:

> On Tue, 2018-06-19 at 12:49 +0200, Péter Gönczöl wrote:
> > Hi,
> >
> > Is it possible to enroll and verify fingerprint images (bmp format,
> > grayscale) with libfprint?
> > I've been reading the API docs and fprint.h but every functionality
> > I'd need appears to be hidden from the applications.
> >
> > It seems to me that the only option is to use the lib internal
> > functionality like fp_async_verify_start() and do it manually. Did I
> > miss something? Could you help me on how I should get started?
> >
> > Sorry if this is an amateur question, I'm new to native development.
> > Thanks in advance!
>
> We don't support it, we only support enrollment and verification from
> an actual physical device.
>
> If you really wanted the feature (it would be good to explain why
> though), you could create a driver that can take images from the disk,
> to enroll them.
>
> This might be helpful, although the patch needs updating:
> https://gitlab.freedesktop.org/libfprint/libfprint/issues/44
>
> Cheers
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-06-24 Thread Igor Filatov

Bastien,

I've incorporated latest upstream changes so I could open a merge request
but it looks like on gitlab I need a permission to do it. Or should I just
send a patch?
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] elan patch + poc 0x903 and 0x0C03

2018-06-24 Thread Igor Filatov

So I'd created a new project instead of forking and it didn't give me an
option to manually chose libfprint/libfprint as target for the merge
request. Which is weird, I think github allows that at least... but I'm not
sure and it's not important. I've re-created as fork and everything seems
fine now.


On Sun, Jun 24, 2018 at 2:52 PM Bastien Nocera  wrote:

> On Sun, 2018-06-24 at 14:25 +0300, Igor Filatov wrote:
> > Bastien,
> >
> > I've incorporated latest upstream changes so I could open a merge
> > request but it looks like on gitlab I need a permission to do it. Or
> > should I just send a patch?
>
> You don't have rights to commit directly to the libfprint repo (yet),
> so the workflow would be:
> - Click the "Fork" button at the top of the libfprint page:
> https://gitlab.freedesktop.org/libfprint/libfprint
> - This will create a fork in your personal space, under:
>   https://gitlab.freedesktop.org/users//projects
> - Then push your work branch there
> - Once you've pushed your branch, you should get a message in the "git
> push" output telling you where to click to create a merge request, or
> you can create one from the browse page for that branch, in the web UI.
>
> Don't forget to select the correct destination when creating the merge
> request. It will eventually show up at:
> https://gitlab.freedesktop.org/libfprint/libfprint/merge_requests
>
> Let me know if you run into any problems.
>
> The requests that were opened in the past were all create with branches
> in the libfprint repository itself, so they're a little different, but
> the workflow is similar.
>
> Cheers
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] UareU 4000B DigitalPersona image encrypted

2018-08-27 Thread Igor Filatov

https://lists.freedesktop.org/mailman/options/fprint

On Mon, Aug 27, 2018 at 4:25 PM Владислав Зелёный 
wrote:

> Пожалуйста, не пишите на эту почту. Как отписаться от рассылки?
>
>
> 27.08.2018, 19:54, "Bastien Nocera" :
>
> On Mon, 2018-08-27 at 18:33 +0300, Timo Teras wrote:
>
>  Hi
>
>  On Mon, 27 Aug 2018 12:56:21 +0200
>  Bastien Nocera  wrote:
>
>  > On Thu, 2018-08-23 at 13:19 +, Kleyson de Sousa Rios wrote:
>  > > To test I'm basically using the examples/ tools, and seems that
>  > > the
>  > > drive_data has the correct value 5.
>  >
>  > Looks like the device's output isn't always encrypted. Timo, could
>  > you
>  > check whether this change makes sense? Kleyson, could you please
>  > test
>  > it?
>  >
>  >
>
> https://gitlab.freedesktop.org/libfprint/libfprint/merge_requests/13
>
>
>  I remember it was confusing that 4500 reports as 4000B; the only
>  difference seemed to be encryption. There's probably some frame or
>  config flag which will tell if it's encrypted or not. Would be nice
>  if
>  we eventually used that instead of the heuristic.
>
>  But what comes to the patch, now that encryption is always in auto
>  mode, why not just delete the whole encryption flag? You probably
>  also
>  need to set the v/h flipped flags based on if the image was really
>  encrypted or not.
>
>  But the generic idea sounds ok to me until we get more insight if
>  there's a reliable indication somewhere about encryption.
>
>
> I would probably want to do this if only I had access to both types of
> devices, unfortunately, I don't even have one of them.
>
> Do the 4500 and 4000B have the same USB IDs? Maybe different endpoints,
> or properties on those endpoints?
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] [BUGG] Microphone spark sound effect problem on Ryzen cpus

2018-09-20 Thread Igor Filatov

Hi,

This is fprint mailing list for the fprint and libpfprint projets. I'm
guessing you need
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

On Wed, Sep 19, 2018 at 7:44 PM Vámos Balázs 
wrote:

> Hi.
>
> Today we spoke from linux in a Live what is our experience, problems
> etc. It turned out we have a fix problem on linux with a Ryzen cpu. A
> bugg of Pulseaudio.
>
> The problem is.. If we speak to microphone then theres have a spark
> sound in background. Only on Linux. Because on Windows operation system
> works finely. On linux doesnt. Just on Ryzen cpus. Ive tried on an
> intel laptop it works finely on it. And it isnt a hardware problem
> because in our community doesnt work for nobody.
>
> Can you fix this problem? Because we cannot make a stream/video on
> linux because always have a spark sound in background while we speak.
> We tried on Ubuntu, Linux Mint, MX Linux, Manjaro and Arcolinux.
> Nowhere.
>
> I am sorry for bad english because I am hungarian.
> I hope Ill get a reply.
>
> Balázs
>
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] fprintd single sign on limitation

2018-12-07 Thread Igor Filatov

I think Dave means that the scanner would capture the print when the device
is powered on. Not as instructed by a userspace driver, but as a "hardware
feature" of the button/sensor itself. It would store a single image until
asked by libfrint to perform a scan, at which point it would just submit
the image it has. libfprint doesn't need to know. It only needs to match
the print not aginst the library of a chosen user, but of all users and
return a pair of (ok, user_id).


On Fri, 7 Dec 2018, 14:36 Bastien Nocera,  wrote:

> Hello Dave,
>
> On Wed, 2018-11-14 at 10:13 +0800, Dave.Wang wrote:
> > Dear Bastien,
> >
> > Thanks for your quick reply!
> >
> > Feeling sorry for not indicating clearly about our definition of SSO
> > In our definition of SSO,
>
> What I was saying is that you shouldn't be using "SSO" as a name, it's
> already something that exists, and that is completely different from
> what you're describing below:
> https://en.wikipedia.org/wiki/Single_sign-on
>
> > 1. Our fingerprint sensor is located on power button of notebook
> > 2. Driver would inform device to pre-capture image while someone
> > touch the power button.
> > 3. In login phase, user wouldn't have to identify finger if the pre-
> > capture image is existed
> > 4. Driver would submit that pre-capture image to algorithm if the
> > pre-capture image is existed, and then login to its corresponding
> > account.
>
> I don't understand at which point the user-space driver would be able
> to tell the power button's IC to capture the image, or where that image
> would end up being stored. Would the driver tell that to the power
> button's IC/fingerprint reader before the machine gets turned off?
>
> > In your opinion, is it possible to implement SSO in libfprint?
> > Thank you very much for your time and suggestion!
>
> There are multiple steps to that, and the first one would be to extend
> fp_driver internally to allow setting that "remember fingerprint on
> next boot", as well as providing a way to extract the "remembered"
> fingerprint.
>
> After that, integration work into the OS can start. I think we would be
> taking cues from the smartcard integration done in gnome-settings-
> daemon[1] and integrate it in fprintd.
>
> Access to hardware and specs would be much appreciated if you want more
> help doing this integration. It's pretty difficult designing for a use
> case in a vacuum. I'd recommend looking into this once the work has
> been done in libfprint to support the hardware features.
>
> Cheers
>
> [1]:
> https://gitlab.gnome.org/GNOME/gnome-settings-daemon/tree/master/plugins/smartcard
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] fprintd help

2019-02-17 Thread Igor Filatov

Hello Rick,

If you want fingerprint login, sudo etc. then you're almost set. You should
only need `apt install libpam-fprintd` and then `sudo pam-auth-update`
where you enable "Fingerprint authentication".

On Sun, Feb 17, 2019 at 2:04 AM Rick Kamp  wrote:

> Hello all,
>
>
>
> Just yesterday I decided to dedicate a machine to the Linux OS (Mint
> Cinnamon) and learning all I can about Linux. After getting the OS up and
> running I was able to install the demo version of fprintd, enroll and
> verify a fingerprint. However, being a newb I’m at a loss how to install
> the working program. Would someone mind taking me to school? I would like
> it if all the features my old HP Pavilion dv6-6173cl worked.
>
>
>
> Kind regards,
>
>
>
> Rick
>
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Using fprint for logging into user or root

2019-07-03 Thread Igor Filatov

Hi Brian,

> how long does it take to identify a fingerprint (setting new fingerprint for 
> user) ? Speed is essential as it needs to happen fresh every bootup.

5 distinct images need to be captured, so I'd say no longer than 15
seconds if the scanner works well. But it's best to set up and see for
yourself whether you find the procedure acceptable or not. Personally
if I had to use such live cd I'd like fingerprint auth to be opt-in.

> can it be used to identify the user / root at all (su command ?)

it it currently not possible to *identify* a user by a fingerprint
(e.g. "find a user and log them in using this fp"). But it is possible
to su /sudo with fp auth (via a PAM module) because there is
always a pair of (, fingerprint) at the input.

> how "heavy" is gentoo's fprintd package (and what are the dependencies)

This is something I don't have in detail, esp. for Gentoo, but on the
high level you need libfprint (the drivers), fprintd (auth daemon) and
fprint PAM module. That shouldn't be too heavy.

On Tue, Jul 2, 2019 at 2:10 PM Brian Peregrine  wrote:
>
> Hi Hadess,
>
> On my linux system (live cd), I need to make a new password on bootup
> for any users, root, 
> I was thinking of the possibility to use fingerprint identification
> instead, to make this a bit safer and also more convenient.
> Some questions though:
>
> * how long does it take to identify a fingerprint (setting new
> fingerprint for user) ? Speed is essential as it needs to happen fresh
> every bootup.
> * can it be used to identify the user / root at all (su command ?)
> * how "heavy" is gentoo's fprintd package (and what are the dependencies) ?
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

Re: [fprint] Working with small sensors

2020-06-13 Thread Igor Filatov

> Is this a small sensor problem and is there really too little minutiae?

See https://cedar.buffalo.edu/~srihari/papers/RRP-full.pdf page 7 fig 3 e,f
where it says 20 and 15 minutiae. A 114x57 scan is roughly 1/3 of that
area. In my experience there's usually <5 minutiae on a 144x64 image.
That's way too little. For reliable matching I'd say you want at least 25.

> What are other options to make my device work, maybe by using multiple
images?

At least one driver is doing just that and it's... not the best UX ever
(even when it works) https://github.com/iafilatov/libfprint#common-problems

On Fri, Jun 12, 2020 at 5:05 PM Indev  wrote:

> I've heard that fprint matching doesn't work well with small sensors.
>
> In my case (issue #162
> ), the
> device returns 114x57 images and there is probably not much minutiae to
> extract. I am certain that it is a press sensor, even though it returns
> multiple images during communication. Despite the fact that it's hard to
> find any specification for the device, Acer Swift 3 promo
>  shows exactly that.
>
> When running enroll and then verify examples, I get "score 0" on every
> verify.
>
> Basically, my questions are:
>
>1. Is this a small sensor problem and is there really too little
>minutiae?
>2. What is the state of small sensors matching? Are there any working
>drivers for small sensors?
>3. How much minutiae is enough to work?
>4. In my driver code, how can i check minutiae count *before* calling
>fpi_image_device_image_captured, for example, to prevent submitting images
>with low minutiae count?
>5. What are other options to make my device work, maybe by using
>multiple images?
>
> ___
> fprint mailing list
> fprint@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
>
___
fprint mailing list
fprint@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fprint

54 matches

Mail list logo