pyusb-users — PyUSB users mailing list discussion

Re: [pyusb-users] No backend available (I read the FAQ!)

[Jonas M. <jo...@pr...>]

On Wed, Jun 19, 2024 at 10:47 PM Michael Cannizzaro via pyusb-users
<pyu...@li...> wrote:
>
> Hello,
>
> I’m on a Mac and I’ve been trying to get my libusb1 backend installed and recognized by PyUSB, to no avail.
>
> I’ve tried installing libusb via both the Homebrew method and the pip install method. Both worked successfully, but I still get “No backend available” when debugging with usb.core.find().
>
> Here’s the output of the script from the FAQ:
>
> 2024-06-19 21:38:46,878 ERROR:usb.libloader:'Libusb 1' could not be found
>
> 2024-06-19 21:38:46,878 ERROR:usb.backend.libusb1:Error loading libusb 1.0 backend
>
> 2024-06-19 21:38:46,879 ERROR:usb.libloader:'OpenUSB library' could not be found
>
> 2024-06-19 21:38:46,879 ERROR:usb.backend.openusb:Error loading OpenUSB backend
>
> 2024-06-19 21:38:46,879 ERROR:usb.libloader:'Libusb 0' could not be found
>
> 2024-06-19 21:38:46,879 ERROR:usb.backend.libusb0:Error loading libusb 0.1 backend
>
> Traceback (most recent call last):
>
>   File "<stdin>", line 1, in <module>
>
>   File "/Users/mike/anaconda3/lib/python3.11/site-packages/usb/core.py", line 1309, in find
>
>     raise NoBackendError('No backend available')
>
> usb.core.NoBackendError: No backend available
>
>
> I’m running Python 3.11.5 and PyUSB 1.2.1. Please let me know if you need any additional information!

Hi Mike,

You can give <https://github.com/pyusb/pyusb/pull/511> a try.

-- 
Jonas

[pyusb-users] No backend available (I read the FAQ!)

[Michael C. <mca...@ic...>]

Hello,

I’m on a Mac and I’ve been trying to get my libusb1 backend installed and recognized by PyUSB, to no avail.

I’ve tried installing libusb via both the Homebrew method and the pip install method. Both worked successfully, but I still get “No backend available” when debugging with usb.core.find().

Here’s the output of the script from the FAQ:

2024-06-19 21:38:46,878 ERROR:usb.libloader:'Libusb 1' could not be found
2024-06-19 21:38:46,878 ERROR:usb.backend.libusb1:Error loading libusb 1.0 backend
2024-06-19 21:38:46,879 ERROR:usb.libloader:'OpenUSB library' could not be found
2024-06-19 21:38:46,879 ERROR:usb.backend.openusb:Error loading OpenUSB backend
2024-06-19 21:38:46,879 ERROR:usb.libloader:'Libusb 0' could not be found
2024-06-19 21:38:46,879 ERROR:usb.backend.libusb0:Error loading libusb 0.1 backend
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/mike/anaconda3/lib/python3.11/site-packages/usb/core.py", line 1309, in find
    raise NoBackendError('No backend available')
usb.core.NoBackendError: No backend available

I’m running Python 3.11.5 and PyUSB 1.2.1. Please let me know if you need any additional information!

Thanks,
Mike Cannizzaro

Re: [pyusb-users] USB using HID RFID Reader

[chris c. <cl...@gm...>]

TL;DR I would recommend AGAINST using pyusb for HID use cases, if you are
on Linux instead use udev.

If you need to know the device that was used to read, I would create a
virtual device id if you really want to read directly from pyusb.. BUT I
would recommend against it.

I've not had to deal with this as I only use one device per USB host.

Take a look at:

  * https://github.com/clach04/keyboard2mqtt - recommended approach, NOTE
doesn't have great user-facing documentation but the code should be easy to
read
  * https://github.com/clach04/pyusb-keyboard-alike - hitting USB directly


On Tue, May 7, 2024 at 2:44 AM Charles Harris <cha...@sl...>
wrote:

> Hi
>
> There are many USB rfid devices to read tags.  They all have identical
> vid and pid, and no device ID.
>
> When using hid into a spreadsheet some form of ID needs to be given for
> each device so that spreadsheet can manipulate data into areas etc.
>
> https://github.com/pyusb/pyusb/blob/master/docs/tutorial.rst
>
> This link refers to multiple usb with same pid vid.   Also refers to
> options   'bus'  and 'address' that could enable ID.
>
> Is there any tutorials or advice on simply how to use one or both  of
> these to attach Device ID to the tag read being processed to the
> spreadsheet.  Suffix or prefix or in a adjacent column.
>
> With the usb rfid reader connected to pc or spreadsheet, is it possible
> to access preferences or whatever on device and process a pyusb code to
> allow and set change on the usb device itself, for the bus or address
> from 'none' to a reference.   Each device would be
> different.https://github.com/pyusb/pyusb/blob/master/docs/tutorial.rst
>
> A standard procedure to do this would be very useful .  I am noobie to
> python etc and would need guidance.
>
> Thankyou
>
> Charles Harris
>
> NZ
>
>
>
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>

[pyusb-users] USB using HID RFID Reader

[Charles H. <cha...@sl...>]

Hi

There are many USB rfid devices to read tags.  They all have identical 
vid and pid, and no device ID.

