[fprint] Improving the etes603 driver

[Vasily Khoruzhick]

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

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

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