Hi Jason, On Thu, Aug 20, 2015 at 11:51 AM, Jason Gerard DeRose <ja...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/fprint _______________________________________________ fprint mailing list fprint@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/fprint
