Comment 43 for bug 790183

(In reply to comment #12)
> > Could you implement some check too see if initialization was completed
> > earlier? Maybe some register value changes after init, etc?
>
> Unfortunately I don't know how to query registers on this device. During
> initialization I'm sending some blobs and occasionally read something back,
> but I have no idea what it all means :-/

Maybe it makes sense to reverse-engineer protocol a bit? I'll take a look at it probably this weekend

> But it does not harm to do this initialization many times. It would not harm
> to do it every time dev_activate is called – the hardware seems to be fine
> with that.
>
> The only problem is how to handle the delay which happens during this
> initialization properly, so that it won't disappoint the user.
>
>
> > Library doesn't expect any device init in dev_open, so it's not a good idea.
>
> But is there some technical reason why it should not be there right now? I
> mean, can this (doing device initialization in dev_open) break things, cause
> incorrect behavior in some situations?

Yes, there's no synchronization points for dev_open, so you can't use async transfers in it, and synchronous transfers are not allowed in libfprint.

> By the way, I also have an unrelated question. If an application opens the
> device and then enrolls/verifies/identifies fingers a few times, will
> dev_activate be called every time when the finger needs to be scanned, or
> just once?

Depends on libfprint internal usage. Current master calls dev_activate for each scan, but I've a pending commit that changes enroll routine to perform 5 scans, and it uses single dev_activate for 5 scans.

> Sorry, I cannot chat now, I don't have more time today.

OK