When using hid into a spreadsheet some form of ID needs to be given for 
each device so that spreadsheet can manipulate data into areas etc.

https://github.com/pyusb/pyusb/blob/master/docs/tutorial.rst

This link refers to multiple usb with same pid vid.   Also refers to 
options   'bus'  and 'address' that could enable ID.

Is there any tutorials or advice on simply how to use one or both  of 
these to attach Device ID to the tag read being processed to the 
spreadsheet.  Suffix or prefix or in a adjacent column.

With the usb rfid reader connected to pc or spreadsheet, is it possible 
to access preferences or whatever on device and process a pyusb code to 
allow and set change on the usb device itself, for the bus or address 
from 'none' to a reference.   Each device would be 
different.https://github.com/pyusb/pyusb/blob/master/docs/tutorial.rst

A standard procedure to do this would be very useful .  I am noobie to 
python etc and would need guidance.

Thankyou

Charles Harris

NZ

[pyusb-users] No error but no success as well

[ConDeS G. & C. K. <j.s...@co...>]

Hi,

I’m using PyUSB both on an Ubuntu and a Mac osX machine. The code on the Mac jkust works fine, it uses PyUSB to communicate to an D1Mini ESP8266 chip. This chip controls some LED using WLED.

If I run the same code on the Ubuntu side, I needed to sort out some issues:
-	Adjust permissions for the USB device
-	Add the user to DIALOUT group
-	Remove brltty-Service

As a result I was able to run the code without any error. Even when switching Debugging on, it gives me the very same result as compared to the Mac.

The problem is that the lights don’r react on the Ubuntu side, whereas everything works fine on the Mac side. I spent some hours searching for an explanation but couldn't see any reason. Boths implementations use libusb1.0, the only difference being that on Ubuntu it says to utilize libusb-1.0.so <http://libusb1.0.so/>.0 whereas on the Mac it says libusb-1.dylib

Both implementations state that they successfully passed the same amount of data to the USB device, no errors are shown on either side. Both sides run the exact same hardware (I switch it between the PCs)

My understanding is that once the data is transmitted to the USB device, the OS of the sending computer should not matter anymore, so I’m having no idea on where to search for a solution for this problem. 

Has anybody an idea on what I could check?

Here’s a debug output from the Mac but the Linux side looks exactly the same:

2024-04-07 17:36:42,699 DEBUG:usb.backend.libusb1:_LibUSB.__init__(<CDLL '/usr/local/lib/libusb-1.0.dylib', handle 7ff91832b330 at 0x10a9facc0>)
2024-04-07 17:36:42,709 INFO:usb.core:find(): using backend "usb.backend.libusb1"
2024-04-07 17:36:42,709 DEBUG:usb.backend.libusb1:_LibUSB.enumerate_devices()
2024-04-07 17:36:42,709 DEBUG:usb.backend.libusb1:_LibUSB.get_device_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>)
2024-04-07 17:36:42,709 DEBUG:usb.backend.libusb1:_LibUSB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.open_device(<usb.backend.libusb1._Device object at 0x10acc4980>)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.set_configuration(<usb.backend.libusb1._DeviceHandle object at 0x10a9fb560>, 1)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_interface_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0, 0, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_endpoint_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0, 0, 0, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_interface_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0, 0, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_endpoint_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 1, 0, 0, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_interface_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0, 0, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_interface_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0, 0, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_endpoint_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0, 0, 0, 0)
2024-04-07 17:36:42,710 DEBUG:usb.backend.libusb1:_LibUSB.get_interface_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0, 0, 0)
2024-04-07 17:36:42,711 DEBUG:usb.backend.libusb1:_LibUSB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0)
2024-04-07 17:36:42,711 DEBUG:usb.backend.libusb1:_LibUSB.get_endpoint_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 1, 0, 0, 0)
2024-04-07 17:36:42,711 DEBUG:usb.backend.libusb1:_LibUSB.get_interface_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0, 0, 0)
2024-04-07 17:36:42,711 DEBUG:usb.backend.libusb1:_LibUSB.get_configuration_descriptor(<usb.backend.libusb1._Device object at 0x10acc4980>, 0)
2024-04-07 17:36:42,711 DEBUG:usb.backend.libusb1:_LibUSB.claim_interface(<usb.backend.libusb1._DeviceHandle object at 0x10a9fb560>, 0)
2024-04-07 17:36:42,712 DEBUG:usb.backend.libusb1:_LibUSB.bulk_write(<usb.backend.libusb1._DeviceHandle object at 0x10a9fb560>, 2, 0, array('B', [123, 34, 111, 110, 34, 58, 116, 114, 117, 101, 125]), 1000)
Bytes written: 11
2024-04-07 17:36:42,744 DEBUG:usb.backend.libusb1:_LibUSB.release_interface(<usb.backend.libusb1._DeviceHandle object at 0x10a9fb560>, 0)
2024-04-07 17:36:42,744 DEBUG:usb.backend.libusb1:_LibUSB.close_device(<usb.backend.libusb1._DeviceHandle object at 0x10a9fb560>)
2024-04-07 17:36:42,744 DEBUG:usb.backend.libusb1:_LibUSB._finalize_object()

[pyusb-users] Permission error

[Chaima K. <cha...@ka...>]

Hello,

