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).<div> <div class="gmail_quote"><div dir="ltr">On Fri, 7 Dec 2018, 14:36 Bastien Nocera, <<a href="mailto:hadess@hadess.net">hadess@hadess.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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: <a href="https://en.wikipedia.org/wiki/Single_sign-on" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Single_sign-on</a> > 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]: <a href="https://gitlab.gnome.org/GNOME/gnome-settings-daemon/tree/master/plugins/smartcard" rel="noreferrer" target="_blank">https://gitlab.gnome.org/GNOME/gnome-settings-daemon/tree/master/plugins/smartcard</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></div>