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

Tue Aug 13 09:26:28 UTC 2019

Hi,

that is useful in general. For now I am focused on ensuring that
already working devices keep working though; i.e. fixing non-functional 
devices is not a priority for me currently.

Could you maybe check that there is a bug open on
  https://gitlab.freedesktop.org/libfprint/libfprint/issues
with the USB ID of the device that is not working for you?

Benjamin

On Tue, 2019-08-13 at 14:02 +0630, Md Mozammel Hossain wrote:
> Hello,
> I do have a Xiaomi laptop which use Elantech device, currently its
> not working even though it on supported device list. I can help to
> test new driver.
> --
> Best Regards,
> Mozammel Hossain
> M: +95 9786256424
> 
> 
> On Mon, Aug 12, 2019 at 7:28 PM Benjamin Berg <
> benjamin at sipsolutions.net> wrote:
> > Hi,
> > 
> > I am wrapping up the libfprint update, and I am also adding
> > automated
> > tests using umockdev. In the future, it will be mandatory for
> > drivers
> > to ship a simple umockdev based test case.
> > 
> > This is something where I would really appreciate help. If anyone
> > has a
> > device, please have a look at the test/README-umockdev and submit a
> > new
> > test for it.
> > 
> > Please note, that umockdev currently has a bug, this may cause
> > random
> > test failures. So if the created test fails sometimes, this is to
> > be
> > expected:
> >   https://github.com/martinpitt/umockdev/pull/92
> > 
> > 
> > At this point all drivers are ported. A lot of them have not been
> > tested though, so any help here is still appreciated (also, see
> > above
> > for submitting automated tests).
> > 
> > Known to be working:
> >  * vfs101
> >  * upektc_img
> >  * aes2660 and aes1660
> >  * aes2550
> >  * synaptics (new)
> > 
> > Known to have issues:
> >  * etes603
> > 
> > I should have an elan device soon, but if anyone can test it, that
> > would be useful.
> > 
> > Benjamin
> > 
> > On Wed, 2019-07-10 at 14:09 +0200, Benjamin Berg wrote:
> > > 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
> > > 
> > > _______________________________________________
> > > fprint mailing list
> > > fprint at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/fprint
> > 
> > 
> > _______________________________________________
> > 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/20190813/0a71b655/attachment-0001.sig>