I am using pyusb to communicate with a Brother label printer on windows. it
worked fine for months and now all of the sudden I started getting
permission issues : usb.core.USBError: [Errno 13] Access denied
(insufficient permissions)

At first this was solved by unplugging and replugging the printer. but
after a while that doesn't work anymore.
I am having issues understanding the reason behind this and how to solve it
( I am on windows and I can't get admin rights because it's a company
laptop).
admin rights are very strict so they're only allowing us to download the
driver with that.
NA: the drivers for the printer are updated.

thank you

[pyusb-users] HELP

[George K. | E. <geo...@ec...>]

Hi!

I am getting this error:

2022-06-06 10:54:33,681 ERROR:usb.libloader:Libusb 1 (C:\WINDOWS\system32\libusb-1.0.dll) could not be loaded
Traceback (most recent call last):
  File "C:\Users\ecotx\Envs\E-watt\lib\site-packages\usb\libloader.py", line 116, in load_library
    return lib_cls(lib)
  File "C:\Users\ecotx\AppData\Local\Programs\Python\Python310\lib\ctypes\__init__.py", line 374, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: [WinError 193] %1 não é um aplicativo Win32 válido
2022-06-06 10:54:33,685 ERROR:usb.backend.libusb1:Error loading libusb 1.0 backend
2022-06-06 10:54:33,685 ERROR:usb.libloader:'OpenUSB library' could not be found
2022-06-06 10:54:33,685 ERROR:usb.backend.openusb:Error loading OpenUSB backend
2022-06-06 10:54:33,689 INFO:usb.core:find(): using backend "usb.backend.libusb0"
2022-06-06 10:54:33,689 DEBUG:usb.backend.libusb0:_LibUSB.enumerate_devices()

when running the following code:

import os
os.environ['PYUSB_DEBUG'] = 'debug'
import usb.core
usb.core.find()

Re: [pyusb-users] Garmin Ant+ dongle - _usb_reap_async - reaping request failed

[stuart l. <stu...@gm...>]

I can confirm that doing the device reset on exit corrects this issue.

One additional note, it is probably impossible to protect everything with a
try: expect: for a KeyboardInterrupt. This exception can happen more or
less at random anywhere or anytime in your program when the user does a ^C.

The only way to have a stable solution is to install a signal handler for
SIGINT. Then implement a graceful exit strategy that can do the device
reset at the correct time as you bring down the program.

See: https://docs.python.org/3/library/signal.html

If a signal handler raises an exception, the exception will be propagated
> to the main thread and may be raised after any bytecode instruction. Most
> notably, a KeyboardInterrupt may appear at any point during execution. Most
> Python code, including the standard library, cannot be made robust against
> this, and so a KeyboardInterrupt (or any other exception resulting from a
> signal handler) may on rare occasions put the program in an unexpected
> state.
>

For many programs, especially those that merely want to exit on
> KeyboardInterrupt, this is not a problem, but applications that are complex
> or require high reliability should avoid raising exceptions from signal
> handlers. They should also avoid catching KeyboardInterrupt as a means of
> gracefully shutting down. Instead, they should install their own SIGINT
> handler.





On Sat, Apr 23, 2022 at 11:30 PM stuart lynne <stu...@gm...>
wrote:

> The device reset seems to help.
>
> When properly exited it went about eight restarts correctly.
>
> Interrupted (^C) exit I think misses the device reset in some cases (I can
> fix that) and eventually it got to the FUBAR state.
>
> Once in that state opening and closing with reset does not fix it.
> Physical replug necessary.
>
> I'll clean up the exception handling so that breaking to exit goes through
> the proper closing sequence and see if that helps.
>
>
> Thanks!
>
>
> On Sat, Apr 23, 2022 at 8:45 PM Xiaofan Chen <xia...@gm...> wrote:
>
>> On Sun, Apr 24, 2022 at 8:43 AM stuart lynne <stu...@gm...>
>> wrote:
>> >
>> > I am seeing a consistent issue with Garmin Ant+ dongles under Windows
>> with libusb0.
>> >
>> > They work the first time my application runs, but fail on the second
>> attempt.
>> >
>> > I have verified the same behaviour across three Garmin Dongles. I have
>> verified
>> >  that the Cycplus Dongle works correctly.
>> >
>> > To maintain compatibility with the other applications running (Zwift
>> and PerfPro
>> > CT Smart) which rely on libusb0 I need to use that backend.
>> >
>> > Those applications do not have any problems with the Garmin (or Cycplus)
>> > dongles, using them multiple times without a problem.
>> >
>> > Is it possible that I need to do something on exit that might cause
>> this?
>> >
>> > Is there anything I can do to remediate this when seen?
>> >
>>
>> Does it make a difference if you use the libusb-1.0 backend? This is not
>> a solution but rather a troubleshooting step. You can keep your driver
>> as it is, but switch to libusb-1.0 backend. You need to have libusbk.dll
>> and libusb-1.0.dll in place to make that work.
>>
>> I understand that you may have to keep with the libusb0.sys based
>> driver provided
>> by Garmin (I used to have one such USB dongle for my old Garmin Vivofit
>> 1).
>>
>> The other potential work-around is to add a device reset at exit. Usually
>> this kind of issue is caused by device firmware bug (eg: USB data toggle
>> issues) and the hope is that the device reset can put the firmware to a
>> good
>> state.
>>
>>
>>
>> --
>> Xiaofan
>>
>>
>> _______________________________________________
>> pyusb-users mailing list
>> pyu...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>>
>
>
> --
> __________O___________
> _______-\<,____________
> _____(_)/_(_)___________
> _________________________
> Stuart_Lynne____<stu...@gm...
> >____604-518-1749(m)__604-461-7532(h)
>


