Interrupt response

[hmaarrfk]

The device may in fact return that a finger is already present in the first interrupt response. I had assumed that it always returned 0 0 0 0 0 if the device was properly configured.

I guess we need to check that first response for availability of data.

[szbergeron]

How feasible would it be to just attempt a capture and check if any pixels are more than 50% "activated"?
Looking at the different interrupt responses there really doesn't seem to be any way to tell apart whether the sensor thinks it's being used or not. Capture does succeed when no finger is present, it just returns low level sensor noise.

[hmaarrfk]

The problem is that nothing at all is captured right? It seems that the configuration strings are different between my senesor and maybe a newer version.

[szbergeron]

When I modified the prototype slightly it seems that capture does indeed work. If you initialize the sensor and immediately start the capture it takes a blank image withh a little bit of sensor noise. If you initialize it and start the capture with a finger there it successfully captures the image, it just doesn't seem to give any indication whether a finger is there or not. If there's any data that would be helpful beyond the diff of dump.txt just let me know.

In terms of packet data, the exchange seems to proceed as follows during the interrupt sequence:
368 85.702703 host 1.3.3 USB 64 URB_INTERRUPT in
0000 c0 29 3d dc 31 9b ff ff 53 01 83 03 01 00 2d 3c
0010 0c fd cc 5a 00 00 00 00 1e 5b 0a 00 8d ff ff ff
0020 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 04 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00

369 85.703276 1.3.3 host USB 69 URB_INTERRUPT in
0000 c0 29 3d dc 31 9b ff ff 43 01 83 03 01 00 2d 00
0010 0c fd cc 5a 00 00 00 00 5b 5d 0a 00 00 00 00 00
0020 05 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00
0030 04 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
0040 02 01 00 50 f0

370 85.703921 host 1.3.3 USB 64 URB_INTERRUPT in
0000 c0 29 3d dc 31 9b ff ff 53 01 83 03 01 00 2d 3c
0010 0c fd cc 5a 00 00 00 00 e0 5f 0a 00 8d ff ff ff
0020 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 04 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00

371 85.735290 1.3.3 host USB 69 URB_INTERRUPT in
0000 c0 29 3d dc 31 9b ff ff 43 01 83 03 01 00 2d 00
0010 0c fd cc 5a 00 00 00 00 69 da 0a 00 00 00 00 00
0020 05 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00
0030 04 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
0040 03 00 00 00 00

Here's a dump from wireshark with two attempted captures. The first is with my palm on the sensor (biometric data, but not really private data) and the second with no finger on the sensor. I'm having some trouble telling any difference between a capture with something on the sensor and a capture without beyond actually looking into any given capture for contrast in data captured. Dump: https://drive.google.com/file/d/1q10t9_a25ekFOgdsxDFh2Cgi3TQFfQbP/view?usp=sharing

[hmaarrfk]

You can try to look at things like "the variance". That is what I did on my libfprint port to make it more quickly detect that a finger was off. It kinda worked.

[hmaarrfk]

But i'm more concerned as to how we can create a driver that spans accross these two devices.

I'm not too familiar with the USB packet organization. Wireshark actually interpreted most of the packet for me, giving me a very small (5 byte) message.

[szbergeron]

Wait a moment, this driver spans two devices? I thought it was for just the 0091.
I also probably have wireshark set up wrong because having it not properly interpret packets is just a pain at the moment. That 5 byte message is what's appearing at the very end of each of the snippets I shared, right?

[hmaarrfk]

It seems like there are 2 driver versions. One that I have, that seems to work with the script, and the other that you seem to have. For some reason it seems that yours uses a different set of commands.

The way windows works with mine is that it sends the initial commands, then waits for the interrupt to return fives zeros [0 0 0 0 0 ] to say that data is ready. Once it is ready, your finger, or something it thinks is a finger should be the next image.

[szbergeron]

Isn't USB a polling based system? I'm kind of wondering how an interrupt of that sort would work if so. On yours, if you try an image capture before it says it detects a finger what happens?

Just a question, you have an XPS 15 9560 right? I kind of wonder if they actually are different at the hardware level, or if there's some firmware difference, or something else.

[szbergeron]

It's super hacky to do it this way, but I think I got it working on my machine. There's almost definitely a better solution, but if I implement wait_finger_on the same way wait_finger_off is implemented it actually waits for a finger and then notices when the sensor isn't being engaged. It just polls the sensor probably more than it needs to. Also, the check for img.var() being less than 10 I think was causing some issues as that almost never ends up being the case, at least not with my sensor. It's almost always in the mid 100s or 200s, and gets to the 700s when a finger is present.

