<html>
<body>
<font size=3>Jim,<br><br>
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.<br><br>
Bill<br><br>
<br>
At 02:11 PM 11/26/2024, Jim Klimov wrote:<br><br>
<blockquote type=cite class=cite cite="">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.)<br><br>
On Tue, Nov 26, 2024, 21:06 Jim Klimov
<<a href="mailto:jimklimov%2Bnut@gmail.com">jimklimov+nut@gmail.com</a>
> wrote:
<dl>
<dd>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?<br>
<dd>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).<br>
<dd>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?)<br>
<dd>Hope this helps,
<dd>Jim Klimov<br>
<dd>On Tue, Nov 26, 2024, 15:53 William R. Elliot
<<a href="mailto:bill@wreassoc.com">bill@wreassoc.com</a>> wrote:
<dl>
<dd>Jim,<br>
<dd>Thanks for the quick reply.<br>
<dd>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.<br>
<dd>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.<br>
<dd>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.<br>
<dd>Thanks,<br>
<dd>Bill<br>
<dd>At 01:50 AM 11/26/2024, Jim Klimov
wrote:<blockquote type=cite class=cite cite="">
<dd>Cheers,<br>
<dd> This error message usually deals with a couple of
situations:<br>
<dd>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;<br>
<dd>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).<br>
<dd>Happy Thanksgiving,
<dd>Jim<br>
<dd>On Tue, Nov 26, 2024 at 4:37 AM William R. Elliot
<<a href="mailto:bill@wreassoc.com">bill@wreassoc.com</a>>
wrote:</blockquote>
<dl>
<dd>Hello again.
<dd>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.
<dd>This is the relevent output following a successful match and trying
to open the device:</font>
<dd><font face="Courier New, Courier" size=3>
0.002511 [D2] Checking device 2 of 5 (1234/0001)
<dd> 0.002564 [D1] Failed to open
device (1234/0001), skipping: Access denied (insufficient
permissions)<br><br>
</font>
<dd>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.
<dd>I would appreciate any pointers toward something I may have missed.
<dd>Thank you,
<dd>Bill
<dd>Happy Thanksgiving to the U.S. folks!
<dd>Virus-free.
<a href="https://www.avg.com/" eudora="autourl">www.avg.com</a>
<a href="https://www.avg.com/" eudora="autourl"> </a>
<dd>_______________________________________________
<dd>Nut-upsdev mailing list
<dd><a href="mailto:Nut-upsdev@alioth-lists.debian.net">
Nut-upsdev@alioth-lists.debian.net</a>
<dd>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" eudora="autourl">
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a>
</dl>
</dl>
</dl></blockquote><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /><table style="border-top: 1px solid #D3D4DE;"><tr><td style="width: 55px; padding-top: 13px;"><a href="http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-green-avg-v1.png" alt="" width="46" height="29" style="width: 46px; height: 29px;"/></a></td><td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free.<a href="http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank" style="color: #4453ea;">www.avg.com</a></td></tr></table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>