-- 
__________O___________
_______-\<,____________
_____(_)/_(_)___________
_________________________
Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h)

Re: [pyusb-users] Garmin Ant+ dongle - _usb_reap_async - reaping request failed

[stuart l. <stu...@gm...>]

The device reset seems to help.

When properly exited it went about eight restarts correctly.

Interrupted (^C) exit I think misses the device reset in some cases (I can
fix that) and eventually it got to the FUBAR state.

Once in that state opening and closing with reset does not fix it. Physical
replug necessary.

I'll clean up the exception handling so that breaking to exit goes through
the proper closing sequence and see if that helps.


Thanks!


On Sat, Apr 23, 2022 at 8:45 PM Xiaofan Chen <xia...@gm...> wrote:

> On Sun, Apr 24, 2022 at 8:43 AM stuart lynne <stu...@gm...>
> wrote:
> >
> > I am seeing a consistent issue with Garmin Ant+ dongles under Windows
> with libusb0.
> >
> > They work the first time my application runs, but fail on the second
> attempt.
> >
> > I have verified the same behaviour across three Garmin Dongles. I have
> verified
> >  that the Cycplus Dongle works correctly.
> >
> > To maintain compatibility with the other applications running (Zwift and
> PerfPro
> > CT Smart) which rely on libusb0 I need to use that backend.
> >
> > Those applications do not have any problems with the Garmin (or Cycplus)
> > dongles, using them multiple times without a problem.
> >
> > Is it possible that I need to do something on exit that might cause this?
> >
> > Is there anything I can do to remediate this when seen?
> >
>
> Does it make a difference if you use the libusb-1.0 backend? This is not
> a solution but rather a troubleshooting step. You can keep your driver
> as it is, but switch to libusb-1.0 backend. You need to have libusbk.dll
> and libusb-1.0.dll in place to make that work.
>
> I understand that you may have to keep with the libusb0.sys based
> driver provided
> by Garmin (I used to have one such USB dongle for my old Garmin Vivofit 1).
>
> The other potential work-around is to add a device reset at exit. Usually
> this kind of issue is caused by device firmware bug (eg: USB data toggle
> issues) and the hope is that the device reset can put the firmware to a
> good
> state.
>
>
>
> --
> Xiaofan
>
>
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>


-- 
__________O___________
_______-\<,____________
_____(_)/_(_)___________
_________________________
Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h)

Re: [pyusb-users] Garmin Ant+ dongle - _usb_reap_async - reaping request failed

[Xiaofan C. <xia...@gm...>]

On Sun, Apr 24, 2022 at 8:43 AM stuart lynne <stu...@gm...> wrote:
>
> I am seeing a consistent issue with Garmin Ant+ dongles under Windows with libusb0.
>
> They work the first time my application runs, but fail on the second attempt.
>
> I have verified the same behaviour across three Garmin Dongles. I have verified
>  that the Cycplus Dongle works correctly.
>
> To maintain compatibility with the other applications running (Zwift and PerfPro
> CT Smart) which rely on libusb0 I need to use that backend.
>
> Those applications do not have any problems with the Garmin (or Cycplus)
> dongles, using them multiple times without a problem.
>
> Is it possible that I need to do something on exit that might cause this?
>
> Is there anything I can do to remediate this when seen?
>

Does it make a difference if you use the libusb-1.0 backend? This is not
a solution but rather a troubleshooting step. You can keep your driver
as it is, but switch to libusb-1.0 backend. You need to have libusbk.dll
and libusb-1.0.dll in place to make that work.

I understand that you may have to keep with the libusb0.sys based
driver provided
by Garmin (I used to have one such USB dongle for my old Garmin Vivofit 1).

The other potential work-around is to add a device reset at exit. Usually
this kind of issue is caused by device firmware bug (eg: USB data toggle
issues) and the hope is that the device reset can put the firmware to a good
state.



-- 
Xiaofan

[pyusb-users] Garmin Ant+ dongle - _usb_reap_async - reaping request failed

[stuart l. <stu...@gm...>]

I am seeing a consistent issue with Garmin Ant+ dongles under Windows with
libusb0.

They work the first time my application runs, but fail on the second
attempt.

I have verified the same behaviour across three Garmin Dongles. I have
verified that the Cycplus Dongle works correctly.

To maintain compatibility with the other applications running (Zwift and
PerfPro CT Smart) which rely on libusb0 I need to use that backend.

Those applications do not have any problems with the Garmin (or Cycplus)
dongles, using them multiple times without a problem.

Is it possible that I need to do something on exit that might cause this?

Is there anything I can do to remediate this when seen?

Thanks!

