New 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 device scope:
-
Add supports-identification
property andIdentifyFingerStart/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"
-
AddSetPreferredFinger
for devices with no identification supportSo 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 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 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) -
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 (closed) (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):
<!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>