[fprint] Improving the etes603 driver

[Jason Gerard DeRose]

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.

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.

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.

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.

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.

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.

Does this plan seem reasonable to you?

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?

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?

Also, your blog post was fantastically useful, thanks!

Thanks!
-Jason

On 08/24/2015 04:26 AM, Patrick Marlier wrote:
> Jason,
>
> On Fri, Aug 21, 2015 at 6:18 PM, Jason Gerard DeRose <jason at system76.com> wrote:
>> etes603.c mentions:
>>
>> 1. Tuning of DTVRT for contact detection
>> 2. Contact detection via capacitance
>
> Those 2 are the calibration issue for detecting a finger.
>
>> 3. Capture mode using assembled frames (usually better quality)
>
> Hum I do remember now. In my first version of the driver, I had 2
> modes: manual assembled frame and automatic using hardware feature. I
> was getting great result with manual but to get it into the trunk I
> simplified the driver.
>
>
>> Pardon my ignorance, but I don't quite understand what you mean by LED
>> control.  Is there an LED that shines up through the sensor to light your
>> finger while scanning?
>
> Depends on the hardware you have.
>
>
>> If LED control is currently missing, does that mean the LED is off, or just
>> that the LED is at whatever default output level the hardware sets?
>
> This is whatever default output but AFAIK it is off. My device did not
> have this feature but somebody reported it to me. We managed to find
> the command to control the LED but I did not implement it in the
> trunk.
>
> You have some low-level information on http://pmarlier.free.fr/etes603.html .
>
>>>>> 3.  For whatever reason, this sensor and the current driver really
>>>>>      don't like my fingers (which is actually great for testing).  When
>>>>>      trying to enroll, frequently the etes603 driver will remove so many
>>>>>      "empty" lines that the resulting image is less than 8 lines high,
>>>>>      after which block_offsets() in nbis/mindtct/block.c will return an
>>>>>      error, ultimately resulting in the device being put back into an
>>>>>      idle state and fpintd-enroll failing with 'enroll-unknown-error'.
>>>>
>>>>
>>>> Hm, enroll-unknown-error doesn't look good. I guess you'll need to
>>>> debug it further.
>>>
>>>
>>> This is a calibration issue. Either from the detection calibration or
>>> the contrast calibration.
>>> I think generally the calibration should be completely revisited.
>>> Indeed, when I developed the driver I had only one device to test that
>>> probably led to bad assumptions.
>>>
>>
>> In the process of trying to better tune the revision/model System76 is
>> currently shipping, I of course don't want to cause regression on other
>> revisions/models.
>>
>> So I'm trying to understand how much the fact that it has USB ID 1c7a:0603
>> actually tells me about what exact hardware it is and how it will behave.
>> Any wisdom you can share here?
>>
>> Is there other information about the hardware, like a revision or sub-ID,
>> that I can use to enable revision/model specific conditional code paths if
>> needed?
>
> See also my webpage. When I sniffed the USB, I have noticed some kind
> of device id. But no guarantee since I don't have the specification of
> the protocol. Maybe System76 can ask EgisTec to get them?
>
>
>> Also, do you still have the original hardware you developed this driver
>> against?  If so, and if you wouldn't mind, I'd be keen on having you verify
>> that I didn't break things there :D
>
> I can still get access to it but not easily. When your changes are
> stable, I can give a try.
> However, if you want something stable, I would advise you to test on
> at least 3 different devices.
>
>
>>> Feel free to contact me directly if you have any questions.
>>> Have a good day,
>>
>> Okay, thanks!  FYI, I've been idling in the #fprint IRC channel on freenode.
>> My nick is "jderose".
>
> Unfortunately, I cannot be on IRC. So let's continue with emails or if
> we need at some point we can setup a phone call.
>
> Have a good day,
> --
> Pat
>