2022-04-23 17:13:40,318 INFO:usb.core:find(): using backend
> "usb.backend.libusb0"
> 2022-04-23 17:13:40,318
> DEBUG:usb.backend.libusb0:_LibUSB.enumerate_devices()
> 2022-04-23 17:13:40,318
> DEBUG:usb.backend.libusb0:_LibUSB.get_device_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>)
> is_ant_device: dev: 0x1009
> @
>
>
> /reap
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_interface_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0, 0, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_configuration_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_endpoint_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0, 0, 0, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_interface_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0, 0, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_configuration_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_endpoint_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 1, 0, 0, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_interface_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0, 0, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.get_configuration_descriptor(<usb.backend.libusb0._usb_device
> object at 0x000002073629D940>, 0)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.bulk_write(2229757821776, 1, 0,
> array('B', [164, 1, 74, 48, 223]), 2000)
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.bulk_read(2229757821776, 129, 0,
> array('B', [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]), 4000)
>
> 2022-04-23 17:13:41,334
> DEBUG:usb.backend.libusb0:_LibUSB.bulk_write(2229757821776, 1, 0,
> array('B', [164, 1, 74, 48, 223]), 2000)
> USBLoop.run: USBError e.errno: None e.backend_error_code: -5
> USBLoop.run: USBError e: [USBError(None, b'libusb0-dll:err
> [_usb_reap_async] reaping request failed, win error: A device attached to
> the system is not functioning.\r\n\n')]
>
>

-- 
__________O___________
_______-\<,____________
_____(_)/_(_)___________
_________________________
Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h)

Re: [pyusb-users] Preventing multiple opens on a USB Device

[stuart l. <stu...@gm...>]

Thanks for your suggestions.

I'm also seeing some strange differences in how the two types of Ant+
dongles I have (current models from Garmin and Cycplus.)

The Cycplus for example does not appear to support a get_interface control
request. That prevented the libant library from using it. They were using
that call to fetch the alternate setting which will always be zero, so just
removing the extra request is OK.

The Garmin has some trouble with closing and re-opening in Linux with
libusb1 the backend. Typically will not function correctly on the first
open. Second open works. Then in some cases, subsequent use fails entirely
until the device is replugged.

I'm just starting to test them in Windows, and both are reacting slightly
differently there. But (currently) that is defaulting to libusb0, so I need
to figure out how to switch that. And then make sure I can push that out in
the app as built with pyinstaller.




On Sat, Feb 5, 2022 at 2:05 AM Xiaofan Chen <xia...@gm...> wrote:

> On Sat, Feb 5, 2022 at 10:26 AM stuart lynne <stu...@gm...>
> wrote:
> >
> > Most people are using a generic libusb-win32 driver for Ant+ dongles.
> > I have two types, Garmin and Cycplus, and both show up as Dynastream
> > as the manufacturer, but they do have minor differences, so even if the
> same
> >  chip from Dynastream, different configuration possibly.
> >
> > In driver details, that shows up with the actual driver as libusb0.dll.
>
> In that case, you will probably want to use pyusb libusb-0.1 backend
> as the driver (libusb0.sys) and  libusb0.dll are already in place. You
> do not need to ship libusb-1.0.dll if you use the libusb-0.1 backend.
>
> I remember Garmin shipped a pretty old version of libusb0.sys and
> libusb0.dll but hopefully it does not cause issues for you. I may be
> wrong though.
>
> libusb-win32 official release is also very old -- 1.2.6.0 version
> was released in 2012.
>
>
>
> --
> Xiaofan
>
>
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>


-- 
__________O___________
_______-\<,____________
_____(_)/_(_)___________
_________________________
Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h)

Re: [pyusb-users] Preventing multiple opens on a USB Device

[Xiaofan C. <xia...@gm...>]

On Sat, Feb 5, 2022 at 10:26 AM stuart lynne <stu...@gm...> wrote:
>
> Most people are using a generic libusb-win32 driver for Ant+ dongles.
> I have two types, Garmin and Cycplus, and both show up as Dynastream
> as the manufacturer, but they do have minor differences, so even if the same
>  chip from Dynastream, different configuration possibly.
>
> In driver details, that shows up with the actual driver as libusb0.dll.

In that case, you will probably want to use pyusb libusb-0.1 backend
as the driver (libusb0.sys) and  libusb0.dll are already in place. You
do not need to ship libusb-1.0.dll if you use the libusb-0.1 backend.

I remember Garmin shipped a pretty old version of libusb0.sys and
libusb0.dll but hopefully it does not cause issues for you. I may be
wrong though.

libusb-win32 official release is also very old -- 1.2.6.0 version
was released in 2012.



--
Xiaofan

Re: [pyusb-users] Preventing multiple opens on a USB Device

[stuart l. <stu...@gm...>]

Most people are using a generic libusb-win32 driver for Ant+ dongles. I
have two types, Garmin and Cycplus, and both show up as Dynastream as the
manufacturer, but they do have minor differences, so even if the same chip
from Dynastream, different configuration possibly.

In driver details, that shows up with the actual driver as libusb0.dll.

On Fri, Feb 4, 2022 at 2:14 AM Xiaofan Chen <xia...@gm...> wrote:

