[fprint] vfs5011 support

[Per-Ola Gustavsson]

On Wed, Jan 14, 2015 at 3:11 AM, Daniel Drake <dan at reactivated.net> wrote:
> Per-Ola Gustavsson wrote:
>>
>> Btw, the libfprint "SSM: sequential state machine" is quite flawed.
>> Why isn't there a normal message loop system and threading? Maybe glib
>> style? I haven't looked deeply into poll.c but I have a hunch it's
>> functionality should be reimplemented in a very different way.
>
>
> The idea was to use "zero threads" (i.e. to only use the thread of the
> process calling into the library). Why go to the expense of having a whole
> thread for tiny USB transactions? I was working with some very low power
> systems at the time.

"Zero threads" equals synchronous (and blocking) calls. Cannot be combinated
with asynchronous calls. Usually easier.

>
> Having implemented it like that though, I'm not sure it was worth it, as you
> note the code didn't turn out particularly small or readable. The SSM could
> probably be implemented to be cleaner/better, or indeed maybe moving to
> synchronous code running in threads would be sensible.
>

Nothing against the SSM really, could be a lot more helpful though keeping
track of states (including idle). I guess you could abstract infinitely....

>> vfs5011.c doesn't handle libusb async calls in a correct or polite
>> manner. It hi'jacks the thread of libusb and fills it's stack with
>> recursive calls and memory allocations. I believe this is causing race
>> conditions and other anomalies,
>
>
> libusb doesn't have a thread either, but that kind of code does indeed sound
> like it would be problematic.

So I put this nifty little function in fpi_log() (core.c):
g_thread_self()
I simply include it's return value in the debug output and I know which thread
the code currently is running in.

Here is my tweaked debug output:
[3.336136]Th:0x1b3b050 vfs5011:debug [usbexchange_loop] Receiving 2368 bytes
[3.336218]Th:0x1b3c810 vfs5011:debug [async_recv_cb] Happy with 2
Th:xxxx is the thread. The callback from libusb is in another thread, from my
perspective libusb DOES have a thread. I want to leave that thread as fast as
possible to avoid problems.

>
> Thanks
> Daniel
>
> _______________________________________________
> fprint mailing list
> fprint at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/fprint

As a footnote, there is a problem with libusb_device_handle, I think my device
resets itself, this invalidates the handle. I then get a -4 from libusb_open().
A workaround should be made in fprintd probably. Don't know if it would be
feasible in libfprint. At least document it.

Kind regards

Per-Ola Gustavsson
marsba.se