Re: 10 seconds lag when connecting UPS device (usb_submit_urb(ctrl) failed: -1)
Le Sat, 11 Aug 2012 14:01:21 -0400 (EDT), Alan Stern a écrit : Hi, > Try using usbmon to see what happens when the UPS is plugged in > (instructions are in Documentation/usb/usbmon.txt). Thanks for your answer. Please see the attached logs. Hope this will help. Cheers Laurent Bigonville 8801b5ac3cc0 283152949 S Ci:7:001:0 s a3 00 0001 0004 4 < 8801b5ac3cc0 283152960 C Ci:7:001:0 0 4 = 0001 8801b5ac3cc0 283152962 S Ci:7:001:0 s a3 00 0002 0004 4 < 8801b5ac3cc0 283152966 C Ci:7:001:0 0 4 = 01030100 8801b5ac3cc0 283152967 S Co:7:001:0 s 23 01 0010 0002 0 8801b5ac3cc0 283152969 C Co:7:001:0 0 0 8801b4019500 283256915 S Ii:7:001:1 -115:128 2 < 8801b6efe140 283256982 S Ci:7:001:0 s a3 00 0002 0004 4 < 8801b6efe140 283256988 C Ci:7:001:0 0 4 = 0103 8801b6efe140 283256995 S Co:7:001:0 s 23 03 0004 0002 0 8801b6efe140 283256998 C Co:7:001:0 0 0 8801b6efe140 283312971 S Ci:7:001:0 s a3 00 0002 0004 4 < 8801b6efe140 283312993 C Ci:7:001:0 0 4 = 0303 8801b6efe140 283369003 S Co:7:001:0 s 23 01 0014 0002 0 8801b6efe140 283369010 C Co:7:001:0 0 0 8801b6efe140 283369020 S Ci:7:000:0 s 80 06 0100 0040 64 < 8801b6efe140 283471012 C Ci:7:000:0 0 18 = 12011001 0008 6304 00010102 0301 8801b6efe140 283471076 S Co:7:001:0 s 23 03 0004 0002 0 8801b6efe140 283471083 C Co:7:001:0 0 0 8801b6efe140 283525057 S Ci:7:001:0 s a3 00 0002 0004 4 < 8801b6efe140 283525079 C Ci:7:001:0 0 4 = 0303 8801b6efe140 283580975 S Co:7:001:0 s 23 01 0014 0002 0 8801b6efe140 283580978 C Co:7:001:0 0 0 8801b6efe140 283580981 S Co:7:000:0 s 00 05 0009 0 8801b6efe140 283584013 C Co:7:000:0 0 0 8801b5ac3cc0 283600953 S Ci:7:009:0 s 80 06 0100 0012 18 < 8801b5ac3cc0 283701010 C Ci:7:009:0 0 18 = 12011001 0008 6304 00010102 0301 8801b5ac3cc0 283701078 S Ci:7:009:0 s 80 06 0200 0009 9 < 8801b5ac3cc0 283770983 C Ci:7:009:0 0 9 = 09022200 010100a0 0a 8801b5ac3cc0 283771044 S Ci:7:009:0 s 80 06 0200 0022 34 < 8801b5ac3cc0 283925983 C Ci:7:009:0 0 34 = 09022200 010100a0 0a090400 00010300 0921 10012101 22720307 05810308 8801b5ac3cc0 283926049 S Ci:7:009:0 s 80 06 0300 00ff 255 < 8801b5ac3cc0 283976985 C Ci:7:009:0 0 4 = 04030904 8801b5ac3cc0 283977047 S Ci:7:009:0 s 80 06 0302 0409 00ff 255 < 8801b5ac3cc0 284093980 C Ci:7:009:0 0 24 = 18034500 6c006c00 69007000 73006500 20004d00 41005800 8801b5ac3cc0 284094044 S Ci:7:009:0 s 80 06 0301 0409 00ff 255 < 8801b5ac3cc0 284171986 C Ci:7:009:0 0 12 = 0c034500 41005400 4f004e00 8801b5ac3cc0 284172048 S Ci:7:009:0 s 80 06 0303 0409 00ff 255 < 8801b5ac3cc0 284278010 C Ci:7:009:0 0 20 = 14034100 44004600 4c003300 39003000 36005400 8801b5ac3b40 284278309 S Co:7:009:0 s 00 09 0001 0 8801b5ac3b40 284280994 C Co:7:009:0 0 0 8801b6efe740 284281137 S Ci:7:009:0 s 80 06 0303 0409 00ff 255 < 8801b6efe740 284387014 C Ci:7:009:0 0 20 = 14034100 44004600 4c003300 39003000 36005400 8801b6efe980 284387115 S Co:7:009:0 s 21 0a 0 8801b6efe980 284390013 C Co:7:009:0 0 0 8801b6efe980 284390077 S Ci:7:009:0 s 81 06 2200 0372 882 < 8801b6efe980 287447011 C Ci:7:009:0 0 882 = 05840904 a1010910 a1000912 a100095a 85207508 95011500 26ff0065 005500b1 880106263cc0 287447854 S Ci:7:009:0 s a1 01 0119 0003 8 < 880106263cc0 287495013 C Ci:7:009:0 0 3 = 19 880106263cc0 287495018 S Ci:7:009:0 s a1 01 0103 0003 8 < 880106263cc0 287542010 C Ci:7:009:0 0 3 = 03 880106263cc0 287542015 S Ci:7:009:0 s a1 01 011f 0002 8 < 880106263cc0 287587012 C Ci:7:009:0 0 2 = 1f02 880106263cc0 287587017 S Ci:7:009:0 s a1 01 0101 0006 8 < 880106263cc0 287640999 C Ci:7:009:0 0 6 = 01010001 0001 880106263cc0 287641003 S Ci:7:009:0 s a1 01 010f 0002 8 < 880106263cc0 287686980 C Ci:7:009:0 0 2 = 0f00 880106263cc0 287686984 S Ci:7:009:0 s a1 01 0102 0006 8 < 880106263cc0 287740990 C Ci:7:009:0 0 6 = 0200 880106263cc0 287740995 S Ci:7:009:0 s a1 01 0106 0006 8 < 880106263cc0 287796012 C Ci:7:009:0 0 6 = 0664c40c 880106263cc0 287796017 S Ci:7:009:0 s a1 01 0320 0002 8 < 880106263cc0 287840992 C Ci:7:009:0 0 2 = 2002 880106263cc0 287840996 S Ci:7:009:0 s a1 01 03ff 0018 24 < 880106263cc0 287892988 C Ci:7:009:0 0 4 = ff01 880106263cc0 287892992 S Ci:7:009:0 s a1 01 03fe 000b 16 < 880106263cc0 297447011 C Ci:7:009:0 -2 0 880106263cc0 297447017 S Ci:7:009:0 s a1 01 030d 0004 8 < 880106263cc0 297447019 E Ci:7:009:0 -1 0 880106263a80 297461544 S Ii:7:009:1 -115:16 6 <
Re: 10 seconds lag when connecting UPS device (usb_submit_urb(ctrl) failed: -1)
Le Sat, 11 Aug 2012 15:11:28 -0400 (EDT), Alan Stern a écrit : > On Sat, 11 Aug 2012, Laurent Bigonville wrote: > > > Le Sat, 11 Aug 2012 14:01:21 -0400 (EDT), > > Alan Stern a écrit : > > > > Hi, Hi, > > > > > Try using usbmon to see what happens when the UPS is plugged in > > > (instructions are in Documentation/usb/usbmon.txt). > > > > Thanks for your answer. > > > > Please see the attached logs. Hope this will help. > > The log looks quite normal, except at the end. The computer asks the > UPS device for a bunch of reports, which it sends okay ... until it > doesn't. For some reason that UPS didn't send anything when asked > for one of the reports, and 10 seconds later the computer gave up. > > (The reason you see a total delay of 13 seconds rather than 10 is > because the device takes 3 seconds to transmit its report descriptor.) > > I don't know how well this will work, but you can tell the computer > not to ask for all those reports by using an appropriate module > parameter for the usbhid driver: > > modprobe usbhid quirks=0x0463:0x:0x8 > > Or maybe you'll need to put an equivalent "options" line in some file > under /etc/modprobe.d/. > > Anyway, let's see if that works. It seems it's with this parameter, the "lag" is down to 3 sec. Cheers Laurent Bigonville 8801b4e8a800 1339721245 S Ci:7:001:0 s a3 00 0001 0004 4 < 8801b4e8a800 1339721255 C Ci:7:001:0 0 4 = 0001 8801b4e8a800 1339721258 S Ci:7:001:0 s a3 00 0002 0004 4 < 8801b4e8a800 1339721261 C Ci:7:001:0 0 4 = 01030100 8801b4e8a800 1339721262 S Co:7:001:0 s 23 01 0010 0002 0 8801b4e8a800 1339721265 C Co:7:001:0 0 0 8801b430b300 1339825282 S Ii:7:001:1 -115:128 2 < 8801b4e8a800 1339825308 S Ci:7:001:0 s a3 00 0002 0004 4 < 8801b4e8a800 1339825313 C Ci:7:001:0 0 4 = 0103 8801b4e8a800 1339825319 S Co:7:001:0 s 23 03 0004 0002 0 8801b4e8a800 1339825323 C Co:7:001:0 0 0 8801b4e8a800 1339881244 S Ci:7:001:0 s a3 00 0002 0004 4 < 8801b4e8a800 1339881266 C Ci:7:001:0 0 4 = 0303 8801b4e8a800 1339937243 S Co:7:001:0 s 23 01 0014 0002 0 8801b4e8a800 1339937246 C Co:7:001:0 0 0 8801b4e8a800 1339937256 S Ci:7:000:0 s 80 06 0100 0040 64 < 8801b4e8a800 1340038306 C Ci:7:000:0 0 18 = 12011001 0008 6304 00010102 0301 8801b4e8a800 1340038370 S Co:7:001:0 s 23 03 0004 0002 0 8801b4e8a800 1340038381 C Co:7:001:0 0 0 8801b430b300 1340073211 C Ii:7:001:1 0:128 1 = 04 8801b430b300 1340073214 S Ii:7:001:1 -115:128 2 < 8801b4e8a800 1340093304 S Ci:7:001:0 s a3 00 0002 0004 4 < 8801b4e8a800 1340093325 C Ci:7:001:0 0 4 = 0303 8801b4e8a800 1340149305 S Co:7:001:0 s 23 01 0014 0002 0 8801b4e8a800 1340149309 C Co:7:001:0 0 0 8801b4e8a800 1340149311 S Co:7:000:0 s 00 05 0008 0 8801b4e8a800 1340152305 C Co:7:000:0 0 0 8801b4e8abc0 1340169209 S Ci:7:008:0 s 80 06 0100 0012 18 < 8801b4e8abc0 1340268272 C Ci:7:008:0 0 18 = 12011001 0008 6304 00010102 0301 8801b4e8abc0 1340268338 S Ci:7:008:0 s 80 06 0200 0009 9 < 8801b4e8abc0 1340339272 C Ci:7:008:0 0 9 = 09022200 010100a0 0a 8801b4e8abc0 1340339334 S Ci:7:008:0 s 80 06 0200 0022 34 < 8801b4e8abc0 1340495302 C Ci:7:008:0 0 34 = 09022200 010100a0 0a090400 00010300 0921 10012101 22720307 05810308 8801b4e8abc0 1340495366 S Ci:7:008:0 s 80 06 0300 00ff 255 < 8801b4e8abc0 1340547301 C Ci:7:008:0 0 4 = 04030904 8801b4e8abc0 1340547366 S Ci:7:008:0 s 80 06 0302 0409 00ff 255 < 8801b4e8abc0 1340664304 C Ci:7:008:0 0 24 = 18034500 6c006c00 69007000 73006500 20004d00 41005800 8801b4e8abc0 1340664368 S Ci:7:008:0 s 80 06 0301 0409 00ff 255 < 8801b4e8abc0 1340742305 C Ci:7:008:0 0 12 = 0c034500 41005400 4f004e00 8801b4e8abc0 1340742368 S Ci:7:008:0 s 80 06 0303 0409 00ff 255 < 8801b4e8abc0 1340848270 C Ci:7:008:0 0 20 = 14034100 44004600 4c003300 39003000 36005400 8801b4e8a800 1340848582 S Co:7:008:0 s 00 09 0001 0 8801b4e8a800 1340851311 C Co:7:008:0 0 0 88018ffe10c0 1340851453 S Ci:7:008:0 s 80 06 0303 0409 00ff 255 < 88018ffe10c0 1340957307 C Ci:7:008:0 0 20 = 14034100 44004600 4c003300 39003000 36005400 88018ffe1900 1340957467 S Co:7:008:0 s 21 0a 0 88018ffe1900 1340960305 C Co:7:008:0 0 0 88018ffe1900 1340960369 S Ci:7:008:0 s 81 06 2200 0372 882 < 88018ffe1900 1344018310 C Ci:7:008:0 0 882 = 05840904 a1010910 a1000912 a100095a 85207508 95011500 26ff0065 005500b1 88019bd22b40 1344019688 S Ci:7:001:0 s a3 00 0002 0004 4 < 88019bd22b40 1344019693 C Ci:7:001:0 0 4 = 0303 880190156200 1344035269 S Ii:7:008:1 -115:16 6 <
Re: 10 seconds lag when connecting UPS device (usb_submit_urb(ctrl) failed: -1)
Le Sun, 12 Aug 2012 17:23:30 -0400 (EDT), Alan Stern a écrit : > On Sun, 12 Aug 2012, Laurent Bigonville wrote: > > > > I don't know how well this will work, but you can tell the > > > computer not to ask for all those reports by using an appropriate > > > module parameter for the usbhid driver: > > > > > > modprobe usbhid quirks=0x0463:0x:0x8 > > > > > > Or maybe you'll need to put an equivalent "options" line in some > > > file under /etc/modprobe.d/. > > > > > > Anyway, let's see if that works. > > > > It seems it's with this parameter, the "lag" is down to 3 sec. > > But does the UPS work okay when you use the parameter? If it does, > the quirk information can be added to a permanent table in the usbhid > driver. Yes it seems to work, the userspace driver can communicate with the device (at least I can see the status of the UPS). Thanks Laurent Bigonville -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 10 seconds lag when connecting UPS device (usb_submit_urb(ctrl) failed: -1)
Le Wed, 15 Aug 2012 10:53:07 -0400 (EDT), Alan Stern a écrit : > On Tue, 14 Aug 2012, Laurent Bigonville wrote: > > > > But does the UPS work okay when you use the parameter? If it > > > does, the quirk information can be added to a permanent table in > > > the usbhid driver. > > > > Yes it seems to work, the userspace driver can communicate with the > > device (at least I can see the status of the UPS). > > Okay. Below is a patch to add a permanent blacklist entry for your > UPS. With this patch you shouldn't need to use the module parameter > any more. Please try it out and let me know if it works; if it does > I will submit it for inclusion in the kernel. Alright, I've recompiled linux kernel 3.5 with the patch and it seems to work. Thanks! Laurent Bigonville -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Weird Serial number with Fitbit Base Station dongle
Hi, This is probably a minor issue, but when plugin the Fitbit base station dongle, I'm getting some weird serial number in dmesg. Can something be done here? Kind regards Laurent Bigonville [ 9993.722197] usb 1-1.2: new full-speed USB device number 7 using ehci-pci [ 9993.820617] usb 1-1.2: New USB device found, idVendor=2687, idProduct=fb01 [ 9993.820622] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 9993.820625] usb 1-1.2: Product: Fitbit Base Station [ 9993.820627] usb 1-1.2: Manufacturer: Fitbit Inc. [ 9993.820629] usb 1-1.2: SerialNumber: \xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf [ 9993.824615] hid-generic 0003:2687:FB01.0008: hiddev0,hidraw1: USB HID v1.11 Device [Fitbit Inc. Fitbit Base Station] on usb-:00:1a.0-1.2/input0 [ 9993.827453] hid-generic 0003:2687:FB01.0009: hiddev0,hidraw2: USB HID v1.11 Device [Fitbit Inc. Fitbit Base Station] on usb-:00:1a.0-1.2/input1 Bus 001 Device 007: ID 2687:fb01 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize032 idVendor 0x2687 idProduct 0xfb01 bcdDevice1.00 iManufacturer 1 Fitbit Inc. iProduct2 Fitbit Base Station iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 73 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 50mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.11 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 54 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 2 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.11 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 54 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage
Re: Weird Serial number with Fitbit Base Station dongle
Le Tue, 23 Jul 2013 10:16:00 -0400 (EDT), Alan Stern a écrit : > On Tue, 23 Jul 2013, Laurent Bigonville wrote: > > > Hi, > > > > This is probably a minor issue, but when plugin the Fitbit base > > station dongle, I'm getting some weird serial number in dmesg. > > > > Can something be done here? > > > > Kind regards > > > > Laurent Bigonville > > > > [ 9993.722197] usb 1-1.2: new full-speed USB device number 7 using > > ehci-pci [ 9993.820617] usb 1-1.2: New USB device found, > > idVendor=2687, idProduct=fb01 [ 9993.820622] usb 1-1.2: New USB > > device strings: Mfr=1, Product=2, SerialNumber=3 [ 9993.820625] usb > > 1-1.2: Product: Fitbit Base Station [ 9993.820627] usb 1-1.2: > > Manufacturer: Fitbit Inc. [ 9993.820629] usb 1-1.2: SerialNumber: > > \xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf\xffef\xffbf\xffbf\xffbf\xffbf > > It may be that, weird as this looks, it is actually correct. > > Can you post a usbmon trace showing what happens when the dongle is > first plugged? Instructions are in the kernel source file > Documentation/usb/usbmon.txt. I hope this is enough: 8801b840fbc0 3460461486 S Ci:7:001:0 s a3 00 0001 0004 4 < 8801b840fbc0 3460461497 C Ci:7:001:0 0 4 = 0001 8801b840fbc0 3460461500 S Ci:7:001:0 s a3 00 0002 0004 4 < 8801b840fbc0 3460461503 C Ci:7:001:0 0 4 = 0001 8801b840fbc0 3460461505 S Ci:7:001:0 s a3 00 0003 0004 4 < 8801b840fbc0 3460461507 C Ci:7:001:0 0 4 = 0001 8801b840fbc0 3460461508 S Ci:7:001:0 s a3 00 0004 0004 4 < 8801b840fbc0 3460461510 C Ci:7:001:0 0 4 = 0001 8801b840fbc0 3460461511 S Ci:7:001:0 s a3 00 0005 0004 4 < 8801b840fbc0 3460461513 C Ci:7:001:0 0 4 = 0705 8801b840fbc0 3460461515 S Ci:7:001:0 s a3 00 0006 0004 4 < 8801b840fbc0 3460461517 C Ci:7:001:0 0 4 = 0001 8801b533d680 3460461518 S Ii:7:001:1 -115:2048 4 < 8801b533d680 3460465524 C Ii:7:001:1 0:2048 1 = 20 8801b533d680 3460465531 S Ii:7:001:1 -115:2048 4 < 880170d62e00 3460465611 S Ci:7:001:0 s a3 00 0005 0004 4 < 880170d62e00 3460465653 C Ci:7:001:0 0 4 = 03050400 880170d62e00 3460465655 S Co:7:001:0 s 23 01 0012 0005 0 880170d62e00 3460465660 C Co:7:001:0 0 0 880170d62e00 3460481441 S Ci:7:001:0 s a3 00 0005 0004 4 < 880170d62e00 3460481446 C Ci:7:001:0 0 4 = 0305 880170d62e00 3460481449 S Ci:7:004:0 s 80 00 0002 2 < 880170d62e00 3460481592 C Ci:7:004:0 0 2 = 0300 880170d62e00 3460481696 S Co:7:004:0 s 00 01 0001 0 880170d62e00 3460481842 C Co:7:004:0 0 0 880170d62e00 3460481922 S Ci:7:004:0 s a3 00 0001 0004 4 < 880170d62e00 3460482114 C Ci:7:004:0 0 4 = 0001 880170d62e00 3460482198 S Ci:7:004:0 s a3 00 0002 0004 4 < 880170d62e00 3460482368 C Ci:7:004:0 0 4 = 01010100 880170d62e00 3460482454 S Co:7:004:0 s 23 01 0010 0002 0 880170d62e00 3460482613 C Co:7:004:0 0 0 880170d62e00 3460482692 S Ci:7:004:0 s a3 00 0003 0004 4 < 880170d62e00 3460482869 C Ci:7:004:0 0 4 = 0001 880170d62e00 3460482895 S Ci:7:004:0 s a3 00 0004 0004 4 < 880170d62e00 3460483105 C Ci:7:004:0 0 4 = 0001 8801b485c500 3460585479 S Ii:7:004:1 -115:2048 1 < 880170d62e00 3460585496 S Ci:7:004:0 s a3 00 0002 0004 4 < 880170d62e00 3460585554 C Ci:7:004:0 0 4 = 0101 880170d62e00 3460585604 S Co:7:004:0 s 23 03 0004 0002 0 880170d62e00 3460585669 C Co:7:004:0 0 0 8801b76a1840 3460601424 S Ci:7:004:0 s a3 00 0002 0004 4 < 8801b76a1840 3460601635 C Ci:7:004:0 0 4 = 1101 8801b840fbc0 3460617472 S Ci:7:004:0 s a3 00 0002 0004 4 < 8801b840fbc0 3460617537 C Ci:7:004:0 0 4 = 03011000 8801b840fbc0 3460673477 S Co:7:004:0 s 23 01 0014 0002 0 8801b840fbc0 3460673546 C Co:7:004:0 0 0 8801b840fbc0 3460673572 S Ci:7:000:0 s 80 06 0100 0040 64 < 8801b840fbc0 3460674092 C Ci:7:000:0 0 18 = 12010002 0020 872601fb 00010102 0301 8801b840fbc0 3460674158 S Co:7:004:0 s 23 03 0004
ioctl for HID Power devices (UPS) always returning 0
Hello,
For quite some time, upower is not properly displaying the information
from my Eaton UPS, looking at this it seems that the kernel is not
returning the correct information.
I've attached a test program (that is heavily inspired by apcupsd
hid-ups example) that displays:
UPS HID device name: "EATON Ellipse ECO"
Battery Chemistry: "" (0)
Battery Capacity: (null)
As you can see, the values are set to 0.
Any idea what's wrong here?
Kind regards,
Laurent Bigonville
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define BAT_CHEMISTRY 0x850089
#define UPS_CAPACITY_MODE 0x85002c
static const char *get_string(int fd, int sindex) {
static struct hiddev_string_descriptor sdesc;
static char buf[200];
if (sindex == 0) {
return "";
}
sdesc.index = sindex;
if (ioctl(fd, HIDIOCGSTRING, &sdesc) < 0) {
sprintf(buf, "String index %d returned ERR=%s\n", sindex,
strerror(errno));
return buf;
}
return sdesc.value;
}
int main(void) {
int fd;
char name[256] = "Unknown";
struct hiddev_usage_ref uref;
if ((fd = open("/dev/usb/hiddev4", O_RDONLY)) < 0) {
perror("open");
exit(1);
}
ioctl(fd, HIDIOCINITREPORT, 0);
ioctl(fd, HIDIOCGNAME(sizeof(name)), name);
printf("UPS HID device name: \"%s\"\n", name);
memset(&uref, 0, sizeof(uref));
uref.report_type = HID_REPORT_TYPE_FEATURE;
uref.report_id = HID_REPORT_ID_UNKNOWN;
uref.usage_code = BAT_CHEMISTRY;
if (ioctl(fd, HIDIOCGUSAGE, &uref) == 0) {
printf("Battery Chemistry: \"%s\" (%d)\n", get_string(fd, uref.value),
uref.value);
}
memset(&uref, 0, sizeof(uref));
uref.report_type = HID_REPORT_TYPE_FEATURE;
uref.report_id = HID_REPORT_ID_UNKNOWN;
uref.usage_code = UPS_CAPACITY_MODE;
if (ioctl(fd, HIDIOCGUSAGE, &uref) == 0) {
printf("Battery Capacity: %s\n", uref.value);
}
close(fd);
return 0;
}
Re: ioctl for HID Power devices (UPS) always returning 0
Le 30/09/18 à 13:59, Laurent Bigonville a écrit : Hello, For quite some time, upower is not properly displaying the information from my Eaton UPS, looking at this it seems that the kernel is not returning the correct information. OK, the issue comes from 67ddbb3e6568fb1820b2cc45b00c50702b114801 (adding HID_QUIRK_NOGET for these devices, which I'm partially responsible of as I was seeing a 10s delay back then) If I revert the commit, I can see the values as expected, but I still see a delay of 3 sec between the moment the USB device is seen by the kernel and the HID driver is initialized: [ 343.392860] usb 6-1: new low-speed USB device number 3 using uhci_hcd [ 345.456954] usb 6-1: New USB device found, idVendor=0463, idProduct=, bcdDevice= 1.00 [ 345.456958] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4 [ 345.456960] usb 6-1: Product: Ellipse ECO [ 345.456963] usb 6-1: Manufacturer: EATON [ 345.456965] usb 6-1: SerialNumber: 0 [ 348.782970] hid-generic 0003:0463:.000A: hiddev4,hidraw6: USB HID v10.10 Device [EATON Ellipse ECO] on usb-:00:1d.0-1/input0 An idea what should be done here?
