[fprint] Improving the etes603 driver

[Patrick Marlier]

Jason,

On 08/26/2015 05:57 PM, Jason Gerard DeRose wrote:
> Patrick,
>
> A little update on where I'm at with this.  Through many iterations of
> adding extra debug logging and removing logging that was too noisy and
> wasn't helpful to me, I've discovered a problem that at least seems to
> exist with the particular hardware I'm testing on.

Maybe some debugging output is not meaningful. Please keep track of it 
so that we can remove it from the driver. No need to pollute logs.

About your hardware, let's suppose this is due to calibration. Can you 
send me the full log? I can have a look and tell you what I think.


> The initial finger detection in m_finger_state() via reading raw frames
> in REG_MODE_SENSOR till a non-empty frame is read works flawlessly well
> prior to the first scan.  However, if the first scan fails (because not
> enough minutiae could be detected), on the next go m_finger_state() will
> *always* get a non-empty frame on the first frame it reads, even though
> my finger isn't on the sensor.

Yep I was trying to make the driver clever but the bad calibration makes 
the detection really bad. :(


> My hunch is the sensor is returning the frames used in the hardware-
> assembled image read in REG_MODE_FP, though I haven't confirmed that yet
> for sure.  But if I ignore the first X frames (currently I'm using
> X=125, which seems to work well), and only then have m_finger_state()
> interpret a non-empty frame as meaning your finger is on the sensor, I
> can work around this.

Not sure to follow here...


> However, in my experience thus far, the hardware-frame-assembly seems
> pretty low quality, at least with my finger.  That or REG_MODE_FP and
> REG_MODE_SENSOR fundamentally don't interact well for whatever reason.

Humm. The quality was not too bad for me for this REG_MODE_FP. I don't 
have sample but I will try to get access to the fingerprint device and 
send a capture to you.


> So my currently plan is to switch the etes603 driver to using software
> frame assembly, basically what you were doing prior to the driver being
> merged into libfprint.

Ok. You can have a look at my development repository if you did not yet 
because this was already there.
Damn it I think Google Code screwed my dev repository! :( 
(https://code.google.com/p/etes603/source/checkout?repo=dev)
I will try to find it and send it to you.


> Chatting with Vasily (anarsoul) on IRC, I learned that the internal
> libfprint aes_assemble() function in aeslib.c currently isn't generic
> enough for the etes603 driver to use, so I'll work up one patch to
> make aes_assemble() more generic (and update all its consumers), and
> then a 2nd patch to switch etes603 to reading only in REG_MODE_SENSOR,
> assembling the frames in software.

In this dev repo, I had also my own assemble function that worked pretty 
well for this device (obviously, you need to swipe in a reasonable time).


> Does this plan seem reasonable to you?

It sounds good but I would advise you also to take time and have a look 
at this calibration because it is a key point.


> Also, in your initial reverse engineering, how close did you get to
> figuring out how to make REG_MODE_CONTACT work (finger detection via
> capacitance)?  Do you think that's a route worth pursuing?

Testing, testing, testing over and over... and finally worked pretty 
well with my device. Again calibration is key.


> In my experience thus far, it seems REG_MODE_SENSOR is probably totally
> workable for finger detection when doing software frame assembly, and I
> get the impression that was your experience too.  What do you think?

Yep I used REG_MODE_SENSOR for a while but I changed to REG_MODE_CONTACT 
to reduce energy consumption and increase lifetime of the device if it 
has to wait a long time before something happen.


> Also, your blog post was fantastically useful, thanks!

Thanks a lot :) I am glad it finally helped someone!

Keep me posted.
--
Pat