On Mon, Nov 22, 2021 at 10:35 PM Filipe Laíns <lains@xxxxxxxxxxxxx> wrote: > > On Mon, 2021-11-22 at 15:13 -0500, Alan Stern wrote: > > On Mon, Nov 22, 2021 at 11:25:26AM -0500, David Niklas wrote: > > > Ok, I first edited the kernel to return -ENOMEM like you suggested but > > > the UPS still disconnected. I then edited it again to re-add the 1060 > > > byte request and the UPS still disconnected. > > > > > > I'm attaching the usbmon traces. > > > If you need any additional info I'll do my best to provide it. > > > > Holy cow! I just realized what's going on. And these little changes > > we've been messing around with have nothing to do with it. > > > > For the first time, I looked at the timestamps in the usbmon traces. It > > turns out that the disconnects occur several seconds after the kernel > > retrieves the HID report descriptor from the device. Under normal > > conditions we would expect to see report packets coming in from the > > device, starting just a fraction of a second after the descriptor is > > received. But that isn't happening in the Linux traces, whereas it does > > happen in the Windows pcap log. > > > > I would guess that the UPS is programmed to disconnect itself > > electronically from the USB bus if it doesn't get any requests for > > reports within a couple of seconds. That certainly would explain what > > you've been seeing. I can't imagine why it would be programmed to > > behave this way, but companies have been known to do stranger things. > > > > As for why the kernel doesn't try to get the reports... That's a little > > harder to answer. Maybe Jiri or Benjamin will know something about it. I am not sure exactly what is going on there. There are a couple of things that come to my mind: - for quite some time now, we don't fetch all reports whenever we connect a new device. This was known to be problematic on some devices (see all the devices with HID_QUIRK_NOGET or HID_QUIRK_NO_INIT_REPORT), and the default to not poll input values on plug for devices is actually safer. If you want to revert, we will have to have a special driver for this one I guess - HID_QUIRK_ALWAYS_POLL *might* be a way to force the device to stay with a USB connection up. > > > > The UPS's vendor ID is 0d9f (POWERCOM) and the product ID is 0004. Now, > > the drivers/hid/hid-quirks.c file contains a quirk entry for 0d9f:0002 > > (product POWERCOM_UPS), which is probably an earlier model of the same > > device, or a very similar device. This quirk entry is in the > > hid_ignore_list; it tells the HID core not to handle the device at all. > > > > I don't know why that quirk entry is present, and furthermore, it can't > > directly affect what is happening with your device because the product > > IDs are different. Still, it is an indication that something strange is > > going on behind the scenes. > > > > Perhaps there is no kernel driver for these UPS devices? Perhaps the > > intention is that some user program will handle all the communication > > when one of them is detected? A quick search on Google turns up > > usbhid-ups, part of Network USB Tools (NUT) -- maybe you need to > > install that package in order to use the device. I don't have enough experience with UPS here to be helpful, unfortunately. But What Alan said made a lot of sense. Maybe the NUT people will have a better insight. > > > > I don't know what the full story is. With luck, Jiri or Benjamin can > > help more. > > > > Alan Stern > > hid-generic should be able to handle these devices, but UPSes are much less > tested than normal input peripherals, so it's not that surprising that there may > be some unexpected weirdness. FWIW, I have two UPSes, one works OOTB and the > other doesn't, I have been meaning to investigate the issue. However, David's > case seems to me like a hardware quirk, but that's just my guess. > Yep, that seems to validate the fact that this UPS needs some care... Cheers, Benjamin
