[fprint] Unplug device while enrollment/verify process

[Benjamin Berg]

Hi,

On Mon, 2021-01-18 at 16:07 +0000, Carlos Garcia wrote:
> [SNIP] 
> I made a port of libfprint for Windows O.S. using MSYS2 and works
> fine. I have tested the examples provided in the library v1.90.6 for
> the enroll and verify processes in Linux (Ubuntu 18.04 LTS) and
> Windows using the device: Digital Persona U are U 4500.

So this is the uru4000 driver.

> When I testing the examples I found a possible error (really I don't
> known if really is an error or I'm not using correctly the library).
> When the process for Enroll or Verify is executing and ask for the
> FINGER ON, if I unplug the USB device then the user callback will
> never be called. Internally the device is DEACTIVATE so the state
> change to DEACTIVATE but the action remains as
> FPI_DEVICE_ACTION_ENROLL or FPI_DEVICE_ACTION_VERIFY according to the
> case. This is a problem because I'm never notified and it causes the
> app to hang.

Yeah, you should get a well defined behaviour. i.e. the following
happening (in this order):
 * "removed" property changes from FALSE to TRUE
 * enroll callback being called with error
 * "removed" signal is called
 * FpContext emits the "device-removed" signal

> If I plug the device again nothing happens, just a message saying it
> can't be bind.

Sounds odd. Because I wouldn't expect that the old still-open device is
a problem. I think some of these devices have different modes, so maybe
that is happening?

Note that you will get a new FpDevice when you plug it back in.

> If I prepare the examples for GCancellable, create a signal handler
> for SIGINT and execute g_cancellable_cancel inside the signal
> handler, nothing happens, it only indicates that the device is
> already DEACTIVATE
>  
> If I try to close the device I have an error FP_DEVICE_ERROR_BUSY.
> 
> So someone can help me?

This will be an issue with the uru4000 driver or the generic image
device abstraction. You can enable more debug output by setting
G_MESSAGES_DEBUG=all and maybe also FP_DEBUG_TRANSFERS=1.

This will give quite detailed information about the internal state
machine. Hopefully, it is then clear where the driver is getting stuck
instead of returning an error.

Feel free to open an issue in the libfprint bugtracker with that
information.

Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/fprint/attachments/20210118/3cdb9cda/attachment.sig>