Darwin: Can't claim device #158
Comments
|
Can you post the output of "lsusb -vvv" for this device (under Linux)?
Thanks.
|
|
|
Can you give the debug output with the call to libusb_set_configuration. That call should be fixing your issue but it must be made before you try to claim an interface. You can use libusb_get_configuration to detect if the device is configured as a configuration of 0 means the device is unconfigured. |
|
Also, it might be better for you to use libhid to access this device. Due to the way Microsoft handles USB a lot of devices erroneously use HID to avoid having to make a driver. |
@mcuee I hope the information I've posted is adequate. 👍
@hjelmn This is where debugging is difficult. I think I had already done this via https://github.com/tresf/qz-print/commit/30d5c2229b3cffaeba854263a9cb96f21d5ff98f#diff-66e51979c4dd4f537b85c3203a0f1568R55.
@hjelmn Well, that's the part I'm a bit unfamiliar with. Unlike the C or Python API, the High-Level Java API isn't clear how to do this, so I did it using the technique linked in the comment segment just above. I'd be happy to provide these logs.
@hjelmn Can you elaborate a bit on this recommendation? This recommendation seems a bit drastic given the amount of success we've had with |
|
The logs would be helpful to see if the device is actually getting configured. As for using hidapi. In OS X USB devices that use the HID device class are opened by IOUSBHID and can not be used by libusb in any meaningful way without writing a codeless kext. This means you will need to use hidapi to use the device. It sucks but this is a side-effect of the manufacturer abusing the HID device class to simplify their Windows support. Its hard to tell if this will happen in this case because the configuration specifies the device class. You should be able use libusb and hidapi side-by-side without any problems. |
I've done the
...
I'll have the logs later, and we may eventually bundle HID support if needed, but I'd first like to isolate the cause since this happens on 10.11 but not in 10.7 and not in Windows or Linux. |
|
Good luck on the signing rights. Apple is really strict on when they will allow KEXT signing. I couldn't get rights to sign a kext I wrote because I was not the one who created the hardware. Really irritating. |
Thanks for the heads up. The hardware manufacturer has been great to work with if I need to escalate, but getting approved for signing can be a tricky thing. I know some Mac sound drivers have to go through the kernel extension route to override device-claim settings too, so this shouldn't be off the mark in regards to what's allowed. If indeed the We write a JavaScript shim to talk to these devices through all major web browsers and we'd like to keep Mac on that list. Anyway... back on topic... for now, I'll proceed as if it will be approved and get those logs over. 👍 |
|
I believe this to be the relevant portion of the logs where I set the active configuration... Should I not be calling Edit: I've placed the full log here if interested: https://gist.github.com/tresf/c26c14d55aba91d0efcc [21.986931] [0000d903] libusb: debug [usbi_add_pollfd] add fd 63 events 1
[21.986940] [0000d903] libusb: debug [usbi_add_pollfd] add fd 65 events 1
[21.986986] [0000d903] libusb: debug [libusb_open] open 0.5
[21.987021] [0000d903] libusb: debug [usbi_add_pollfd] add fd 67 events 1
[21.987026] [0000d903] libusb: debug [darwin_open] device open for access
+ [21.987087] [0000d903] libusb: debug [libusb_set_configuration] configuration 1
+ [22.012154] [0000d903] libusb: debug [libusb_close]
[22.012190] [0000d903] libusb: debug [usbi_remove_pollfd] remove fd 67
[22.012235] [0000d903] libusb: debug [libusb_exit]
[22.012244] [0000d903] libusb: debug [libusb_get_next_timeout] no URBs, no timeout!
[22.012248] [0000d903] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[22.012252] [0000d903] libusb: debug [handle_events] poll() 2 fds with timeout in 0ms
[22.012269] [0000d903] libusb: debug [handle_events] poll() returned 0
[22.012274] [0000d903] libusb: debug [libusb_unref_device] destroy device 0.5
[22.012278] [0000d903] libusb: debug [libusb_unref_device] destroy device 0.4
[22.012282] [0000d903] libusb: debug [libusb_unref_device] destroy device 0.3
[22.012286] [0000d903] libusb: debug [libusb_unref_device] destroy device 0.2
[22.012290] [0000d903] libusb: debug [libusb_unref_device] destroy device 0.0
[22.012293] [0000d903] libusb: debug [libusb_unref_device] destroy device 0.1
[22.012297] [0000d903] libusb: debug [usbi_remove_pollfd] remove fd 63
[22.016617] [0000d903] libusb: debug [usbi_remove_pollfd] remove fd 65
[ERROR] 2016-02-29 20:55:55,832 @ qz.ws.PrintSocketClient:?
Problem processing message
javax.usb.UsbNotActiveException: Configuration is not active
at org.usb4java.javax.Interface.checkActive(Interface.java:74)
at org.usb4java.javax.Interface.claim(Interface.java:99)
at qz.communication.UsbIO.open(Unknown Source)
at qz.ws.PrintSocketClient.processMessage(Unknown Source)
at qz.ws.PrintSocketClient.onMessage(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.jetty.websocket.common.events.annotated.CallableMethod.call(CallableMethod.java:70)
at org.eclipse.jetty.websocket.common.events.annotated.OptionalSessionCallableMethod.call(OptionalSessionCallableMethod.java:68)
at org.eclipse.jetty.websocket.common.events.JettyAnnotatedEventDriver$2.run(JettyAnnotatedEventDriver.java:210)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745) |
|
Its hard to tell ordering from this log since the java error is not printed near any messages from the matching open call. Can you use gist to post the entire log? The call to |
I thought of that and edited/appended that right away. 😉 |
|
Weird. I do not see usb4java calling libusb_get_configuration anywhere. I would expect to see a message from that function: I wonder where checkActive is getting the configuration from? It might be caching it somewhere that isn't catching your change to set the configuration. |
|
Ref:
https://github.com/tresf/qz-print/blob/2.0/src/qz/utils/UsbUtilities.java
Firstly I do not see the code to setUsbConfiguration, only
getUsbConfiguration.
I will also recommend to forget about libusb for HID device under Mac OS X.
It is much easier to use HIDAPI instead. In fact, HIDAPI should be the
recommended tool to use for HID device if it is cross-platform projects.
Ref: http://www.signal11.us/oss/hidapi/
Ref:
https://github.com/libusb/libusb/wiki/FAQ#Does_libusb_support_HID_devices
|
@mcuee the API doesn't provide one in the High-Level (that I can find), only the low-level. Also, you're looking at a moving target, it was here at the time of testing... https://github.com/tresf/qz-print/commit/a7b86dc1fb9d96cba71023a2ac52ff76c1a90cc7.
@hjelmn agreed. I suppose I should not expect them to be synchronized when combining two completely separate apis from the same library. What if I were to take
Duly noted. Are we OK to see this through? Surely the research on |
|
@mcuee I agree with you but this device seems to be usable by libusb because the HID device class is specified in the configuration descriptor. Since the device will be exclusively opened by libusb I don't think that IOUSBHID will be able to attach once the device is configured. I may be wrong though. @tresf I think I see an issue in your code @ https://github.com/tresf/qz-print/blob/30d5c2229b3cffaeba854263a9cb96f21d5ff98f/src/qz/communication/UsbIO.java#L30 You are getting the interface before the setConfiguration call. Try moving this line to after the setConfiguration call and see if that helps. Hmm, thinking about it that might not make a difference. Not too familiar with usb4java. |
|
@hjelmn Thanks for the spot check. Tried this via Growing a bit concerned about the lack of verbosity with the [167.690699] [0000dd03] libusb: debug [libusb_set_configuration] configuration 1
[167.690712] [0000dd03] libusb: debug [libusb_claim_interface] interface 0
+ [167.713521] [0000dd03] libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access
[167.713570] [0000dd03] libusb: debug [libusb_release_interface] interface 0
[167.713577] [0000dd03] libusb: debug [libusb_close] Full gist here: https://gist.github.com/tresf/0e6bde6 |
|
Hmmm, well that error suggest the device was successfully configured. I wonder if IOUSBHID somehow managed to grab the interface after the device was configured even with a user-space process holding the device. Unfortunately I can't look at the IOUSBFamily source code of 10.11 to verify as Apple has decided to no longer release the code. If IOUSBHID is grabbing the interface it would suggest that hidapi is going to be the only way to get this working. It looks like there has been some work on java bindings for the hidapi library: https://github.com/gary-rowe/hid4java |
Ok, I finally claimed it... I had to use a remote desktop utility because this command kills the mouse... sudo kextunload -b com.apple.driver.usb.IOUSBHostHIDDeviceOnce this was run, I could claim the device. 👿 There must be something wrong with my
It's a pretty vanilla |
|
You need to prevent IOUSBHID from loading on the interfaces not the device. Example: https://github.com/hjelmn/gcusbadapter_osx/blob/master/gcusbadapter/Info_raw.plist |
I was following the documentation here: https://developer.apple.com/library/mac/qa/qa1076/_index.html [quoted]
I wasn't sure how reliable the Edit: Example: https://github.com/RehabMan/OS-X-BrcmPatchRAM/blob/master/BrcmBluetoothInjector-Info.plist Edit2: Comparing the two...
Finally... is early-boot availability needed via |
|
The main takeaway from my example (which is a HID device) is that you need to match the IOProviderClass IOUSBInterface (or IOUSBHostInterface-- 10.11+ only) not IOUSBDevice. Your kext may very well be matching the device but that won't prevent IOUSBHID from grabbing the interfaces. |
Gotcha, I'll switch that over and take another crack at it tonight. Can you help explain the volatility of these settings? e.g. Should these stay relatively identical for all HID devices? How would I know what these should be? <key>bInterfaceNumber</key>
<integer>0</integer>
<key>bConfigurationValue</key>
<integer>1</integer> |
|
Those lines limit the matching to a specific configuration/interface. It prevents the kext from matching interfaces that were not intended. |
|
@hjelmn Thanks. I guess my question is, how do I know which options are safe to use for a particular HID device? Are they almost always |
|
It device specific. You can tell from the device/configuration/interface descriptors which options you want. In most cases it will be |
Confirmed this on a Windows machine. Unfortunately, I still can't get the kext to load. You had previously mentioned |
|
It should work with either the legacy IOUSBInterface or IOUSBHostInterface. There is probably some subtle bug that isn't being detected by kextload. |
Yeah, I'm having a hard time putting my finger on it. Debugging these codeless I thought perhaps the package name ending in I've detached and reattached the device several times and it seem to stay available. Here's the current log (I'll be squashing commits very shortly if this starts to work.) I'm still a bit uncertain what changed... 😕 On a side note, after some more digging around, I found another comment about Apple denying the
Although I can somewhat understand Apple's stance in regards to the request coming from an emulator community... Do you know if Apple does the signing themselves, or do they offer a new developer certificate which has |
|
Rebooted and same familiar message... Manually ran Are you aware if I guess the good thing is it's predictable now. It works after unplugging and plugging back in and manually running |
|
Ok... it's finally working first try after a reboot without manually firing |
|
... and now it's not working again unless We'll start implementing the |
@hjelmn, As a follow-up to this, Apple did grant |
|
@tresf Nice! I keep hitting a brick wall when trying to get signing right but I am an open-source developer. Here is their latest response: |
|
@hjelmn We're open source as well, but operate a commercial business model, which may be the deciding factor here. |
|
@tresf That probably is the difference. Find it a little odd that Apple is willing to shut out third party support when there is no chance of first party support. |
|
The problem seems to be due to a conflict between different drivers, which use the same libraries, and in my case they were related to previous Samsung device installations. i had solved this way: To have a return like this: Then: Done. Enjoy |
I'm using a high-level api wrapper, usb4java to claim a USB device on Mac.
udevworkarounds)kextdummy extension,csrutil disable,kext-dev-mode=1, etc..)The errors:
NullPointerExceptiondue to assumptions about the active configuration. (reported by Java of course)Configuration not activewhen trying to "claim" the device.Since
libusbis so popular for being wrapper by other languages (py, java),how best to provide debug information for wrapper libraries such as usb4java?Edit TheLIBUSB_DEBUG=4works fine on usb4java if the Java app is started from Terminal. Logs appended below.I've filed a downstream bug here:
usb4java/usb4java#51
And as well as our own downstream-downstream bug:
qzind/qz-print#180
I have a C/C++ build environment on the 10.11 machine, but I'm not familiar enough with C nor the API to start writing test cases, etc, so any help is appreciated.
The text was updated successfully, but these errors were encountered: