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