[fprint] Planning libfprint API changes (2.x)

[Benjamin Berg]

Hi everyone,

so, I have worked on this for a while now, and I pushed my changes to
the
  https://gitlab.freedesktop.org/libfprint/libfprint/commits/wip/benzea/v2
branch.

This is not yet quite complete. Some changes are more invasive, others
are less so. Most drivers have been ported at this point (fixing a
number of issues in the process). Unfortunately, I have only been able
to test two of the drivers on real hardware.

It would be great if people could take a look and test this. For
testing, you have two ways:
 * Grab the git repository and build locally
   - Run demo/gtk-libfprint-test as root from the build directory
 * Grab the flatpak from the CI pipeline, then:
   - Add e.g. the flathub repository (by going to flathub.org)
   - flatpak install org.gnome.Platform/x86_64/3.32
   - flatpak install --no-deps --bundle DOWNLOADED_FLATPAK
   - Make sure your user can access the USB device in /dev/bus/usb
   - flatpak run org.freedesktop.libfprint.Demo

When testing, please watch out for warnings that may need to be fixed.

I am planning in adding a way to record a trace of the USB traffic. The
idea is that we can run a basic simulation as a CI test. But I am not
sure how this will look like in the end.

Some of the highlights:
 * Working CI using a new virtual image driver
 * Generation of GIR data (i.e. various language bindings)
 * More convenient USB API for drivers

From the user perspective, the API changes in the following ways:
 * Use of GLib style asynchronous API with cancellation handling
 * A new FpContext object, that handles enumeration and hotplugging
 * FpPrint (was struct fp_print) can now stores some more metadata:
   - Username
   - Description
   - Enroll Date
 * The enroll call now takes a template print, this is so that the
   driver could make use of the above metadata.
 * Retry conditions are just errors, but they are in the
   FP_DEVICE_RETRY error domain.
 * New "list" and "delete" commands (not quite there but this is purely
   something for the drivers to handle).
 * Requires GLib mainloop

On the drivers side, the API has not changed as much. There are a
number of changes in the boilerplate code though and changed function
names. Other than that:
 * Updated custom USB transfer API (no libusb anymore)
   - Starting a transfer always succeeds (simplified error handling)
   - More convenient parameters for the callback function
 * Changed error reporting (GError instead of pure integer)

Comments and feedback are welcome!

Benjamin

On Tue, 2019-06-18 at 10:48 +0200, Benjamin Berg wrote:
> I realised that I only had talked to a few individuals about this, so
> it seems like a good idea to inform the ML about some of the ideas.
> 
> The current situation is that we are looking at adding support for
> devices that store the print data in the sensor. With these devices,
> a
> few new operations will be necessary:
> 
>  * Deleting prints from the device when deleting them from the host
>    
> https://gitlab.freedesktop.org/libfprint/libfprint/merge_requests/54
>  * Garbage collecting old prints
>    (e.g. left over from e.g. old installations)
>    - Listing prints from the device
>    - Deleting prints that are unknown on the host
> 
> Another important change is to support non-USB devices. My main
> motivation for this right now is adding virtual devices for testing
>   
> https://gitlab.freedesktop.org/libfprint/libfprint/merge_requests/53
> 
> 
> After some discussions, the idea is to bump the soname/version of
> libfprint and then add the required API for the mentioned sensors.
> Doing so also gives us the chance to clean up the external API.
> 
> I am currently looking into this, considering the following:
>  * A GLib based external (and internal API)
>    - Allows proper async operations and cancellation
>    - Use GError for error reporting; so that applications don't
>      need to assume libusb error codes
>    - Removes the need for custom mainloop code
>  * Possibly port libfprint to libgusb rather than libusb
>    - Hopefully easier integration with the above changes
>  * Dropping the special fp_dscv_dev and just having an fp_dev
>    that needs to be opened/closed.
>  * Handling fp_imgdev as a "subclass" (i.e. with the fp_dev struct
>    embedded at the start). Maybe even as a GObject.
> 
> This will to result in a lot of collateral changes in all drivers.
> 
> Benjamin
> _______________________________________________
> fprint mailing list
> fprint at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fprint
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/fprint/attachments/20190710/5a612c8d/attachment.sig>