[fprint] Improving the etes603 driver

[Jason Gerard DeRose]

Vasily,

On 08/20/2015 07:58 PM, Vasily Khoruzhick 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!
>
>> I'm just starting to get my head around the code and was hoping folks
>> here might be able to advise me on a few questions I currently have:
>>
>> 1.  What's the preferred workflow for making changes, building the
>>     library, and testing it?  In particular, can anyone point me to a
>>     good way to run the resulting build from the source tree without
>>     installing it?
>
> # do configure with custom prefix, enough to do it once
> ./configure --prefix=/home/user/tmp
>
> # Installs your changes into your home
> make all install
>
> LD_LIBRARY_PATH=/home/user/tmp/lib ./fprint_demo

Thanks, that's exactly what I was looking for!

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

Okay, I'll keep digging, thanks.

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

Yup, I'll definitely be developing against what's in git. Just to make 
sure I'm on the same page, I should be developing against the master 
branch here:

http://cgit.freedesktop.org/libfprint/libfprint/

Correct?

Is the preferred workflow to use git-format-patch and send it to this 
mailing list?

>> 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
>> fp:debug [fpi_img_new] length=0
>> etes603:debug [m_capture_state] Sending the raw fingerprint image (0x0)
>> fp:debug [fpi_imgdev_image_captured]
>> fp:error [sanitize_image] no image height assigned
>> fp:debug [fpi_imgdev_report_finger_status] finger removed
>> fp:debug [fpi_imgdev_report_finger_status] reporting enroll result
>> async:debug [fpi_drvcb_enroll_stage_completed] result -22
>> async:debug [fp_async_enroll_stop]
>> etes603:debug [dev_deactivate] deactivating
>> etes603:debug [m_exit_start] Switching device to idle mode
>> drv:debug [__ssm_call_handler] 0x16e3000 entering state 0
>> drv:debug [fpi_ssm_mark_completed] 0x17572a0 completed with status 0
>> etes603:debug [m_capture_complete] And it's over.
>> drv:debug [__ssm_call_handler] 0x16e3000 entering state 1
>> drv:debug [fpi_ssm_mark_completed] 0x16e3000 completed with status 0
>> etes603:debug [m_exit_complete] The device is now in idle state
>> fp:debug [fpi_imgdev_deactivate_complete]
>> async:debug [fpi_drvcb_enroll_stopped]
>>
>> _______________________________________________
>> fprint mailing list
>> fprint at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/fprint