Thanks for the additional information. I don't want to become an expert on USB but I still need to know enough to make sure the driver is solid.
Bill
At 02:11 PM 11/26/2024, Jim Klimov wrote:
Thinking of it, we can't conjure a libusb descriptor from thin air because the library can have internal state associated with it (allocated buffers, open-close count, etc.)
On Tue, Nov 26, 2024, 21:06 Jim Klimov <[email protected] > wrote:
- 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:
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
