[fprint] Improving the etes603 driver

[Jason Gerard DeRose]

Patrick,

On 08/21/2015 01:41 AM, Patrick Marlier wrote:
> Hi Jason and Vasily,
>
> On Fri, Aug 21, 2015 at 3:58 AM, Vasily Khoruzhick <anarsoul at gmail.com> wrote:
>> Hi Jason,
>>
>> On Thu, Aug 20, 2015 at 11:51 AM, Jason Gerard DeRose
>> <jason at system76.com> wrote:
>>> Hello,
>>>
>>> I work at System76 and am going to take a stab at improving the etes603
>>> driver (1c7a:0603) as it's the fingerprint reader used in our current
>>> generation hardware.
>>
>> Great!
>
> Indeed this is good news! :)
>
>
>>> 2.  etes603.c mentions a number of features not yet implemented in the
>>>     driver.  Of these missing features, any advise on where I should
>>>     start, what features are likely to yield the best improvement for
>>>     the effort when it comes to reliability and user experience?
>>
>> Patrick probably can answer these questions
>
> Humm I don't remember what we were the missing features apart from the
> LED control. What do you see in the driver?

etes603.c mentions:

1. Tuning of DTVRT for contact detection
2. Contact detection via capacitance
3. Capture mode using assembled frames (usually better quality)

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?

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?

>>> 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?

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

>>>     At a glance, this seems like a scenario that the driver should be
>>>     handling differently.  Is this true?  If so, can anyone describe
>>>     what the driver should do in this scenario instead?  I have example
>>>     log[*] output below from running against a libfprint deb I built
>>>     with `--enable-debug-log`.
>>>
>>> For what it's worth, I'm doing my development on Ubuntu Wily (libfprint
>>> 0.6.0, fprintd 0.6.0).
>>
>> Ubuntu is fine, but please use libfprint from git for development
>
> And also please do incremental patches (one commit per fix).

Will do!

>
>>> And a big thanks to everyone whose hard work gave the open source world
>>> all these great drivers and a great driver framework!
>>>
>>> Cheers,
>>> Jason
>>>
>>> [*]: Example log with --enable-debug-log enabled:
>>>
>>> etes603:debug [process_remove_fp_end] Removing 498 empty lines from image
>>> etes603:debug [process_remove_fp_end] Removing 496 empty lines from image
>
> This message is almost for sure due to calibration issue here.
>
> 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".

> --
> Pat
>