On 08/27/2015 01:07 AM, Jason Gerard DeRose wrote:
Patrick,

On 08/26/2015 02:53 PM, Patrick Marlier wrote:
Jason,

On 08/26/2015 05:57 PM, Jason Gerard DeRose wrote:
Patrick,

A little update on where I'm at with this.  Through many iterations of
adding extra debug logging and removing logging that was too noisy and
wasn't helpful to me, I've discovered a problem that at least seems to
exist with the particular hardware I'm testing on.
Maybe some debugging output is not meaningful. Please keep track of it
so that we can remove it from the driver. No need to pollute logs.
Okay, will do. From what I recall, it was the USB traffic logging that
was difficult to deal with, but I could certainly see a use for it.

Right now my branch is a big mess of experiments I've done in trying to
understand the driver. But when I can I'll step back and study my diff
from master, see if there is anything actually useful that I've done.

About your hardware, let's suppose this is due to calibration. Can you
send me the full log? I can have a look and tell you what I think.
Here's the logging bits on calibration:

etes603:debug [m_tunedc_state] Tuning DCoffset
etes603:debug [m_tunedc_state] Testing DCoffset=0x1A Gain=0x23
etes603:debug [m_tunedc_state] Testing DCoffset=0x27 Gain=0x23
etes603:debug [m_tunedc_state] Testing DCoffset=0x2E Gain=0x23
etes603:debug [m_tunedc_state] Testing DCoffset=0x31 Gain=0x23
etes603:debug [m_tunedc_state] Testing DCoffset=0x2F Gain=0x23
etes603:debug [m_tunedc_state] Testing DCoffset=0x30 Gain=0x23
etes603:debug [m_tunedc_state] -> DCoffset=0x32 Gain=0x23
Humm strange. I was expecting at least that the DCoffset=0x32 or more to 
be tested before to go back to 0x32 but I forgot a bit the details. At 
least the value sounds reasonable.
drv:debug [fpi_ssm_mark_completed] 0xbb1350 completed with status 0
etes603:debug [m_tunevrb_state] Tuning of VRT/VRB
etes603:debug [m_tunevrb_state] Testing VRT=0x0A VRB=0x10
etes603:debug [process_hist] fullb=0.779948 black=0.212240 grey=0.220052
white=0.007812 fullw=0.000000
etes603:debug [m_tunevrb_state] Testing VRT=0x09 VRB=0x0F
etes603:debug [process_hist] fullb=0.580729 black=0.325521 grey=0.411458
white=0.085938 fullw=0.007812
etes603:debug [m_tunevrb_state] -> VRT=0x09 VRB=0x0F
This one could be probably improved a bit but the overall balance is ok.


Does that seem reasonable, or do you spot anything off there?
Sounds really reasonable.


However, in my experience thus far, the hardware-frame-assembly seems
pretty low quality, at least with my finger.  That or REG_MODE_FP and
REG_MODE_SENSOR fundamentally don't interact well for whatever reason.
Humm. The quality was not too bad for me for this REG_MODE_FP. I don't
have sample but I will try to get access to the fingerprint device and
send a capture to you.
I think instead of "poor quality" I probably should have said "seems
totally broken", at least on the hardware I'm testing on.
Outch. Too bad :( You don't even got an kind of fingerprint?


Like you said, probably a tuning issue. Perhaps the revision of etes603
I'm testing on needs a somewhat different tuning strategy.

The other thing I've wondered about is timing issues, wondered where
exactly my finger is at on the sensor when it gets around to reading in
REG_MODE_FP, whether my finger is still actually on the sensor at that
time.

It's a bit difficult to match up the outgoing logging output temporally
with what I'm doing physically, but from the images I'm getting from
fprint_demo, my gut reaction is, "that's not a fingerprint, it must have
just been capturing the air!". Like you said, tuning, tuning :D
Yeah... Keep me posted on how we could make it work together. I can try 
to get access to the fingerprint device, we can try to schedule a 
debugging session, we can try to disable auto tuning and check how to 
fix the tuning...
Maybe we should talk offlist from now and only CCed the list when we 
have something useful to the list.
--
Pat
_______________________________________________
fprint mailing list
fprint@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/fprint

Reply via email to