[fprint] vfs5011 support

[Per-Ola Gustavsson]

vfs5011 is now really smooth and reliable. I have not looked at the
image processing for possible improvements, it is swipe speed
sensitive in my opinion. It would be nice to unlock more of the
functionality of this device, unfortunately it cannot dance but it can
flash red at failure! The driver is a crude hack at the moment. And
some cleanup would be nice.

I reverted some changes and the old driver aes2501 seem to be happy too.

On Wed, Jan 14, 2015 at 6:27 PM, Vasily Khoruzhick <anarsoul at gmail.com> wrote:
> 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?

Do not hear any of it in this case, libfprint is "asynchronous" and
don't utilize those
techniques for device communication. While there is great usage scenarios for
select/poll/epoll it is very much blocking and synchronous. Simple and reliable.
Let's use it!

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

Yes, I see his name in libusb.h. I dug though some of the code of
libusb, I now see that i missed a part in the reference manual, my
bad. Didn't realize it used the same weird "asynchronous" methods as
libfprint. It's more non-blocking than asynchronous. Making these
things cross platform is a challenge, I know, but this is plain weird
coding. It's time for change!

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

Regards

Per-Ola Gustavsson
marsba.se