[fprint] vfs5011 support

[Vasily Khoruzhick]

Hi Per-Ola,

On Wed, Jan 14, 2015 at 7:02 PM, Per-Ola Gustavsson
<pellesmek+fprint at gmail.com> wrote:
> 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.

Not true. Did you hear anything about multiplexing and
select/poll/epoll syscalls?

>> 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.

As far as I remember, Daniel is an original author of libusb. But
maybe things changed since he stepped out from libusb development.

Regards,
Vasily

>
>>
>> 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
> _______________________________________________
> fprint mailing list
> fprint at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/fprint