<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#0b5394">Hello,</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small;color:#0b5394">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.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">-- Best Regards, Mozammel HossainM: +95 9786256424</div></div></div></div></div></div></div></div></div></div></div> </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 12, 2019 at 7:28 PM Benjamin Berg <<a href="mailto:benjamin@sipsolutions.net">benjamin@sipsolutions.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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: <a href="https://github.com/martinpitt/umockdev/pull/92" rel="noreferrer" target="_blank">https://github.com/martinpitt/umockdev/pull/92</a> 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 > <a href="https://gitlab.freedesktop.org/libfprint/libfprint/commits/wip/benzea/v2" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/libfprint/libfprint/commits/wip/benzea/v2</a> > 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 <a href="http://flathub.org" rel="noreferrer" target="_blank">flathub.org</a>) > - 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 > > > > <a href="https://gitlab.freedesktop.org/libfprint/libfprint/merge_requests/54" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/libfprint/libfprint/merge_requests/54</a> > > * 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 > > > > <a href="https://gitlab.freedesktop.org/libfprint/libfprint/merge_requests/53" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/libfprint/libfprint/merge_requests/53</a> > > > > > > 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 > > <a href="mailto:fprint@lists.freedesktop.org" target="_blank">fprint@lists.freedesktop.org</a> > > <a href="https://lists.freedesktop.org/mailman/listinfo/fprint" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/fprint</a> > > _______________________________________________ > fprint mailing list > <a href="mailto:fprint@lists.freedesktop.org" target="_blank">fprint@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/fprint" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/fprint</a> _______________________________________________ fprint mailing list <a href="mailto:fprint@lists.freedesktop.org" target="_blank">fprint@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/fprint" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/fprint</a></blockquote></div>