<p dir="ltr">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.)</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 26, 2024, 21:06 Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com">jimklimov+nut@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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?</p>
<p dir="ltr">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).</p>
<p dir="ltr">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?)</p>
<p dir="ltr">Hope this helps,<br>
Jim Klimov</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 26, 2024, 15:53 William R. Elliot <<a href="mailto:bill@wreassoc.com" target="_blank" rel="noreferrer">bill@wreassoc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<font size="3">Jim,<br><br>
Thanks for the quick reply.<br><br>
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><br>
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><br>
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><br>
Thanks,<br><br>
Bill<br><br>
At 01:50 AM 11/26/2024, Jim Klimov wrote:<br>
<blockquote type="cite">Cheers,<br><br>
This error message usually deals with a couple of
situations:<br><br>
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><br>
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><br>
Happy Thanksgiving,<br>
Jim<br><br>
On Tue, Nov 26, 2024 at 4:37 AM William R. Elliot
<<a href="mailto:bill@wreassoc.com" rel="noreferrer noreferrer" target="_blank">bill@wreassoc.com</a>>
wrote:<br>
</blockquote></font>
<dl>
<dd>Hello again.<br><br>
<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.<br><br>
<dd>This is the relevent output following a successful match and trying
to open the device:<br><br>
<dd><font face="Courier New, Courier" size="3">
0.002511 [D2] Checking device 2 of 5
(1234/0001)<br>
<dd> 0.002564 [D1] Failed to open
device (1234/0001), skipping: Access denied (insufficient
permissions)<br><br>
</dd></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.<br><br>
<dd>I would appreciate any pointers toward something I may have
missed.<br><br>
<dd>Thank you,<br><br>
<dd>Bill<br><br>
<dd>Happy Thanksgiving to the U.S. folks!<br><br>
<dd>
Virus-free.<a href="http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" rel="noreferrer noreferrer" target="_blank">
www.avg.com</a>
<a href="#m_-887649569300041980_m_-5248667457445858416_m_-6725320979215136950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" rel="noreferrer noreferrer">
<br>
</a>
<dd>_______________________________________________<br>
<dd>Nut-upsdev mailing list<br>
<dd><a href="mailto:Nut-upsdev@alioth-lists.debian.net" rel="noreferrer noreferrer" target="_blank">
Nut-upsdev@alioth-lists.debian.net</a><br>
<dd>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer noreferrer" target="_blank">
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a>
<br>
</dd></dd></dd></dd></dd></dd></dd></dd></dd></dd></dd></dd></dd></dd></dl></div>
</blockquote></div>
</blockquote></div>