<html>
<body>
<font size=3>Jim, see two comments/questions below...<br><br>
Bill<br><br>
At 01:50 AM 11/26/2024, Jim Klimov wrote:<br>
<blockquote type=cite class=cite 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;</font></blockquote><br>
Thank you, this seems to be the primary problem. I learned enough about
udev to find that the first UPS I was testing with had 'root nut'
ownership. The second UPS used for testing had 'root root' ownership.
When I manually changed the second UPS to 'root nut' ownership the driver
behaved as expected with the second UPS.<br><br>
The question I have now is: Why did the second UPS need manual ownership
change and the first one did not? I know that I didn't do anything down
the /dev/bus/usb/xxx path until today.<br><br>
<font size=3>I have been running the driver in the foreground for the
second UPS but I know I had run the driver "normally" on the
first UPS. Would the ownership have been changed due to the
"normal" driver run versus the "foreground" driver
run? Perhaps something that gets done using 'upsdrvctl' that doesn't get
done just running the driver by itself?<br><br>
<br>
<blockquote type=cite class=cite cite="">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).</font></blockquote><br>
Didn't go here as I made progress with udev above. Plus I am the only one
running the driver on this machine.<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>Happy
Thanksgiving,<br>
Jim<br><br>
On Tue, Nov 26, 2024 at 4:37 AM William R. Elliot
<<a href="mailto:bill@wreassoc.com">bill@wreassoc.com</a>>
wrote:<br>
</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>
</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">
www.avg.com</a>
<a href="#m_-6725320979215136950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2">
<br>
</a>
<dd>_______________________________________________<br>
<dd>Nut-upsdev mailing list<br>
<dd><a href="mailto:Nut-upsdev@alioth-lists.debian.net">
Nut-upsdev@alioth-lists.debian.net</a><br>
<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>
<br>
</dl></blockquote></body>
</html>