hi pedro not sure... if you can capture a UsbSnoop log under windows and send it to me, however, i can have a quick look and see if the protocol is similar to the 138a:0001 protocol or not.
thanks ray On 10-07-01 03:49 AM, Pedro Ferreira wrote: > Hello again, > > The code assumes the device to be "138a:0001", but in my case it's > "138a:0007". I tried just changing the device id In the code, but it > just spits out a ton of protocol errors when I run it. > Does anybody know which device is this? > > Regards, > > Pedro > > On Tue, Jun 29, 2010 at 6:28 PM, Pedro Ferreira<[email protected]> wrote: > >> OK, I'll give it a try :) >> >> Thank you very much! >> >> Pedro >> >> On Tue, Jun 29, 2010 at 5:45 PM, Ray Lehtiniemi<[email protected]> wrote: >> >>> On 10-06-29 09:40 AM, Kunal Gangakhedkar wrote: >>> >>>> For starters, you can take a look at Ray's repo at: >>>> http://github.com/rayl/vfs101driver >>>> >>>> This is not an fprint driver, but a set of tools he's working on to >>>> simulate >>>> the protocol for the device. >>>> >>>> >>> just as a quick status update, the current code is able to configure >>> the device, enter a polling loop, and retrieve a single fingerprint into >>> a PNM file. for some reason the hardware seems to lock up at this >>> point. once this lockup problem is solved, i think it will be fairly >>> easy (for someone who understands the fprint state machine model) to >>> take this code and produce an actual fprint driver. >>> >>> so if you're willing and able, please try out the code, try to reproduce >>> the lockup, and see if you can figure out why it's happening :-) >>> >>> thanks >>> ray >>> >>> _______________________________________________ >>> fprint mailing list >>> [email protected] >>> http://lists.reactivated.net/mailman/listinfo/fprint >>> >>> >> _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
