[fprint] Improving the etes603 driver

[Patrick Marlier]

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