Attachment 69484 Details for Bug 56715 – 0001-AES2501-wait-for-3-empty-frames-to-stop-scan.patch

[patch] 0001-AES2501-wait-for-3-empty-frames-to-stop-scan.patch

0001-AES2501-wait-for-3-empty-frames-to-stop-scan.patch (text/plain), 3.31 KB, created by Vasily Khoruzhick on 2012-11-03 13:21:05 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Vasily Khoruzhick

Created: 2012-11-03 13:21:05 UTC

Size: 3.31 KB

patch

obsolete

>From a272036ea76fce9c3d00aa3e33354e771859ec52 Mon Sep 17 00:00:00 2001
>From: Vasily Khoruzhick <anarsoul@gmail.com>
>Date: Sat, 3 Nov 2012 16:08:04 +0300
>Subject: [PATCH 1/2] AES2501: wait for 3 empty frames to stop scan
>
>Until now driver stoped scan immideately after empty frame (with hist sum == 0)
>was received, but sometimes we get empty frames in the middle of scan (maybe
>because finger pressure is to low?), as result driver got incomplete image.
>Wait for 3 empty frames to fix this issue.
>---
> libfprint/drivers/aes2501.c | 41 +++++++++++++++++++++++------------------
> 1 file changed, 23 insertions(+), 18 deletions(-)
>
>diff --git a/libfprint/drivers/aes2501.c b/libfprint/drivers/aes2501.c
>index 617bb64..f002b93 100644
>--- a/libfprint/drivers/aes2501.c
>+++ b/libfprint/drivers/aes2501.c
>@@ -67,6 +67,7 @@ struct aes2501_dev {
> 	GSList *strips;
> 	size_t strips_len;
> 	gboolean deactivating;
>+	int no_finger_cnt;
> };
> 
> typedef void (*aes2501_read_regs_cb)(struct fp_img_dev *dev, int status,
>@@ -559,12 +560,6 @@ static void capture_read_strip_cb(struct libusb_transfer *transfer)
> 		goto out;
> 	}
> 
>-	/* FIXME: would preallocating strip buffers be a decent optimization? */
>-	stripdata = g_malloc(192 * 8);
>-	memcpy(stripdata, data + 1, 192*8);
>-	aesdev->strips = g_slist_prepend(aesdev->strips, stripdata);
>-	aesdev->strips_len++;
>-
> 	threshold = regval_from_dump(data + 1 + 192*8 + 1 + 16*2 + 1 + 8,
> 		AES2501_REG_DATFMT);
> 	if (threshold < 0) {
>@@ -572,27 +567,36 @@ static void capture_read_strip_cb(struct libusb_transfer *transfer)
> 		goto out;
> 	}
> 
>-    sum = sum_histogram_values(data + 1 + 192*8, threshold & 0x0f);
>+	sum = sum_histogram_values(data + 1 + 192*8, threshold & 0x0f);
> 	if (sum < 0) {
> 		fpi_ssm_mark_aborted(ssm, sum);
> 		goto out;
> 	}
> 	fp_dbg("sum=%d", sum);
> 
>-	/* FIXME: 0 might be too low as a threshold */
>-	/* FIXME: sometimes we get 0 in the middle of a scan, should we wait for
>-	 * a few consecutive zeroes? */
>-	/* FIXME: we should have an upper limit on the number of strips */
>-
>-	/* If sum is 0, finger has been removed */
>+	/* Sum is 0, maybe finger was removed? Wait for 3 empty frames
>+	 * to ensure
>+	 */
> 	if (sum == 0) {
>-		/* assemble image and submit it to library */
>-		assemble_and_submit_image(dev);
>-		fpi_imgdev_report_finger_status(dev, FALSE);
>-		/* marking machine complete will re-trigger finger detection loop */
>-		fpi_ssm_mark_completed(ssm);
>+		aesdev->no_finger_cnt++;
>+		if (aesdev->no_finger_cnt == 3) {
>+			/* assemble image and submit it to library */
>+			assemble_and_submit_image(dev);
>+			fpi_imgdev_report_finger_status(dev, FALSE);
>+			/* marking machine complete will re-trigger finger detection loop */
>+			fpi_ssm_mark_completed(ssm);
>+		} else {
>+			fpi_ssm_jump_to_state(ssm, CAPTURE_REQUEST_STRIP);
>+		}
> 	} else {
> 		/* obtain next strip */
>+		/* FIXME: would preallocating strip buffers be a decent optimization? */
>+		stripdata = g_malloc(192 * 8);
>+		memcpy(stripdata, data + 1, 192*8);
>+		aesdev->no_finger_cnt = 0;
>+		aesdev->strips = g_slist_prepend(aesdev->strips, stripdata);
>+		aesdev->strips_len++;
>+
> 		fpi_ssm_jump_to_state(ssm, CAPTURE_REQUEST_STRIP);
> 	}
> 
>@@ -677,6 +681,7 @@ static void start_capture(struct fp_img_dev *dev)
> 		return;
> 	}
> 
>+	aesdev->no_finger_cnt = 0;
> 	ssm = fpi_ssm_new(dev->dev, capture_run_state, CAPTURE_NUM_STATES);
> 	fp_dbg("");
> 	ssm->priv = dev;
>-- 
>1.8.0
>

Actions: View | Splinter Review

Attachments on bug 56715: 69484 | 69485 | 69487

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.