Re: [fprint] [Fwd: Re: Upek Eikon II]
The upeksonly device seems to work *very* differently to the other two devices. The upeksonly driver has not the same structure as the upekts driver as well, and we should need to take a very deep look into its code to do the matching. I mean, that would be a lot of hard work. I like your idea, because that would fix the ids issue. But that's too much work and I'm not very confident that merging two drivers that seem so different would be the best solution. Comments about this would be very appreciated. I actually don't want to do this if we are able to find a smarter solution. -- Jorge Suárez de Lis y...@jorgesuarezdelis.name ___ fprint mailing list fprint@reactivated.net http://lists.reactivated.net/mailman/listinfo/fprint
Re: [fprint] [Fwd: Re: Upek Eikon II]
I don't think there's any way to do this on fprint. I still have to take a better look at the code, but it seems that the drivers just register themselves as I am ready to support the device with these IDs, so I'll do the job. I have an upeksonly device. It must be possible to differentiate the devices at runtime and merge the drivers so that while using one driver, different code paths are followed. Ive posted several patches to this list that for while made my upeksonly work quite decently but after some kernel update something in the data transfer broke. Swiping fast enough to get a print before a gap was detected became a chore. I if you want to merge the only driver to upekts, I can provide testing and diagnostics. -- --Alexia ___ fprint mailing list fprint@reactivated.net http://lists.reactivated.net/mailman/listinfo/fprint
Re: [fprint] [Fwd: Re: Upek Eikon II]
On 04/26/2010 02:33 PM, Jorge Suárez de Lis wrote: That's weird. I've never received 2e. You should receive 0d, then 0e, then 26 and then 27. But not 2e. Is your device the same as mine? On the barcode it says TCRD4CA1H6A3. Try this, after line 1000 (case 0x27:) add this: I can't check the barcode on the chip (built into my Lenovo T410 laptop) but the lsusb output is: Bus 001 Device 003: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor I added the case 'case 0x2e' part and it actually will enroll my fingerprint! I just checked the enrollment with fprintd-verify and it verified with no problems. So the current downside is that the 0483:2016 device no longer works with this code so it'd really be best to get the upekts.c driver to work properly with both devices. Are there multiple devices matching 147e:2016 that would need to be addressed somehow so that upeksonly could still service the 'old' device and upekts could service the 'new' version? Any idea if there is any way to differentiate? ___ fprint mailing list fprint@reactivated.net http://lists.reactivated.net/mailman/listinfo/fprint
Re: [fprint] [Fwd: Re: Upek Eikon II]
Full lsusb output: Bus 001 Device 003: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.01 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x147e Upek idProduct 0x2016 Biometric Touchchip/Touchstrip Fingerprint Sensor bcdDevice0.02 iManufacturer 1 UPEK iProduct2 Biometric Coprocessor iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 20 Device Status: 0x (Bus Powered) Debug output from enrollment: fp:debug [fp_init] fp:debug [register_driver] registered driver upekts fp:debug [register_driver] registered driver aes4000 fp:debug [register_driver] registered driver aes2501 fp:debug [register_driver] registered driver uru4000 fp:debug [register_driver] registered driver vcom5s fp:debug [register_driver] registered driver upeksonly fp:debug [register_driver] registered driver aes1610 Launching FprintObject fp:debug [find_supporting_driver] driver upekts supports USB device 147e:2016 ** Message: D-Bus service launched with name: net.reactivated.Fprint ** Message: entering main loop ** Message: user 'dhollis' claiming the device: 0 async:debug [fp_async_dev_open] ** Message: now monitoring fd 8 async:debug [fpi_drvcb_open_complete] status 0 ** Message: device 0 claim status 0 ** Message: start enrollment device 0 finger 7 async:debug [fp_async_enroll_start] starting enrollment drv:debug [__ssm_call_handler] 0x2516bd0 entering state 0 drv:debug [__ssm_call_handler] 0x2527a50 entering state 0 drv:debug [__ssm_call_handler] 0x2527a50 entering state 1 upekts:debug [__handle_incoming_msg] A=03 B=00 len=5 upekts:debug [__handle_incoming_msg] cmd 3 from device to driver drv:debug [__ssm_call_handler] 0x2527a50 entering state 2 upekts:debug [alloc_send_cmdresponse_transfer] seq=04 len=8 upekts:debug [initsm_send_msg_cb] state 2 completed drv:debug [__ssm_call_handler] 0x2527a50 entering state 3 upekts:debug [__handle_incoming_msg] A=05 B=00 len=1 upekts:debug [__handle_incoming_msg] cmd 5 from device to driver drv:debug [__ssm_call_handler] 0x2527a50 entering state 4 upekts:debug [alloc_send_cmd28_transfer] seq=00 subcmd=06 with 1 bytes of data upekts:debug [initsm_send_msg_cb] state 4 completed drv:debug [__ssm_call_handler] 0x2527a50 entering state 5 upekts:debug [__handle_incoming_msg] A=00 B=00 len=55 upekts:debug [__handle_incoming_msg] device responds to subcmd 6 with 49 bytes upekts:debug [initsm_read_msg_response_cb] state 5 completed drv:debug [__ssm_call_handler] 0x2527a50 entering state 6 upekts:debug [alloc_send_cmd28_transfer] seq=10 subcmd=51 with 5 bytes of data upekts:debug [initsm_send_msg_cb] state 6 completed drv:debug [__ssm_call_handler] 0x2527a50 entering state 7 upekts:debug [__handle_incoming_msg] A=00 B=10 len=27 upekts:debug [__handle_incoming_msg] device responds to subcmd 51 with 21 bytes upekts:debug [initsm_read_msg_response_cb] state 7 completed drv:debug [__ssm_call_handler] 0x2527a50 entering state 8 upekts:debug [alloc_send_cmd28_transfer] seq=20
