your error sounds like mine with UPEK TouchStrip device variant ID 0483:2016
I suspect this thing is firmware related, according to http://avilella.googlepages.com/vaiosz ("fingerprint sensor" section, directly from UPEK) "It is a problem of custom firmware of the fingerprint module that Sony required for their notebooks. This firmware needs a special key before calling any functions, thus Linux driver cannot access them... Only special version of PS QL (which has the key build-in) can work with the sensor. Sony does not want any other software to be able to communicate with the fingerprint sensor. According to our business agreement, we cannot enclose the Sony's key in our Linux BSP." I don't know which laptop you have, but seems like your manufacturer has a custom bios too. Daniel Drake suggested me to dump from windows via sniffusb and provide a log for further investigation, I will provide it in next days, I suggest you to make te same On Friday 14 December 2007 01:25:35 Ugo Riboni wrote: > > > I'd like to help with trying the binary drivers, at least trying > > > installing them and trying to get them to work. > > > But the link above leads me nowhere, and searching the upek drivers > > > area for Linux turns out only a BioAPI based SDK. > > > Is the binary driver inside that ? > > > > http://www.upek.com/solutions/pc_and_networking/sdks/linux/ > > I think that's all you need. You can probably find some howto's on the > > thinkpad wiki or something like that. > > I finally had some free time and gave this a shot. > Installed from source the linux-bioapi framework. Then downloaded and > installed the UPEK BSP binary module. > Then after fiddling a while to get it to build, i ran (as root) the > sample included with the BSP, which essentially tries to use the > bioapi framework to load the UPEK BSP, initialize it, then do some > enrollment. > But i never got to that point. The sample fails when initializing the > BSP module. > > Basically it goes like this: > - at some point BioAPI_ModuleLoad is called, asking it to load the > UPEK binary library > - bioapi find the library, and dynamically loads it. > - then finds the address of the SPI Load function in the library and > tries to call it. > - the function returns an error code of 0x149D which is described in > the BSP manual as: > BioAPIERR_TFMESS_PT_FUNCTION_FAILED : Function failed > > Not a very useful error message. > So i went in and tried to see if strace had anything useful to say. > It appears everything goes fine until the library tries to access the > actual USB device. > You can see from the log yourself, i have attached to this email, but > it looks like it does some searching through all the USB devices on > the system, until it settles down on this: > > open("/dev/bus/usb/003/002", O_RDWR) = 12 > ioctl(12, USBDEVFS_SETCONFIGURATION, 0xbfaa09a4) = 0 > ioctl(12, USBDEVFS_CLAIMINTERFACE, 0xbfaa09a4) = 0 > nanosleep({0, 10000000}, NULL) = 0 > ioctl(12, USBDEVFS_CONTROL, 0xbfaa096c) = 1 > gettimeofday({1197590255, 551261}, NULL) = 0 > ioctl(12, USBDEVFS_SUBMITURB, 0xbfaa00f4) = 0 > > after this, it enters in a very long loop doing the following: > > ioctl(12, USBDEVFS_REAPURBNDELAY, 0xbfaa0138) = -1 EAGAIN (Resource > temporarily unavailable) > select(13, NULL, [12], NULL, {0, 1000}) = 0 (Timeout) > gettimeofday({1197590255, 553691}, NULL) = 0 > > It looks to me like it sent a command to the device (possibly an > initialization command) and the device isn't responding at all. > After keeping retrying for like 10 seconds, it does bail out and > return the error message listed above. > > Notice that it doesn't seem to fail because of some authentication > scheme, like i've read elsewhere. > If it was that, it would be getting a response of some kind from the > device, unless the authentication itself is just "knowing the right > initial USB command to send", which would be a pretty silly auth > scheme... but you never know how silly people can get with this stuff. > > So it looks like either the BSP library isn't designed to work with > this specific model of reader, or something else is going wrong. But > being closed source stuff, there's only so much one can do. > > It may be possible to trace USB messages and compare the > initialization the BSP sends with the one that windows sends. But i > don't know how to do that, and i'm doubting it would lead to anything > useful since we can't alter the binary BSP library in any way to make > it send the correct data. > > > > Please let me know where i can get this binary driver from, if it does > > > exist at all, so i can try to help further. > > > > The first step is to figure out the image format. If you'd like to help, > > read the thread titled "image format challenges" I started the other day. > > I will try to play with the image when i have time, but not sure i can > get anywhere with that. > > Any other ideas based on information above ? > -- > Ugo _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
