On 25 June 2014 09:33:37 Timo Teras wrote:
> On Wed, 25 Jun 2014 09:15:29 +0300
>
> Vasily Khoruzhick wrote:
> > > It did. Thanks. Forget the earlier patch, it's irrelevant and the
> > > original code is right. Seems the bug is in the generic code and
> > > affects all drivers that are capable of
On Wed, 25 Jun 2014 09:15:29 +0300
Vasily Khoruzhick wrote:
> > It did. Thanks. Forget the earlier patch, it's irrelevant and the
> > original code is right. Seems the bug is in the generic code and
> > affects all drivers that are capable of 'finger present' detection.
> >
> > It seems to be a
On 25 June 2014 09:06:41 Timo Teras wrote:
> On Tue, 24 Jun 2014 22:01:24 +0200
>
> Martin Hejnfelt wrote:
> > Here's the output, this is just the examples/enroll.c which does the
> > same as my own app (which is using async calls).
> > I've inserted the "* * * " output via fp_dbg just to make it
On Tue, 24 Jun 2014 22:01:24 +0200
Martin Hejnfelt wrote:
> Here's the output, this is just the examples/enroll.c which does the
> same as my own app (which is using async calls).
> I've inserted the "* * * " output via fp_dbg just to make it a
> bit easier (for myself) to see whats going on...
>
On Tue, 2014-06-24 at 22:46 +0300, Timo Teras wrote:
> On Tue, 24 Jun 2014 21:19:25 +0200
> Martin Hejnfelt wrote:
>
> > If it gives any clues, I can see that after the first stage, then the
> > imaging run state machine (imaging_run_state) is just blazing through
> > its states,
> > IMAGING_CAP
On Tue, 24 Jun 2014 21:19:25 +0200
Martin Hejnfelt wrote:
> If it gives any clues, I can see that after the first stage, then the
> imaging run state machine (imaging_run_state) is just blazing through
> its states,
> IMAGING_CAPTURE -> IMAGING_SEND_INDEX -> IMAGING_DECODE ->
> IMAGING_REPORT_IM
Hi Paolo,
Just to tell you that I can reproduce the problem on my machine. However
I have no clue yet on why it happens with the enroll example. I am not
sure when I will have time to dig more so you can try to use
fprintd-enroll (it was working months, or years ago).
Regards,
--
Patrick
On
Hi again,
If it gives any clues, I can see that after the first stage, then the
imaging run state machine (imaging_run_state) is just blazing through
its states,
IMAGING_CAPTURE -> IMAGING_SEND_INDEX -> IMAGING_DECODE ->
IMAGING_REPORT_IMAGE -> IMAGING_CAPTURE -> ...
in an endless loop...
Martin
On Tue, 2014-06-24 at 21:34 +0300, Timo Teras wrote:
> Would the following fix it?
>
> --- a/libfprint/drivers/uru4000.c
> +++ b/libfprint/drivers/uru4000.c
> @@ -773,11 +773,7 @@ static void imaging_run_state(struct fpi_ssm *ssm)
> if (!urudev->profile->encryption)
>
On Tue, 24 Jun 2014 19:39:26 +0200
Martin Hejnfelt wrote:
> I'm using a Digital Persona U.are.U 4500 and using the current
> libfprint from git. I can see in the git log that there were some
> changes in the nr_enroll_stages, that was changed to 5 for all
> devices. This seems to not make the U.a
Hi,
I'm using a Digital Persona U.are.U 4500 and using the current libfprint
from git. I can see in the git log that there were some changes in the
nr_enroll_stages, that was changed to 5 for all devices. This seems to
not make the U.are.U 4500 happy, as it goes into some sort of disco
mode, upon
Hi Paolo,
Not sure if this could be the culprit of your problem, but the Raspberry
Pi has some serious USB issues depending on which kernel and kernel
parameters you are using. I've had similar issues with other USB
devices, especially a FTDI USB-RS232 converter.
Try running a "BRANCH=next rpi-up
12 matches
Mail list logo
