Regarding the follow-up, IIRC `open` walks a device list returned by libusb, checks each entry against the matcher, and tells libusb if it wants to claim the device described by a particular entry. I don't think it walks further entries after a successful match and claim?
We can't use the matcher directly, because its fields can be a regex geberally (e.g. `vendor=A*` instead of `APC` or `Aardwark` specifically), and because libusb device descriptors are a black box for us (FD, struct, blob - whatever the token we pass to library methods is on a platform and lib version). Also matching can involve callbacks, so a driver can probe the device in more detail (okay, you're APC - but do you talk USB HID or Modbus or microsol?) Hope this helps, Jim Klimov On Tue, Nov 26, 2024, 15:53 William R. Elliot <[email protected]> wrote: > Jim, > > Thanks for the quick reply. > > I'll try number 1 below but I don't have the understanding as to why that > would be for this UPS and not the other UPS in the family. > > For number 2, kind of the same comment. Why would someone else hold this > device and not the other vendor ups that is working. I am running the > driver in the foreground and not through a debugger. > > A follow up question that hit me this morning even though I have seen the > evidence for weeks: If there is a successful Regex Match, why does the > "open" command walk through the five or so available USB devices? Why is > "open" not just opening what is in the matcher structure? I'm clearly > missing something here about how all the USB stuff works. > > Thanks, > > Bill > > At 01:50 AM 11/26/2024, Jim Klimov wrote: > > Cheers, > > This error message usually deals with a couple of situations: > > 1) Actual lack of permissions (POSIX bits in devfs) - usually solved by > `udev` or similar subsystem that handles hotplug HW for the OS. Or by > running the driver as root and not losing the privileges (user=root in > ups.conf) as a temporary fix and check that this is the case at all; > > 2) Someone else has hold of the device and libusb can't take it as > exclusively as NUT needs (lsof/fuser/... to check if any other programs > hold it - maybe another copy of your driver program in debugger etc). > > Happy Thanksgiving, > Jim > > On Tue, Nov 26, 2024 at 4:37 AM William R. Elliot <[email protected]> > wrote: > > Hello again. > > The USB device table in the driver I am working on has two entries for the > particular vendor ID I am working with, one for each of two product > IDs...0x0001 and 0x0002. The driver properly matches and can open the > device with the 0x0002 product ID. However, running the same driver with > the 0x0001 ups attached matches but fails to open. > > This is the relevent output following a successful match and trying to > open the device: > > 0.002511 [D2] Checking device 2 of 5 (1234/0001) > 0.002564 [D1] Failed to open device (1234/0001), skipping: Access > denied (insufficient permissions) > > My expectation would be that either device, once matched, would be able to > be opened and then further steps can be taken to confirm that the driver is > communicating with an expected device. > > I would appreciate any pointers toward something I may have missed. > > Thank you, > > Bill > > Happy Thanksgiving to the U.S. folks! > > Virus-free. www.avg.com > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > > <#m_-5248667457445858416_m_-6725320979215136950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > _______________________________________________ > Nut-upsdev mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
