You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(3) |
Nov
(4) |
Dec
|
2008 |
Jan
(1) |
Feb
(5) |
Mar
(2) |
Apr
|
May
(8) |
Jun
(4) |
Jul
|
Aug
|
Sep
(11) |
Oct
|
Nov
|
Dec
(20) |
2009 |
Jan
(16) |
Feb
(7) |
Mar
(9) |
Apr
(4) |
May
(6) |
Jun
(17) |
Jul
(3) |
Aug
(4) |
Sep
(5) |
Oct
(10) |
Nov
(16) |
Dec
|
2010 |
Jan
(22) |
Feb
(18) |
Mar
(9) |
Apr
(102) |
May
(29) |
Jun
(40) |
Jul
(80) |
Aug
(21) |
Sep
(47) |
Oct
(13) |
Nov
(19) |
Dec
(45) |
2011 |
Jan
(82) |
Feb
(20) |
Mar
(47) |
Apr
(25) |
May
(18) |
Jun
(24) |
Jul
(24) |
Aug
(47) |
Sep
(23) |
Oct
(22) |
Nov
(69) |
Dec
(20) |
2012 |
Jan
(56) |
Feb
(42) |
Mar
(43) |
Apr
(27) |
May
(18) |
Jun
(11) |
Jul
(61) |
Aug
(19) |
Sep
(13) |
Oct
(49) |
Nov
(32) |
Dec
(37) |
2013 |
Jan
(46) |
Feb
(14) |
Mar
(13) |
Apr
(20) |
May
(20) |
Jun
(3) |
Jul
(19) |
Aug
(7) |
Sep
(4) |
Oct
(33) |
Nov
(7) |
Dec
(15) |
2014 |
Jan
(5) |
Feb
(21) |
Mar
(3) |
Apr
(3) |
May
(30) |
Jun
(1) |
Jul
(30) |
Aug
(2) |
Sep
(22) |
Oct
(14) |
Nov
(22) |
Dec
(6) |
2015 |
Jan
(7) |
Feb
(4) |
Mar
(16) |
Apr
(9) |
May
(17) |
Jun
(28) |
Jul
(3) |
Aug
(18) |
Sep
(3) |
Oct
|
Nov
(6) |
Dec
(3) |
2016 |
Jan
(15) |
Feb
(18) |
Mar
(12) |
Apr
(14) |
May
(15) |
Jun
(3) |
Jul
(3) |
Aug
(42) |
Sep
(24) |
Oct
(6) |
Nov
(5) |
Dec
(6) |
2017 |
Jan
(6) |
Feb
(2) |
Mar
(12) |
Apr
|
May
(1) |
Jun
(3) |
Jul
(2) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(7) |
2018 |
Jan
|
Feb
(9) |
Mar
(7) |
Apr
|
May
(10) |
Jun
(20) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(20) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(9) |
Dec
|
2020 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(5) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(8) |
Dec
(2) |
2021 |
Jan
(16) |
Feb
(1) |
Mar
|
Apr
(9) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(1) |
2022 |
Jan
|
Feb
(7) |
Mar
|
Apr
(4) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jonas M. <jo...@pr...> - 2024-06-20 04:19:24
|
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 |
From: Michael C. <mca...@ic...> - 2024-06-20 01:47:10
|
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 |
From: chris c. <cl...@gm...> - 2024-05-07 13:59:52
|
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 > |
From: Charles H. <cha...@sl...> - 2024-05-07 09:41:46
|
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 |
From: ConDeS G. & C. K. <j.s...@co...> - 2024-04-07 15:53:49
|
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() |
From: Chaima K. <cha...@ka...> - 2023-10-10 08:27:05
|
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 |
From: George K. | E. <geo...@ec...> - 2022-06-06 14:12:57
|
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() |
From: stuart l. <stu...@gm...> - 2022-04-27 08:50:21
|
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) |
From: stuart l. <stu...@gm...> - 2022-04-24 06:31:09
|
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) |
From: Xiaofan C. <xia...@gm...> - 2022-04-24 03:45:06
|
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 |
From: stuart l. <stu...@gm...> - 2022-04-24 00:42:36
|
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) |
From: stuart l. <stu...@gm...> - 2022-02-05 19:14:43
|
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) |
From: Xiaofan C. <xia...@gm...> - 2022-02-05 10:05:03
|
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 |
From: stuart l. <stu...@gm...> - 2022-02-05 02:25:59
|
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) |
From: Xiaofan C. <xia...@gm...> - 2022-02-04 10:14:34
|
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 |
From: stuart l. <stu...@gm...> - 2022-02-04 08:40:24
|
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) |
From: Jonas M. <jo...@pr...> - 2022-02-04 00:22:15
|
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 |
From: stuart l. <stu...@gm...> - 2022-02-03 22:25:01
|
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) |
From: Vincent D. <pyu...@vd...> - 2021-12-06 17:37:37
|
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) |
From: Xiaofan C. <xia...@gm...> - 2021-10-19 02:20:14
|
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 |
From: <fis...@ya...> - 2021-10-18 06:02:43
|
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. |
From: Xiaofan C. <xia...@gm...> - 2021-09-07 09:54:40
|
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 |
From: <fis...@ya...> - 2021-09-07 09:41:24
|
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 |
From: Bruno R. <dc...@gm...> - 2021-05-14 11:58:43
|
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 > |
From: Xiaofan C. <xia...@gm...> - 2021-05-11 04:00:37
|
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 |