hid_device_info->interface_number zero on macOS 13.3 #531
Labels
macOS
Related to macOS backend
Comments
|
I think this is a real issue. Last time I can get proper interface number on my Mac Mini M1. With the latest macOS Ventura 13.3.1 on my Mac Mini M1, interface number becomes 0 for the Logitech USB receiver (046d:c52b). |
|
From @dingsijie-nreal
|
|
@Youw @dingsijie-nreal @pengxianheng-nreal Somehow libusb is able to print the interface number. |
|
PR #530 is a workaround and it seems to work. However, I believe there is a better solution. |
|
Just a quick test using my mod hidapi-libusb under macOS. |
|
I am thinking that libusb codes may be of some reference to sort out the issue here.[ |
Yeah, libusb and HIDAPI using different API/subsystems to get the information about USB device. BTW: I'm still using 12.6 so I'm unable to debug/fix it localy as of yet... |
|
Yeah, I've noticed that libusb is able to fetch the correct interface number, but as @Youw has pointed out, hidapi doesn't use libusb on mac. Our app code currently uses hidapi API because it is easier and nicer to use than libusb. Maybe it is a real bug on macOS 13.3? |
|
The USB receiver works fine (together with the mouse and keyboard). In fact yesterday I tried hidpp macOS fork and it works fine. It is probably just the paticual macOS API is broken. Sometimes Apple will fix it in the future updates. Sometimes it may take time. Let's see if you will get some reply here. Better way is to submit a bug report to Apple. |
@dingsijie-nreal You can see from the following libusb issue that Apple fixed the issue pretty fast in the paticular case. But sometimes it takes time. |
|
feedback posted. https://feedbackassistant.apple.com/feedback/12125162 |
|
Is there some kind of visibility configuration for the feedback? I'm unable to open/see it. |
Same here. Probably it is not visible for unconfirmed issue. |
|
Only apple can see it according to: |
|
After digging deeper into the problem in the context of #534 - I'm starting to think that this is not a bug in macOS. But it is still a clear statement that |
|
@dingsijie-nreal see if you (or you colleague?) could check the #534 fix. |
|
PR #534 works fine for me. |
Closed
benma
added a commit
to benma/bitbox02-firmware
that referenced
this issue
May 29, 2023
Fixing trezor/cython-hidapi#151, which includes the fix libusb/hidapi#531, which fixes a bug where on macOS, the interface number of all hid interfaces would be 0. This lead to one BitBox02 multi being listed twice instead of once (as it exposes a second interface for U2F).
benma
added a commit
to benma/bitbox02-firmware
that referenced
this issue
May 29, 2023
Fixing trezor/cython-hidapi#151, which includes the fix libusb/hidapi#531, which fixes a bug where on macOS, the interface number of all hid interfaces would be 0. This lead to one BitBox02 multi being listed twice instead of once (as it exposes a second interface for U2F).
benma
added a commit
to benma/HWI
that referenced
this issue
May 30, 2023
6.2.0 was released to put a minimum requirement on hidapi 0.14.0, which includes the fix for this issue: libusb/hidapi#531 That bug caused hidapi on macOS 13.3 to report 0 as the interface number for all hid devices, which led to the bitbox02 being listed twice instead of once. This breaks some downstream integrations like Sparrow: sparrowwallet/sparrow#972
SomberNight
pushed a commit
to spesmilo/electrum
that referenced
this issue
May 30, 2023
6.2.0 was released to put a minimum requirement on hidapi 0.14.0, which includes the fix for this issue: libusb/hidapi#531 That bug caused hidapi on macOS 13.3 to report 0 as the interface number for all hid devices, which led to the bitbox02 multi edition being listed twice instead of once - once for the main HW wallet interface and once erroneously For the U2F interface (which should not be listed).
benma
added a commit
to benma/bitbox-wallet-app
that referenced
this issue
Mar 13, 2024
When building the BBApp on an updated XCode, the BitBox02 can't connect anymore on macOS, most likely due to libusb/hidapi#531. In BitBoxSwiss@bef0672 we switched from karalabe/hid to karalabe/usb, because karalabe/usb go-ethereum switched to it, and both libs cannot (or could not) be linked at once. Then in BitBoxSwiss@63dbb28 we abandoned karalabe/usb and made our own fork (https://github.com/digitalbitbox/usb/), because it seemed unmaintained/dead, and we needed important fixes to keep working. The original and the fork had a very old version of https://github.com/libusb/hidapi/. This fork, like the original, bundled a very old version of the hidapi C library. The above issue is with the connection on macOS is fixed by uprading it, but that is not super easy (hidapi requires libusb, and upgrading and compiling both in cgo is hard). Luckily just last week, go-ethereum switched back to karalabe/hid, and karalabe/hid finally got some love from the maintainers and they upgraded hidapi: karalabe/hid@80d2c4b Switching back to this the hid lib fixes the macOS issue and it means we can archive our own fork.
benma
added a commit
to benma/bitbox-wallet-app
that referenced
this issue
Mar 13, 2024
When building the BBApp on an updated XCode, the BitBox02 can't connect anymore on macOS, most likely due to libusb/hidapi#531. In BitBoxSwiss@bef0672 we switched from karalabe/hid to karalabe/usb, because karalabe/usb go-ethereum switched to it, and both libs cannot (or could not) be linked at once. Then in BitBoxSwiss@63dbb28 we abandoned karalabe/usb and made our own fork (https://github.com/digitalbitbox/usb/), because it seemed unmaintained/dead, and we needed important fixes to keep working. The original and the fork had a very old version of https://github.com/libusb/hidapi/. This fork, like the original, bundled a very old version of the hidapi C library. The above issue is with the connection on macOS is fixed by uprading it, but that is not super easy (hidapi requires libusb, and upgrading and compiling both in cgo is hard). Luckily just last week, go-ethereum switched back to karalabe/hid, and karalabe/hid finally got some love from the maintainers and they upgraded hidapi: karalabe/hid@80d2c4b Switching back to this the hid lib fixes the macOS issue and it means we can archive our own fork. The golangci linter `gomoddirectives` is disabled b/c it complains about `replace` directives in the go.mod file.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Discussed in #527
Originally posted by dingsijie-nreal April 11, 2023
I've noticed comment here: https://github.com/libusb/hidapi/blob/master/mac/hid.c#L543
The interesting thing is: macOS Monterey(12.6.3) works perfectly with my usb gadget, I got expected interface numbers.
the output of
test.cis shown below:But, after upgrading to macOS 13.3 the result changes to flowing:
My mission it to discriminate 3 different components on my USB gadget, and the interface number was the key that I rely on.
But with 0 interfaces numbers, I don't know how to do my job.
Any one get any ideas? Thanks a lot.
The text was updated successfully, but these errors were encountered: