fprintd issueshttps://gitlab.freedesktop.org/libfprint/fprintd/-/issues2021-02-05T18:00:26Zhttps://gitlab.freedesktop.org/libfprint/fprintd/-/issues/85New D-Bus APIs (or API additions)2021-02-05T18:00:26ZMarco TrevisanNew D-Bus APIs (or API additions)We had some preliminary discussions with @benzea about various dbus API additions we would need, so trying to get an incomplete and to-be-updated list here (feel free to edit this comment to add whatever you think is needed).
In the dev...We had some preliminary discussions with @benzea about various dbus API additions we would need, so trying to get an incomplete and to-be-updated list here (feel free to edit this comment to add whatever you think is needed).
In the device scope:
- [ ] Add `supports-identification` property and `IdentifyFingerStart/IdentifyFingerStop` methods
- It will be used by the enroll / prints manager dialog to identify the finger so that
the user can test the enrolled fingers
- Will be used by the login screen so that can be "swipe any finger"
- [ ] ~~Add `SetPreferredFinger` for devices with no identification support~~
- ~~So that the user can select the preferred finger to be used at verification phase when there's no user interaction (i.e. at login screen)~~
- This could be just done by making the UI not accepting more than one print, and the cmd-line tools to warn
- [ ] Add `DeleteEnrolledFinger` method
- Manage prints UI [dialog design](https://gitlab.gnome.org/Teams/Design/settings-mockups/-/issues/18) should allow to remove a single print
- [ ] Add `finger-on-sensor` property:
- Enroll dialog should highlight the finger when the sensor is touched during enrollment
- [GNOME shell unlock dialog](https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/56) should highlight the fingerprint icon when user has a finger on it
- [ ] Make fingerprints to have a customized label (this was a design request, not sure fprintd should handle it)
- [x] Device `added`/`removed` signalling on hotplugging (this is somewhat already handled as we're going to use an object manager)
- [ ] Device `available` property to provide dummy devices for print listing/deletion if devices are currently unplugged.
- [ ] A generic Manager's `Identify` method that will identify any user on any device (to allow login without having to select an user name).
TODO:
* Do we need new API for libfprint#256 (device initiated resume with immediate verify)
Most of the required things here can be just added, and in case clients can handle the `DBus.Error.UnknownMethod` in case (even without bothering adding a different interface IMHO), however...
Given that now we're almost past the gdbus port, we were also considering the idea that maybe we could just refactor the whole DBus API (maybe putting it into the FDO namespace, at this point).
I'd imagine a such iface would imply that when we start a device action, we return an object that can be used to stop the operation and get notified about the results of it.
Maybe something like this (was quickly drafted, so I might have forgot things):
```xml
<!DOCTYPE node PUBLIC
"-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" >
<node xmlns:doc="http://www.freedesktop.org/dbus/1.0/doc.dtd">
<interface name="org.freedesktop.Fprintd1.Manager">
<!-- No need to implement get devices, as it will be handled by the object manager -->
<method name="GetDefaultDevice">
<arg type="o" name="device" direction="out" />
</method>
</interface>
<interface name="org.freedesktop.Fprintd1.Device">
<method name="Claim">
<arg type="s" name="username" direction="in" />
<arg type="o" name="claimed_device" direction="out" />
</method>
</interface>
<interface name="org.freedesktop.Fprintd1.ClaimedDevice">
<method name="Enroll">
<arg type="s" name="finger_name" direction="in" />
<arg type="o" name="enroll_action" direction="out" />
</method>
<method name="Verify">
<arg type="s" name="finger_name" direction="in" />
<arg type="o" name="verify_action" direction="out" />
</method>
<method name="Release" />
</interface>
<interface name="org.freedesktop.Fprintd1.EnrollAction">
<!-- Maybe move this to a more generic DeviceAction interface -->
<method name="Stop" />
<property name="enroll-status" type="s" access="read" />
<signal name="done">
<arg type="b" name="done" />
</signal>
</interface>
<interface name="org.freedesktop.Fprintd1.VerifyAction">
<!-- Maybe move this to a more generic DeviceAction interface -->
<method name="Stop" />
<property name="selected-finger" type="s" access="read" />
<property name="verify-status" type="s" access="read" />
</interface>
</node>
```2.0https://gitlab.freedesktop.org/libfprint/fprintd/-/issues/4Port API docs to gdbus-codegen2020-11-26T11:20:09ZBugzilla Migration UserPort API docs to gdbus-codegen## Submitted by Bastien Nocera
**[Link to original bug (#90594)](https://bugs.freedesktop.org/show_bug.cgi?id=90594)**
## Description
When we've ported most of the code to GDBus, we can start using gdbus-codegen to create the gtk-do...## Submitted by Bastien Nocera
**[Link to original bug (#90594)](https://bugs.freedesktop.org/show_bug.cgi?id=90594)**
## Description
When we've ported most of the code to GDBus, we can start using gdbus-codegen to create the gtk-doc docbook.
See https://github.com/hadess/iio-sensor-proxy/ for an examplehttps://gitlab.freedesktop.org/libfprint/fprintd/-/issues/1Fprintd-enroll should maybe show some info or feedback when fingerprints are ...2020-02-14T15:09:10ZBugzilla Migration UserFprintd-enroll should maybe show some info or feedback when fingerprints are entered.## Submitted by goldie
**[Link to original bug (#79723)](https://bugs.freedesktop.org/show_bug.cgi?id=79723)**
## Description
Fprintd-enroll could tell user that it expects multiple scans. Since the message after first scan is somet...## Submitted by goldie
**[Link to original bug (#79723)](https://bugs.freedesktop.org/show_bug.cgi?id=79723)**
## Description
Fprintd-enroll could tell user that it expects multiple scans. Since the message after first scan is something like "Success" users might think that that's all, and quit or just wait for the program to quit, and therefore fail to actually enter any fingerprint data.