> On Fri, Feb 4, 2022 at 4:40 PM stuart lynne <stu...@gm...>
> wrote:
> >
> >
>
> Windows can be a big problem.
>
> What is the driver used with your ANT+ dongle? I remember my old
> Garmin ANT dongle (for use with the Garmin VivoFit 1 and 3) uses
> libusb-win32 driver. We have improved the support of libusb0.sys
> in libusb 1.0.25 release but there may still be some problems.
> Ref:
> https://github.com/libusb/libusb/wiki/FAQ#How_to_use_libusb_under_Windows
>
> Good thing is that pyusb does support libusb-0.1 backend even though
> libusb-1.0 backend is recommended.
>
> If your ANT+ dongle uses WinUSB driver, you have a problem as
> WinUSB does not support multiple concurrent applications.
> Ref: https://github.com/libusb/libusb/wiki/Windows#Known_Restrictions
>
> There is a workaround -- you have to write a daemon (eg: Windows service)
> to deal with them and then multiple applications can call the daemon to
> work
> with the ANT+ device.
>
> For macOS, as long as your ANT+ dongle is not claimed exclusively by
> existing kernel drivers, hopefully it will be fine.
>
> Read the libusb caveats as well for things to take note under all
> operating systems.
> https://libusb.sourceforge.io/api-1.0/libusb_caveats.html
>
> --
> Xiaofan
>
>
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>


-- 
__________O___________
_______-\<,____________
_____(_)/_(_)___________
_________________________
Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h)

Re: [pyusb-users] Preventing multiple opens on a USB Device

[Xiaofan C. <xia...@gm...>]

On Fri, Feb 4, 2022 at 4:40 PM stuart lynne <stu...@gm...> wrote:
>
> Yes, I'm looking at claim_interface/release_interface. It seems to take
> a bit of a song and dance to get it to work.
>
> And I'm definitely seeing different results between Linux and Windows.
> I can live with that, platform.system() can be used to differentiate with
> different solutions.
>
> A bigger issue (especially for Windows which is the main target and
> possibly macOS) will be playing nice with existing commercial programs.
> Can't interfere with them, just need to find an available Ant+ dongle without
> causing problems and then claiming it so other programs won't attempt to use it.
>
> Under Linux it appears that set_configuration() will fail if another process has
> done a claim_interface(). It doesn't look like claim_interface() can fail, which
> possibly means two processes could get past the set_configuration() test and
> then both attempt to do a claim_interface().

Windows can be a big problem.

What is the driver used with your ANT+ dongle? I remember my old
Garmin ANT dongle (for use with the Garmin VivoFit 1 and 3) uses
libusb-win32 driver. We have improved the support of libusb0.sys
in libusb 1.0.25 release but there may still be some problems.
Ref: https://github.com/libusb/libusb/wiki/FAQ#How_to_use_libusb_under_Windows

Good thing is that pyusb does support libusb-0.1 backend even though
libusb-1.0 backend is recommended.

If your ANT+ dongle uses WinUSB driver, you have a problem as
WinUSB does not support multiple concurrent applications.
Ref: https://github.com/libusb/libusb/wiki/Windows#Known_Restrictions

There is a workaround -- you have to write a daemon (eg: Windows service)
to deal with them and then multiple applications can call the daemon to work
with the ANT+ device.

For macOS, as long as your ANT+ dongle is not claimed exclusively by
existing kernel drivers, hopefully it will be fine.

Read the libusb caveats as well for things to take note under all
operating systems.
https://libusb.sourceforge.io/api-1.0/libusb_caveats.html

-- 
Xiaofan

Re: [pyusb-users] Preventing multiple opens on a USB Device

[stuart l. <stu...@gm...>]

Yes, I'm looking at claim_interface/release_interface. It seems to take a
bit of a song and dance to get it to work.

And I'm definitely seeing different results between Linux and Windows. I
can live with that, platform.system() can be used to differentiate with
different solutions.

A bigger issue (especially for Windows which is the main target and
possibly macOS) will be playing nice with existing commercial programs.
Can't interfere with them, just need to find an available Ant+ dongle
without causing problems and then claiming it so other programs won't
attempt to use it.

Under Linux it appears that set_configuration() will fail if another
process has done a claim_interface(). It doesn't look like
claim_interface() can fail, which possibly means two processes could get
past the set_configuration() test and then both attempt to do a
claim_interface().


On Thu, Feb 3, 2022 at 4:22 PM Jonas Malaco via pyusb-users <
pyu...@li...> wrote:

> On Thu, Feb 3, 2022 at 7:25 PM stuart lynne <stu...@gm...>
> wrote:
> >
> > I am working with libant and pyusb to support Ant+ devices.
> >
> > The issue I am trying to fix is preventing access to a device that is
> already open by another process. There may (usually will) be multiple Ant+
> devices plugged in, and one or more may be in active use by another program.
> >
> > I need to find an unused device and then open that, without interfering
> with the use of the other open devices.
> >
> > Currently, I'm testing on Linux, but this will be deployed on Windows
> and macOS as well.
> >
> > There doesn't appear to be anything to prevent multiple access, and at
> least initial testing with two processes both using pyusb shows them
> interfering with each other as they open, close while attempting to access
> the Ant device.
>
> Hi Stuart,
>
> As far as I know there is no cross-platform way to unilaterally
> prevent other processes from accessing a USB device.
>
> However, careful use of [libusb_]claim_interface() by both processes
> can prevent one from trampling over the other: claiming the interface
> should fail if another process has already done it, so each process
> can use it as a pseudo-lock for the device it's working on.
>
> Note that I'm talking about *explicitly* claiming the interface – with
> usb.tools.claim_interface() – and not the automatic claiming/releasing
> that PyUSB does by default.
>
> Jonas
>
> >
> > Suggestions would be appreciated.
> >
> > Thanks!
> >
> >
> > --
> > __________O___________
> > _______-\<,____________
> > _____(_)/_(_)___________
> > _________________________
> > Stuart_Lynne____<stu...@gm...
> >____604-518-1749(m)__604-461-7532(h)
> > _______________________________________________
> > pyusb-users mailing list
> > pyu...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyusb-users
>
>
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>


