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 < > benja...@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@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/fprint > > > > > > _______________________________________________ > > > fprint mailing list > > > fprint@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/fprint > > > > > > _______________________________________________ > > 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
