Bug 474994
| Summary: | no support for Upek Touchstrip (147e:1000) | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Khashayar Naderehvandi <khashayar.lists> | |
| Component: | libfprint | Assignee: | Bastien Nocera <bnocera> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | low | |||
| Version: | 12 | CC: | awilliam, bnocera, brain.storm, brunojcm, cervajs, eric.donkersloot, james, jturner, karuppuswamy, luizluca, pingou, thesource, tomek | |
| Target Milestone: | --- | Keywords: | Reopened, Triaged | |
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | libfprint-0.3.0-1.fc14 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 538438 (view as bug list) | Environment: | ||
| Last Closed: | 2010-12-05 00:38:29 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 538438 | |||
In which piece of hardware did you find this device? Oh, sorry about that. It's in an Asus N20A notebook. Please let me know if I can help out in any way possible. Some more info [1]: It's a touchstrip fingerprint reader UPEK TCS4 family Device build in: Vaio BZ Series Vaio SR Series Vaio Z Series Compal JLH 90 Thinkpad SL 300 & 500 Asus N10-XXXX And probably many other laptops. UPEK has released a proprietary blob for linux that works fine for this device. The fingerprintGUI [2] application, bundles and optionally uses said blob to enable the scanner under linux. With the blob enabled, I have used usbmon to do some sniffing, following the instructions available on the libfprint wiki. If Redhat engineers have any plans to start reverse engineering this device, please let me know and I'll attach the logs. [1] copied from https://bugs.launchpad.net/ubuntu/+bug/301567/comments/1 [2] http://www.n-view.net/Appliance/fingerprint/ This seems to be 2 different fingerprint readers you're talking about. The one you mentioned in comment 0 would use the "upekts" driver, the one in comment 3 would be using "upektc". In the libfprint sources, you'll need to try and see which driver would support your device by adding the line: { .vendor = 0x147e, .product = 0x1000 }, in the "id_table" structure. You'll need to try either libfprint/drivers/upekts.c, or libfprint/drivers/upektc.c, and see which one works. Let me know if any of those works. Unfortunately, I don't have much time nowadays to tinker. But, if I understand you correctly, you mean that the source code for the 147e:1000 device might already be there, the device ID only needs to be added for everything to work? If that's the case, I'd send an email to the libfprint list explaining that, as I've seen a couple of other people lurking around there hoping for supported 147e:1000 devices. Also, I'm not sure how the fingerprint scanner in comment 0 and comment 3 are different? I thought they would be the same, since they share the same vendor and product ID. In either case, my device is the one in comment 0. Hello Bastien, I tested with upekts, upektc and upeksonly (adding vendor/product id). Maybe the last one is a better guess as it has the same vendor_id. None of them worked. I just managed to use the fingerprint reader with BSAPI.so from vendor but not with fprint(git). When I tested with fprint upeksonly, it set some invalid state in my fingerprint reader that BSAPI just works again after a cold boot. Simple reboot does not solve. My tests (all with root): 1) Open Fingerprint-GUI (with BSPAI): worked 2) Use upekts: failed on example/enroll This program will enroll your right index finger, unconditionally overwriting any right-index print that was enrolled previously. If you want to continue, press enter, otherwise hit Ctrl+C 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 [find_supporting_driver] driver upekts supports USB device 147e:1000 Found device claimed by UPEK TouchStrip driver sync:debug [fp_dev_open] async:debug [fp_async_dev_open] async:debug [fpi_drvcb_open_complete] status 0 sync:debug [sync_open_cb] status 0 Opened device. It's now time to enroll your finger. You will need to successfully scan your finger 3 times to complete the process. Scan your finger now. sync:debug [fp_enroll_finger_img] async:debug [fp_async_enroll_start] starting enrollment drv:debug [__ssm_call_handler] 0x604540 entering state 0 drv:debug [__ssm_call_handler] 0x604580 entering state 0 sync:debug [fp_enroll_finger_img] upekts will handle enroll stage 0/2 drv:debug [__ssm_call_handler] 0x604580 entering state 1 upekts:error [read_msg_cb] async msg read failed, code 2 drv:debug [fpi_ssm_mark_aborted] error -1 from state 1 drv:debug [fpi_ssm_mark_completed] 0x604580 completed with status -1 drv:debug [fpi_ssm_mark_aborted] error -1 from state 0 drv:debug [fpi_ssm_mark_completed] 0x604540 completed with status -1 async:debug [fpi_drvcb_enroll_started] status -1 sync:debug [sync_enroll_cb] result -1 sync:error [fp_enroll_finger_img] unrecognised return code -1 sync:debug [fp_enroll_finger_img] ending enrollment async:debug [fp_async_enroll_stop] drv:debug [__ssm_call_handler] 0x604540 entering state 0 upekts:debug [alloc_send_cmdresponse_transfer] seq=07 len=1 drv:debug [__ssm_call_handler] 0x604540 entering state 1 upekts:error [read_msg_cb] async msg read failed, code 2 drv:debug [fpi_ssm_mark_aborted] error -1 from state 1 drv:debug [fpi_ssm_mark_completed] 0x604540 completed with status -1 async:debug [fpi_drvcb_enroll_stopped] sync:debug [enroll_stop_cb] Enroll failed with error -22 sync:debug [fp_dev_close] async:debug [fpi_drvcb_close_complete] sync:debug [sync_close_cb] fp:debug [fp_exit] 3) Open Fingerprint-GUI (with BSPAI): worked 4) Use upektc: not built (why?) There is just this entry in Makefile UPEKTC_SRC = drivers/upektc.c And no upektc related lib in .libs 5) use upeksonly LD_LIBRARY_PATH=libfprint/.libs/ examples/enroll This program will enroll your right index finger, unconditionally overwriting any right-index print that was enrolled previously. If you want to continue, press enter, otherwise hit Ctrl+C 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 [find_supporting_driver] driver upeksonly supports USB device 147e:1000 Found device claimed by UPEK TouchStrip Sensor-Only driver sync:debug [fp_dev_open] async:debug [fp_async_dev_open] async:debug [fpi_drvcb_open_complete] status 0 sync:debug [sync_open_cb] status 0 Opened device. It's now time to enroll your finger. You will need to successfully scan your finger 1 times to complete the process. Scan your finger now. sync:debug [fp_enroll_finger_img] async:debug [fp_async_enroll_start] starting enrollment fp:debug [generic_acquire_start] action 1 drv:debug [__ssm_call_handler] 0x605940 entering state 0 upeksonly:debug [write_regs_iterate] set 49=00 sync:debug [fp_enroll_finger_img] upeksonly will handle enroll stage 0/0 upeksonly:debug [write_regs_iterate] set 3e=83 upeksonly:debug [write_regs_iterate] set 3e=4f upeksonly:debug [write_regs_iterate] set 3e=0f upeksonly:debug [write_regs_iterate] set 3e=bf upeksonly:debug [write_regs_iterate] set 3e=45 upeksonly:debug [write_regs_iterate] set 3e=35 upeksonly:debug [write_regs_iterate] set 3e=1c upeksonly:debug [write_regs_iterate] set 3e=ae upeksonly:debug [write_regs_iterate] set 44=01 upeksonly:debug [write_regs_iterate] set 43=06 upeksonly:debug [write_regs_iterate] set 43=05 upeksonly:debug [write_regs_iterate] set 43=04 upeksonly:debug [write_regs_iterate] set 44=00 upeksonly:debug [write_regs_iterate] set 0b=00 drv:debug [__ssm_call_handler] 0x605940 entering state 1 upeksonly:debug [sm_read_reg] read reg 09 upeksonly:debug [sm_read_reg_cb] read reg result = 20 drv:debug [__ssm_call_handler] 0x605940 entering state 2 upeksonly:debug [sm_write_reg] set 09=20 drv:debug [__ssm_call_handler] 0x605940 entering state 3 upeksonly:debug [sm_read_reg] read reg 13 upeksonly:debug [sm_read_reg_cb] read reg result = 45 drv:debug [__ssm_call_handler] 0x605940 entering state 4 upeksonly:debug [sm_write_reg] set 13=45 drv:debug [__ssm_call_handler] 0x605940 entering state 5 upeksonly:debug [sm_write_reg] set 04=00 drv:debug [__ssm_call_handler] 0x605940 entering state 6 upeksonly:debug [sm_write_reg] set 05=00 drv:debug [fpi_ssm_mark_completed] 0x605940 completed with status 0 fp:debug [fpi_imgdev_activate_complete] status 0 async:debug [fpi_drvcb_enroll_started] status 0 drv:debug [__ssm_call_handler] 0x61e1b0 entering state 0 drv:debug [__ssm_call_handler] 0x61e0f0 entering state 0 upeksonly:debug [write_regs_iterate] set 0a=00 upeksonly:debug [write_regs_iterate] set 0a=00 upeksonly:debug [write_regs_iterate] set 09=20 upeksonly:debug [write_regs_iterate] set 03=3b upeksonly:debug [write_regs_iterate] set 00=67 upeksonly:debug [write_regs_iterate] set 00=67 drv:debug [__ssm_call_handler] 0x61e0f0 entering state 1 upeksonly:debug [sm_read_reg] read reg 01 upeksonly:debug [sm_read_reg_cb] read reg result = ee drv:debug [__ssm_call_handler] 0x61e0f0 entering state 2 upeksonly:debug [sm_write_reg] set 01=46 drv:debug [__ssm_call_handler] 0x61e0f0 entering state 3 upeksonly:debug [write_regs_iterate] set 01=c6 upeksonly:debug [write_regs_iterate] set 0c=13 upeksonly:debug [write_regs_iterate] set 0d=0d upeksonly:debug [write_regs_iterate] set 0e=0e upeksonly:debug [write_regs_iterate] set 0f=0d upeksonly:debug [write_regs_iterate] set 0b=00 drv:debug [__ssm_call_handler] 0x61e0f0 entering state 4 upeksonly:debug [sm_read_reg] read reg 13 upeksonly:debug [sm_read_reg_cb] read reg result = 45 drv:debug [__ssm_call_handler] 0x61e0f0 entering state 5 upeksonly:debug [sm_write_reg] set 13=45 drv:debug [__ssm_call_handler] 0x61e0f0 entering state 6 upeksonly:debug [write_regs_iterate] set 13=45 upeksonly:debug [write_regs_iterate] set 30=e0 upeksonly:debug [write_regs_iterate] set 12=01 upeksonly:debug [write_regs_iterate] set 20=01 upeksonly:debug [write_regs_iterate] set 09=20 upeksonly:debug [write_regs_iterate] set 0a=00 upeksonly:debug [write_regs_iterate] set 30=e0 upeksonly:debug [write_regs_iterate] set 20=01 drv:debug [__ssm_call_handler] 0x61e0f0 entering state 7 upeksonly:debug [sm_read_reg] read reg 07 upeksonly:debug [sm_read_reg_cb] read reg result = 10 drv:debug [__ssm_call_handler] 0x61e0f0 entering state 8 upeksonly:debug [sm_write_reg] set 07=10 drv:debug [__ssm_call_handler] 0x61e0f0 entering state 9 upeksonly:debug [write_regs_iterate] set 08=00 upeksonly:debug [write_regs_iterate] set 10=00 upeksonly:debug [write_regs_iterate] set 12=01 upeksonly:debug [write_regs_iterate] set 11=bf upeksonly:debug [write_regs_iterate] set 12=01 upeksonly:debug [write_regs_iterate] set 07=10 upeksonly:debug [write_regs_iterate] set 07=10 upeksonly:debug [write_regs_iterate] set 04=00 upeksonly:debug [write_regs_iterate] set 05=00 upeksonly:debug [write_regs_iterate] set 0b=00 upeksonly:debug [write_regs_iterate] set 15=20 upeksonly:debug [write_regs_iterate] set 30=e1 upeksonly:debug [write_regs_iterate] set 15=24 upeksonly:debug [write_regs_iterate] set 15=04 upeksonly:debug [write_regs_iterate] set 15=84 drv:debug [fpi_ssm_mark_completed] 0x61e0f0 completed with status 0 drv:debug [__ssm_call_handler] 0x61e1b0 entering state 1 upeksonly:debug [sm_await_intr] upeksonly:debug [sm_await_intr_cb] interrupt received: 01 00 00 00 fp:debug [fpi_imgdev_report_finger_status] finger on sensor drv:debug [__ssm_call_handler] 0x61e1b0 entering state 2 drv:debug [__ssm_call_handler] 0x61e130 entering state 0 drv:debug [__ssm_call_handler] 0x61e130 entering state 1 upeksonly:debug [sm_write_reg] set 15=20 drv:debug [__ssm_call_handler] 0x61e130 entering state 2 upeksonly:debug [sm_write_reg] set 30=e0 drv:debug [__ssm_call_handler] 0x61e130 entering state 3 drv:debug [__ssm_call_handler] 0x61e130 entering state 4 upeksonly:debug [write_regs_iterate] set 09=28 upeksonly:debug [write_regs_iterate] set 13=55 upeksonly:debug [write_regs_iterate] set 0b=80 upeksonly:debug [write_regs_iterate] set 04=00 upeksonly:debug [write_regs_iterate] set 05=00 drv:debug [fpi_ssm_mark_completed] 0x61e130 completed with status 0 drv:debug [__ssm_call_handler] 0x61e1b0 entering state 3 upeksonly:debug [handle_packet] detected wraparound upeksonly:debug [handle_packet] detected wraparound ^C to kill infinity loop 6) Open Fingerprint-GUI (with BSPAI): does not work anymore 7) poweroff/poweron 8) Open Fingerprint-GUI (with BSPAI): works again I captured Fingerprint-GUI working with wireshark. If it is useful, I can attach. How can I help? Where do I start? someone's reporting this same problem in F11 on the forum: http://forums.fedoraforum.org/showthread.php?t=231070 also found an Ubuntu thread: https://bugs.launchpad.net/ubuntu/+bug/301567 which confirms it works if selected as an 'unknown' device in this fingerprint-gui thing. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers I have the same fprint device on a Dell Vostro 1520 notebook. It's my first notebook with fprint, so I don't have experience with fprint drivers, etc. How can I help to have support for this device? fprint_demo tells me that 'no device is found'. lsusb tells me 'Bus 008 Device 003: ID 147e:1000 Upek ' This particular fingerprint reader is also present on a Sony Vaio VGN-BZ12XN. I've got one in a Sony Vaio VGN-AW230J which isn't working either: fprintd-0.1-15.git04fd09cfa.el6.x86_64 fprintd-pam-0.1-15.git04fd09cfa.el6.x86_64 libfprint-0.1.0-10.pre2.el6.x86_64 Same here. ASUS N51VF i have one in ASmobile Z97V This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping There's still no support for this fingerprint device, changing version to Fedora 12. The upeksonly module in libfprint package supports this. But the upeksonly.c does not list this particular VID/PID. I tried adding 1470:1000 to the supported device table of upeksonly, it works fine. No more "Unknown device". Here is how I got it? May be useful for some one. http://karuppuswamy.com/wordpress/2010/07/22/how-to-get-fingerprint-reader-working-in-fedora-linux-upek-147e1000-in-this-case/ Hello, upeksonly still does not work for me. If someone follows the previous howto, step1 is useless as step2 installs fingerprintGUI and UPEK proprietary library (libbsapi.so): A specific proprietary (non opensource) driver “libbsapi.so” from UPEK Inc. (http://www.upek.com/) is available for this device. To take full advantage of this device, the installation of this driver is required. Do you want the install script to copy this driver to “/usr/lib”? (Yes/no): Yes Driver “libbsapi.so” was copied to “/usr/lib”. At this point, I can see that libbsapi was installed. However, there is no way to check if it is in use by looking at the pictures. If you still have this working, open FingerprintGUI, select "Show Drivername" and change the upper combobox from libbsapi (default one) to "UPEK Touchstrip Sensor-Only" For me, fprint keeps waiting forever on "Scan step" and device becomes unresponsible until next cold reboot. Should the support using a proprietary driver be considered enough? I guess all tools that depends on fprint must change to also support bsapi. (In reply to comment #15) > The upeksonly module in libfprint package supports this. But the upeksonly.c > does not list this particular VID/PID. I tried adding 1470:1000 to the > supported device table of upeksonly, it works fine. No more "Unknown device". > Here is how I got it? May be useful for some one. > > http://karuppuswamy.com/wordpress/2010/07/22/how-to-get-fingerprint-reader-working-in-fedora-linux-upek-147e1000-in-this-case/ Given that your post mentions: > A specific proprietary (non opensource) driver “libbsapi.so” > from UPEK Inc. (http://www.upek.com/) is available for this device. > To take full advantage of this device, the installation of this driver > is required. Do you want the install script to copy this driver to > “/usr/lib”? (Yes/no): Yes > Driver “libbsapi.so” was copied to “/usr/lib”. I'll conclude that the upeksonly driver does not work, unlike what you concluded. (In reply to comment #9) > This particular fingerprint reader is also present on a Sony Vaio VGN-BZ12XN. libfprint will not work with any of the Vaio fingerprint readers, as they're lobotomised versions of the device, and require extra trickery to be able to talk to them (which nobody reversed-engineered). I'll close this bug as there's no drivers for this device available. Any other discussions should happen on the libfprint lists. Reopening, the support is now upstream. I'll update the package when I do a new upstream release. libfprint-0.3.0-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/libfprint-0.3.0-1.fc14 libfprint-0.3.0-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/libfprint-0.3.0-1.fc13 libfprint-0.3.0-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update libfprint'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/libfprint-0.3.0-1.fc14 I used fprintd-enroll and fprintd-verify to check the device. The device is opened and scan is successful, but I never could get verify-match result. And I got TONES of try-again. Either it's a bug or I don't understand how this thing works. After many tries fprintd-enroll/verify started to say that they can not claim device (error -4) though no other apps were running. (In reply to comment #22) > I used fprintd-enroll and fprintd-verify to check the device. The device is > opened and scan is successful, but I never could get verify-match result. And I > got TONES of try-again. Either it's a bug or I don't understand how this thing > works. After many tries fprintd-enroll/verify started to say that they can not > claim device (error -4) though no other apps were running. Either file an upstream bug (on freedesktop.org), or e-mail the fprint mailing-list. I don't have the hardware, so I cannot test. No Fedora 12 packages? I have a device, but only a Fedora 12. If you could provide a patch I can test. I contacted fprint developers about the issue and they say: 1. The new driver is buggy and a reason for frequent 'try again' in fprintd commands 2. The algorithm for image comparison is very simple and therefore it is quite hard to get a 'match' result. You have to swipe finder almost EXACTLY like first time which is very hard. In Windows the native software works better. For those reasons I'd rather use passwords for now. This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping libfprint-0.3.0-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. This comment was flagged a spam, view the edit history to see the original text if required. This comment was flagged a spam, view the edit history to see the original text if required. |
Description of problem: There is currently no support for the Upek Touchstrip 147e:1000. Relevant output of lsusb follows below. Version-Release number of selected component (if applicable): 0.0.5-6.fc10, but this bug applies, as far as I know, to all versions of libfprint. There simply is no support for this device yet. Additional info: Output of lsusb Bus 003 Device 004: ID 147e:1000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x147e idProduct 0x1000 bcdDevice 0.33 iManufacturer 1 TouchStrip iProduct 2 Fingerprint Sensor 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 bInterfaceNumber 0 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 bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 10 Device Status: 0x0000 (Bus Powered)