MacOS Monterey 12.0, libuvc, libusb: info [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access #972
Comments
|
That is just a info message and not a problem. |
|
Do you have real problem here other than the message? |
|
Reference: we have downgraded the message from warning to info as it is normal. |
My program use the libuvc (https://github.com/libuvc/libuvc) to control the webcam. The program can work on macOS 10.x and macOS 11.x. It doesn't work on macOS 12.0 that is Apple's new system released recently. The cause is that the function "uvc_open" failed. Function "uvc_open" works as follows: uvc_open Maybe this problem is caused by some changes in Apple’s new system, i'm not sure. And I don't know how to solve this problem, so come here for help. |
|
Can you try the latest libusb git? And post the debug log again. |
I updated the latest code from the libusb yesterday and got the above log. The log starts with [device.c:322] begin uvc_open |
|
I see. Thanks. Maybe there is a change on the Apple side. Anyway, this is a beta release. You may want to try again when there is a formal release. Right now please post the debug log for macOS 11.x as well since you say it works. By comparing the logs, you may be able to identify the differences. It could be that there is a kernel driver in the 12.x beta which opens the device for exclusive access. One thing you can try is to see if you can use the latest addition to the macOS side, the kernel driver detaching function, but you need to have the right entitlement. I have not tried this myself. More details are in pull request #911 |
On macOS 11.4, the log as follows: |
|
Main difference: macOS 12 beta: claiming interface failed. So there is a kernel driver (or maybe system application) which opened the device for exclusive access. You may have to contact Apple for help. |
|
Think I know how I broke it. Fixing now.... |
|
Opps. Wrong bug :). |
It works when running with sudo. Thanks. I also found another issue: when calling "uvc_close" in libuvc, the following line of code in function "libusb_free_transfer" oftern lead to program crash. |
|
Thanks for the updates. Then there is no issue with libusb already. I will close this issue. The proper way (without using sudo) is for the developer to get the right entitlement as per the following discussion: #911
|
You may want to report the issue to libuvc, looks like a bug in libuvc. But if you think it is an issue with libusb, please create a new issue and post the debug log. Thanks. |
|
Non-VM apps on the App Store have no way to get the 'com.apple.vm.device-access' or run as root by default. |
Thanks for the updates. As for the first sentence, I am not so sure if it is correct or not. I think it is not correct to say "non-VM apps". |
|
Ha, me either. Quote from the mail: |
|
Do not worry too much about the vm in the name. https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_vm_device-access |
|
Updates on Oct 2021: with the merging of pull request #911, support for detaching kernel drivers with authorization has been added. This will be included in the upcoming 1.0.25 release. Take note the underlying macOS capture APIs only work on the whole device and not on individual interfaces. So this will force all the kernel extensions (drivers) bound to all the interfaces of a USB Composite devices to be released (Issue #920). You will need to get the entitlement from Apple Developer support, create a provisioning profile with that entitlement, and build your app with that profile. Please take note that command line apps cannot use provisioning profiles and therefore cannot hold this entitlement. |
mcuee
changed the title
|
Please refer to the following discussion as well for further info. Apple support seems to say that the 'com.apple.vm.device-access' is not the right entitlement for this purpose. |
|
Ref: libuvc/libuvc#188 If you are just testing, then you can use latest libusb git and sudo. The following is with my Mac Mini M1 running macOS 12.0.1. |
|
ANother libuvc issue is here: libuvc/libuvc#194 |
So this entitlement is not required for USBInterfaceOpen, right? Can I say this might be an issue of macOS 12 itself? My app must not be used with root. |
No, it is required as of now. But you can always file a bug with Apple to say the device and app used to work under older version of macOS but now it does not work with macOS Monterey 12.0. |
|
A good summary here:
|
|
I have updated the wiki here. And I will close this issue for now. Please continue in #1014 |
|
Re-open this one so that future issues can be linked here. |
|
Related issue from libuvc github. |
|
I asked this problem to the Apple, and they said: Based on your request Apple Developer Technical Support believes that your question is answered by the Core Media I/O documentation page linked below: Overriding the default USB video class extension: Did someone try this? |
This should work. Basically it is the same as previously used method -- codeless kext, now it is codeless DriverKit extension. You do need to have the valid developer signature in order to load the extension.
The main drawback compared to previous situation is that it will no longer function as a UVC camera and you can only use libuvc. It may be okay for certain use cases though. If possible, I think it is better not to use libusb/libuvc in this case. It was the same situation last time with HID device. Later HIDAPI project was launched to use native HID API under Mac OS X (now macOS). Maybe the application should use native macOS API now. |
|
It's quite a while but found it via google. For me it was "libusb.kext" installed by G-Flash. kextunload it solved it |
Hmm, that is strange to know. I do not think this is the cause for majority of the users. I believe it is the Apple |
|
Edit: this is a false alarm. Using git HEAD (same for older release version). |
My team has successfully used it - that is the way to go.
Not exactly: (even codeless) kext is loaded by the kernel and running in the kernel space. It is deprecated since macOS 12. and it is practically impossible to make/release a product with thiks kind of kext - Apple will not allow it. |
|
So there is a solution but it is not easy for most users. Anyway, this is not a libusb issue now. I will close this one. |
When using the function "uvc_open" in libuvc on MacOS Monterey 12.0, the following exception will be thrown:
libusb: info [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access.
Does anyone know how to solve this problem？
The complete log is as follows：
The text was updated successfully, but these errors were encountered: