Iocreateplugininterfaceforservice Returns Mysterious Error

IOCreatePlugInInterfaceForService returns mysterious error

Finally managed to resolve this after weeks of head scratching. The new Xcode 9 uses app sandboxing to basically prevent access to USB, bluetooth, camera and microphone etc. by default in a new app. Once I switched this off it reverted to it's expected behaviour.

Glad it was such a simple answer in the end but disappointed Xcode does not provide more descriptive error messages or responses to let a user know they are essentially preventing themselves from accessing the parts of the system they need.

get information on usb devices (OSX, C++), IOCreatePlugInInterfaceForService fails

You're matching IOUSBDevice services, but attempting to connect with an IOUSBInterfaceUserClient. If you want to connect to an IOUSBDevice service, the user client type must be kIOUSBDeviceUserClientTypeID. If you want an IOUSBInterfaceUserClient, you need to match IOUSBInterface services.

USBInterfaceOpen always report kIOReturnExclusiveAccess error

A few points:

  • The codeless kext approach should normally work for this kind of situation.
  • Typically, your codeless kext would match (via IOProviderClass) an IOUSBInterface, not an IOUSBDevice. (e.g. see the FTDI example)
  • The bundle identifier for IOService is com.apple.kpi.iokit, not com.apple.iokit.IOUSBFamily, although I suspect that shouldn't be an issue.
  • Is your codeless kext signed and installed correctly? (I have had instances where a kext in /Library/Extensions/ would not work at boot time, at least on OSX 10.9.x, unlike /System/Library/Extensions, although it should work OK for any hot-plugged devices.) Make sure the kext/personality cache is up to date, in other words, touch the Extensions directory whenever you update the kext.
  • What does kextutil -n say?
  • Have you tried setting the IOKitDebug personality property to see if your kext is even getting a chance to match the device?
  • Depending on how your firmware update commands are implemented, you may be able to use ioctls on the device node. You can send raw SCSI requests to SCSI devices via ioctl. I'm not sure this will work for the USB mass storage class, but it definitely will for USB attached SCSI (UAS) or any other "true" SCSI device. Obviously this only helps if the your firmware update commands are exposed via SCSI.

If after all of that, you're still stuck, please provide some more information related to the above suggestions!

OpenCV command line app can't access camera under macOS Mojave

The problem was that the c++ program, for whatever reason, wasn't requesting camera access. I took the advice of @gerwin in the comments to give it a try with Python. Running that program from Terminal resulted in Terminal asking for camera access. Once I granted that, the c++ program was able to access the camera when run from Terminal.

As far as CodeRunner, I'm not sure how to get CodeRunner to run Python programs under a virtual environment so I haven't been able to run a Python OpenCV program to get it to ask for camera access. So at the moment I can't use CodeRunner to run a c++ program that accesses the camera.

OBEX over USB with IOKit

Finally I figured it out. The problem consisted of two parts. First problem was OBEXAddTargetHeader("LivescribeService", strlen("LivescribeService"), header);. Because strlen is the length of the string and not how many bytes are used (+1 for the 0x00 string terminator) the device responded with an error because it expects the string to be terminated. Sadly the OBEXSession just ignored the error that came back from the device.

Second problem was that I sent the received data with kOBEXTransportEventTypeStatus instead of kOBEXTransportEventTypeDataReceived to the clientHandleIncomingData: method.

Now the connection to the device works as expected.



Related Topics



Leave a reply



Submit