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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/fprint
signature.asc
Description: This is a digitally signed message part
_______________________________________________ fprint mailing list fprint@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/fprint