Hacky changes:
differ.txt

Full file for convenience:
validity91.txt

Uploaded as txt because github comments don't allow py files :eyeroll:

From a little testing, this approach appears to use around 3 watts(ish) when waiting for a finger.

[MarkOlree]

I just tested the altered validity91 from dreamwavedev, it also works with my device. I didn't have enough time to be able to hack a working version myself before.

From what I observed and read from my WireShark traces I believe dreamwavedev is somewhat right, "It just polls the sensor probably more than it needs to". I guess it keeps polling until the fingerprint is recognized.

How I believe the driver works and communicates with the sensor:

1. First off all the handshaking and init, works like implemented.
2. The device gives a ready interrupt: 00:00:00:00:00
3. Then it gives an interrupt, for me: 02:01:00:50:f0 'finger on', like implemented: 02 x x x x
4. Then the driver keeps polling on bulk: 78:00:00:00:00
5. Device has two answers: 01:00:00:00:00:00 'NO', 00:00:00:00:00:00 'YES'
6. On Yes the driver asks to send the fingerprint on bulk: 78:c0:12:00:00
7. Device sends package (4864 bytes, 4864 bytes and 3910 bytes) with fingerprint parts, like implemented
8. Device sends additional package, no pattern recognized maybe checksum? 6 and 7 are repeated 3 times for a full fingerprint.
9. The polling from 3 till 8 will be repeated. Till either the finger is removed or the driver sends a stop.
10. Driver sends a 04 to stop (fingerprint recognized) etc, like implemented.

I don't think I captured a finger off, without the driver stopping the reading. Maybe that is the 3 x x x x interrupt, you couldn't declare?

[szbergeron]

@MarkOlree I'm going to have to go back into windows to check, somehow I don't remember getting most of those interrupts.

Something I don't quite understand is the concept of having device initiated interrupts, instead of just tagged responses to host queries. Since USB is based on polling, doesn't the host need to query the device before it can report any of those conditions?

Which driver are you referencing for 1-10? It looks like it's probably the proprietary one on Windows, but I'd just like to be sure to make sure I'm not missing critical info in the captures I'm looking at on my end.

[MarkOlree]

@dreamwavedev I'm referring to the proprietary driver on Windows on a Dell XPS 15 9650, the observations are made based on monitoring the USB traffic with WireShark, maybe using Host had been a better choice.

[hmaarrfk]

@dreamwavedev you are right, USB is a polling system. I guess by interrupt USB means that the host CPU should wait for a message instead of polling. I set the timeout to infinite or something.

@dreamwavedev, it seems that your solution is the "correct" one. I kinda assume that the sensor was more robust, but either your sensor got dirty, and just measures a high capacitance, or maybe the humidity in your region makes the capcitance go up. Either way, I think we should check the variance for wait finger on.

@MarkOlree , I never noticed a finger off command. Basicaly, I noticed taht the Windows driver would poll for data as you explained until the stop command was sent. I assume this also brings the sensor in lower power mode since a few commands are necessary to re-initiate image capture.

[hmaarrfk]

Hey guys, you can try the latest version.

I added @dreamwavedev's suggestion that even the image_capture function wait for the variance to be above a threshold.

600 was very aggressive. It required perfect positioning of the user's finger basically on the whole sensor.

I changed it to 300.

@dreamwavedev thanks for digging into it. I don't know why your sensor is so noisy. Is it particularly oily? where do you live. I live in California, pretty dry air here.

[szbergeron]

@hmaarrfk Awesome to hear. I ended up guesstimating a value that seemed to work, it wan't really tuned for accuracy. It may be somewhat more humid here, mid-spring in NH, but I kept the sensor clean so it may just be manufacturing differences. 300 is probably safe, I think I tried 1000 as an initial value because 10 was always returning true and then just stepped down from there.

I'll pull the latest changes and try them on my end and let you know if everything works as expected.

@MarkOlree just tried again under windows and I have no clue where the interrupts you were seeing could be, I'm seeing pretty much just two or three so far. Could there be a bios revision that changes stuff?

[MarkOlree]

@dreamwavedev only those interrupts that are used and described in wait_finger_on, I described in 2 and 3.
I reffered in my last wild-guess to the code comments in the python code at wait_finger_on.