On Tue, 23 Nov 2021 17:33:08 +0100 Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> wrote: > 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. <snip> I'll send a message their way. Thanks, David
