On Mon, Dec 29, 2008 at 9:27 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 29 Dec 2008, Erik Ekman wrote: > >> I should explain what the tf-tool does. I ran it with option --acquire >> which means >> you swipe three times and it produces a file which is the recorded fingerprint. >> I dont know what interval is 2 ms, I sure didnt run it that way. > > I got a version of the thinkfinger code from Sourceforge. Evidently it > opens the device file, does some stuff, and closes the file. Then it > opens the file again in order to acquire a fingerprint. That's why the > pause is so short; the file gets opened twice during a single run of > the program. > >> The "reverted" log shows a full fingerprint acquire with three swipes, >> all in the same run of tf-tool. The shorter log shows an attempt to do it, >> but tf-tool stopped with an error before I could swipe anything. > > The error occurred during the attempt to claim interface 0 the second > time the file was opened. The EBUSY error code means the kernel > thought the interface was already claimed. > >> This time I have added pam_thinkfinger.so as sufficient for system >> login, and have recorded login attempts with and without the specific >> commit in the kernel. >> >> Stock 2.6.28 did not log me in, I had to write a password. dmesg shows: >> input: Virtual ThinkFinger Keyboard as /class/input/input8 >> usb 5-2: usbfs: process 5539 (login) did not claim interface 0 before use >> usb 5-2: usbfs: process 5539 (login) did not claim interface 0 before use >> usb 5-2: usbfs: process 5539 (login) did not claim interface 0 before use > ... > > Here you see another confusing aspect of the problem. The kernel > thinks the program used interface 0 before claiming it, and the program > thinks it tried to claim the interface but failed! > > And I still don't see what connection any of this has to that commit. > The commit has no effect on interface claims. > >> Bus 5, device 2 is my reader: >> Bus 005 Device 002: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader >> >> 2.6.28 minus the commit lets me in when I swipe, and dmesg only shows: >> input: Virtual ThinkFinger Keyboard as /class/input/input8 > > Now this is confusing too, because you've got the program running > automatically to verify logins and you've got it running directly from > the command line. > > I get the impression that there may be something funky going on > involving multiple threads or multiple processes all trying to access > the reader simultaneously. That's just a guess, though. Still, it's > easier to figure out what's happening when there's only one task > running and it is started from the command line -- not automatically. I think this is one of the problems from thinkfinger that the newer fprint tries to solve. I am CCing the authors of these utilities, please help us. > > Do you have the thinkfinger source code handy? Can you build it with > the USB_DEBUG option enabled? I will try that. /Erik -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
