I think Dave means that the scanner would capture the print when the device is powered on. Not as instructed by a userspace driver, but as a "hardware feature" of the button/sensor itself. It would store a single image until asked by libfrint to perform a scan, at which point it would just submit the image it has. libfprint doesn't need to know. It only needs to match the print not aginst the library of a chosen user, but of all users and return a pair of (ok, user_id).
On Fri, 7 Dec 2018, 14:36 Bastien Nocera, <had...@hadess.net> wrote: > Hello Dave, > > On Wed, 2018-11-14 at 10:13 +0800, Dave.Wang wrote: > > Dear Bastien, > > > > Thanks for your quick reply! > > > > Feeling sorry for not indicating clearly about our definition of SSO > > In our definition of SSO, > > What I was saying is that you shouldn't be using "SSO" as a name, it's > already something that exists, and that is completely different from > what you're describing below: > https://en.wikipedia.org/wiki/Single_sign-on > > > 1. Our fingerprint sensor is located on power button of notebook > > 2. Driver would inform device to pre-capture image while someone > > touch the power button. > > 3. In login phase, user wouldn't have to identify finger if the pre- > > capture image is existed > > 4. Driver would submit that pre-capture image to algorithm if the > > pre-capture image is existed, and then login to its corresponding > > account. > > I don't understand at which point the user-space driver would be able > to tell the power button's IC to capture the image, or where that image > would end up being stored. Would the driver tell that to the power > button's IC/fingerprint reader before the machine gets turned off? > > > In your opinion, is it possible to implement SSO in libfprint? > > Thank you very much for your time and suggestion! > > There are multiple steps to that, and the first one would be to extend > fp_driver internally to allow setting that "remember fingerprint on > next boot", as well as providing a way to extract the "remembered" > fingerprint. > > After that, integration work into the OS can start. I think we would be > taking cues from the smartcard integration done in gnome-settings- > daemon[1] and integrate it in fprintd. > > Access to hardware and specs would be much appreciated if you want more > help doing this integration. It's pretty difficult designing for a use > case in a vacuum. I'd recommend looking into this once the work has > been done in libfprint to support the hardware features. > > Cheers > > [1]: > https://gitlab.gnome.org/GNOME/gnome-settings-daemon/tree/master/plugins/smartcard > > _______________________________________________ > 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