-- 
__________O___________
_______-\<,____________
_____(_)/_(_)___________
_________________________
Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h)

Re: [pyusb-users] Preventing multiple opens on a USB Device

[Jonas M. <jo...@pr...>]

On Thu, Feb 3, 2022 at 7:25 PM stuart lynne <stu...@gm...> wrote:
>
> I am working with libant and pyusb to support Ant+ devices.
>
> The issue I am trying to fix is preventing access to a device that is already open by another process. There may (usually will) be multiple Ant+ devices plugged in, and one or more may be in active use by another program.
>
> I need to find an unused device and then open that, without interfering with the use of the other open devices.
>
> Currently, I'm testing on Linux, but this will be deployed on Windows and macOS as well.
>
> There doesn't appear to be anything to prevent multiple access, and at least initial testing with two processes both using pyusb shows them interfering with each other as they open, close while attempting to access the Ant device.

Hi Stuart,

As far as I know there is no cross-platform way to unilaterally
prevent other processes from accessing a USB device.

However, careful use of [libusb_]claim_interface() by both processes
can prevent one from trampling over the other: claiming the interface
should fail if another process has already done it, so each process
can use it as a pseudo-lock for the device it's working on.

Note that I'm talking about *explicitly* claiming the interface – with
usb.tools.claim_interface() – and not the automatic claiming/releasing
that PyUSB does by default.

Jonas

>
> Suggestions would be appreciated.
>
> Thanks!
>
>
> --
> __________O___________
> _______-\<,____________
> _____(_)/_(_)___________
> _________________________
> Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h)
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users

[pyusb-users] Preventing multiple opens on a USB Device

[stuart l. <stu...@gm...>]

I am working with libant and pyusb to support Ant+ devices.

The issue I am trying to fix is preventing access to a device that is
already open by another process. There may (usually will) be multiple Ant+
devices plugged in, and one or more may be in active use by another program.

I need to find an unused device and then open that, without interfering
with the use of the other open devices.

Currently, I'm testing on Linux, but this will be deployed on Windows and
macOS as well.

There doesn't appear to be anything to prevent multiple access, and at
least initial testing with two processes both using pyusb shows them
interfering with each other as they open, close while attempting to access
the Ant device.

Suggestions would be appreciated.

Thanks!


-- 
__________O___________
_______-\<,____________
_____(_)/_(_)___________
_________________________
Stuart_Lynne____<stu...@gm...>____604-518-1749(m)__604-461-7532(h)

[pyusb-users] No Backend ARM Mac, how to specify libusb location?

[Vincent D. <pyu...@vd...>]

I have installed libusb using brew.
the install location is
/opt/homebrew/Cellar/libusb/1.0.24/lib/libusb-1.0.0.dylib

>From this post, I gather I can specify the location of libusb but I am
failing to do so.
https://github.com/pyusb/pyusb/issues/360#issuecomment-812802678

Looks like this is a known issue but I was not able to figure out any of
the solutions.
f = find(backend=???, find_all=True)

Re: [pyusb-users] cannot send feature report request.

[Xiaofan C. <xia...@gm...>]

On Mon, Oct 18, 2021 at 2:03 PM fishx2000--- via pyusb-users
<pyu...@li...> wrote:
>
> Hi,
>
> I can send input/output report request via HID interface, using the following command:
>     dev.ctrl_transfer(0xA1, 0x01, 0x0100|reportId, hidItfaceIdx, reportLen)
>     dev.ctrl_transfer(0x21, 0x09, 0x0200|report[0], hidItfaceIdx, report)
>
> but failed to send feature report request:
>     dev.ctrl_transfer(0xA1, 0x01, 0x0300|reportId, hidItfaceIdx, reportLen)
>     dev.ctrl_transfer(0x21, 0x09, 0x0300|report[0], hidItfaceIdx, report)
>
>
> I tried the above command in MS-Window, using libusb as backend.
> Is there any restrictions on this usage?

If it is for HID device, you may want to use HIDAPI and cython-hidapi.

There are quite some limitations for the libusb/pyusb with HID devices.

But if you really want to try out pyusb with native HID device driver, you
can try the latest libusb-1.0 git. It has one critical fix for the
feature report.
https://github.com/libusb/libusb/pull/986




-- 
Xiaofan

[pyusb-users] cannot send feature report request.

[<fis...@ya...>]

Hi,
I can send input/output report request via HID interface, using the following command:    dev.ctrl_transfer(0xA1, 0x01, 0x0100|reportId, hidItfaceIdx, reportLen)
    dev.ctrl_transfer(0x21, 0x09, 0x0200|report[0], hidItfaceIdx, report)

but failed to send feature report request:    dev.ctrl_transfer(0xA1, 0x01, 0x0300|reportId, hidItfaceIdx, reportLen)
    dev.ctrl_transfer(0x21, 0x09, 0x0300|report[0], hidItfaceIdx, report)


I tried the above command in MS-Window, using libusb as backend.Is there any restrictions on this usage?
Thanks.
 

Re: [pyusb-users] cannot access HID interface on MacOS.

[Xiaofan C. <xia...@gm...>]

