GitLab

Hi All,

I've got a python based project which I originally created to test different things while reverse engineering Validity sensor driver. Now this project is getting very close to fully supporting 138a:0097 and 06cb:009a devices (including the sensor storage API, and pairing + calibration logic).

I'd like to propose a generic DBus driver which will allow me (or any other 3rd party) to easily integrate with fprintd framework. Please share your ideas and tell me what you think.

The basic idea is very simple: I want to decouple the driver from the framework, so that the driver code can be distributed independently from the framework and have its own independent process environment and life cycle.

In a proposed architecture everything stays the same with an addition of a new virtual driver. This driver will look for a configuration which will tell it a bus name of a DBus service which implements the net.reactivated.Fprint.Device interface. When this driver is opened, it will create a DBus proxy where it will forward all requests to.

I've drafted an example based on virtual environment driver. It works well, however I think it should behave a bit different in future: instead of a single environment variable, it should use a directory with configuration files. As part of enumeration, an instance of this driver class will be created for each file in configuration directory. A third party driver package will install a configuration file in this directory. This configuration file will have a driver description and a "well known" bus name of a DBus service which implements net.reactivated.Fprint.Device.

A bit of reasoning why I think this is a good idea:

• it allows vendors to share propitiatory drivers under their own license without sharing sources (however enabling binary drivers is NOT the main goal of this issue. I'll be happy if someone can suggest an alternative solution which would allow everything else but this)
• it allows quick prototyping & delivery of drivers using something like Python
• in solves life-cycle problems for some sensors (more on that later)
• it is possible to create a generic Wine-based driver which will be using a real WINBIO backend

About the life-cycle problems: it looks like fprintd is an activation based service. It only starts when a DBus client makes a request and automatically shuts down after a while when no one is using it. While it is a nice approach in general, it does not work very well with some Validity sensors. Initiating a connection with such a sensor is an expensive operation and performing it on demand will force the user to wait. Furthermore it looks like my 0097 sensor has a memory leak somewhere in TLS setup routines (or perhaps it is a security feature - I'm not sure). If you establish too many TLS sessions, it simply locks up for a couple of hours. Then it reboots and can be paired again with.

In addition to that, depending a senor state, it may need to be paired & calibrated before use. During the pairing process the device usually reboots a couple of times which causes USB device to be unplugged and plugged back in, and while I'm sure libfprint can handle all that, it further complicates the driver. Another problem is dealing with firmware images. We can't distribute them with libfprint, so for each installation we need to download them from a vendor website. I know that @3v1n0 has created a perfect CLI tool which is doing exactly that, but I think a better UX would be to do that as part of the package configuration. This way there will be no need to run any additional commands before using the sensor. Of course the package the user is installing must be specific enough.