On Tue, Sep 7, 2021 at 5:41 PM fishx2000--- via pyusb-users
<pyu...@li...> wrote:
>
> Hi..
>
> When running on MacOS using pyusb, I failed to read/write HID interface.
>
> error message is as follows:
> 'Access denies(insufficient permissions)' error.
>
> and libusb provides more information:
> libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access
>
> after doing some search, it seems there is no way to avoid this issue on MacOS...
> Is there any suggestions about this ?
>

Please use HIDAPI and Cython-hidapi. That is the right library and
Python binding
to use for HID devices (with different transport: USB, Bluetooth, or
even I2C, SPI, etc).
https://github.com/libusb/libusb/wiki/FAQ#Does_libusb_support_USB_HID_devices

-- 
Xiaofan

[pyusb-users] cannot access HID interface on MacOS.

[<fis...@ya...>]

Hi..
When running on MacOS using pyusb, I failed to read/write HID interface.
error message is as follows:'Access denies(insufficient permissions)' error.
and libusb provides more information:libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access
after doing some search, it seems there is no way to avoid this issue on MacOS...Is there any suggestions about this ?
Thanks

Re: [pyusb-users] Reading data from 3DConnexion SpaceMouse Wireless

[Bruno R. <dc...@gm...>]

Thank you both for your valuable input.

I didn't knew about hidapi. I tried it out and managed to make it work,
thanks!

Best Regards

On Mon, May 10, 2021 at 4:26 PM Jonas Malaco via pyusb-users <
pyu...@li...> wrote:

> On Mon, May 10, 2021 at 02:45:56PM +0100, Bruno Rocha wrote:
> > Hello,
> >
> > I'm developping a solution that needs to read raw data from 3DConnexion
> > SpaceMouse Wireless and then send it via sockets to another application.
> I
> > was able to do it with the SpaceMouse cabled but I've been unable to do
> it
> > via the wireless receiver.
> >
> > I seeked help on 3D Connexion forums but everything I managed to get was
> > the following info:
> >
> > The Universal Receiver (UR) can pair up to five wireless devices, each
> on a
> > separate USB interface. Within each interface, you will find a set of
> > top-level collections (as per the HID specification; these are also known
> > as "application collections"). There's one top-level collection if the
> > interface has no pairing, two if the pairing is for a SpaceMouse and
> three
> > for a CadMouse type. You're interested in the second case. The two
> > top-level collections (all in the "generic" desktop usage page) consist
> of
> > a "multi-axis controller" usage collection (ID 0x08) and a
> "vendor-defined"
> > collection. You want to use the former.
> >
> >  Meanwhile, I've managed to read the data with pywinusb. Pywinusb detects
> > 6/7 devices and one (only one) of them is able to read the data. But I
> > would like to do it with pyusb as I'd also want to be linux supported.
> Any
> > help will be very appreciated, thank you`
>
> Since those are HIDs, and apparently also (at least partially) compliant
> with that spec, I suggest that you take a look at hidapi before trying
> to recreate it with PyUSB.
>
> https://github.com/libusb/hidapi/
> https://github.com/trezor/cython-hidapi
>
> >
> > Best Regards
>
>
> > _______________________________________________
> > pyusb-users mailing list
> > pyu...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyusb-users
>
>
>
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>

Re: [pyusb-users] Reading data from 3DConnexion SpaceMouse Wireless

[Xiaofan C. <xia...@gm...>]

On Mon, May 10, 2021 at 11:26 PM Jonas Malaco via pyusb-users
<pyu...@li...> wrote:
>
> On Mon, May 10, 2021 at 02:45:56PM +0100, Bruno Rocha wrote:
> > Hello,
> >
> > I'm developping a solution that needs to read raw data from 3DConnexion
> > SpaceMouse Wireless and then send it via sockets to another application. I
> > was able to do it with the SpaceMouse cabled but I've been unable to do it
> > via the wireless receiver.
> >
> > I seeked help on 3D Connexion forums but everything I managed to get was
> > the following info:
> >
> > The Universal Receiver (UR) can pair up to five wireless devices, each on a
> > separate USB interface. Within each interface, you will find a set of
> > top-level collections (as per the HID specification; these are also known
> > as "application collections"). There's one top-level collection if the
> > interface has no pairing, two if the pairing is for a SpaceMouse and three
> > for a CadMouse type. You're interested in the second case. The two
> > top-level collections (all in the "generic" desktop usage page) consist of
> > a "multi-axis controller" usage collection (ID 0x08) and a "vendor-defined"
> > collection. You want to use the former.
> >
> >  Meanwhile, I've managed to read the data with pywinusb. Pywinusb detects
> > 6/7 devices and one (only one) of them is able to read the data. But I
> > would like to do it with pyusb as I'd also want to be linux supported. Any
> > help will be very appreciated, thank you`
>
> Since those are HIDs, and apparently also (at least partially) compliant
> with that spec, I suggest that you take a look at hidapi before trying
> to recreate it with PyUSB.
>
> https://github.com/libusb/hidapi/
> https://github.com/trezor/cython-hidapi

There is an existing project already. It should work under Windows and Linux.
https://github.com/smartavionics/RawMouse

It already uses cython-hidapi.

It may have some issues with MacOS now.
https://github.com/libusb/hidapi/issues/212

-- 
Xiaofan