I'm trying to make an asynchronous bulk data read using AsyncIO/CompleteAsyncIO. The problem I'm facing is that the AsyncIO succeeds but CompleteAsyncIO/ReadComplete doesn't get called when the AsyncIO's completion timeout is set to 0. Changing the completion timeout to a non-zero would trigger ReadComplete but I keep getting the (0x2d6) "I/O Timeout" error Any idea what I'm doing wrong? Also, is there any limit for the maximum buffer length the callback can accept? Thanks. struct MyDriver_IVars { OSAction* callbackAction = nullptr; // registered callback action by app IOUSBHostInterface* interface; IOUSBHostPipe* pipe; IOBufferMemoryDescriptor* inDataBuffer; OSAction* ioCompleteCallback = nullptr; // read complete callback action uint32_t MAX_LENGTH = 1024; }; kern_return_t IMPL(MyDriver, Start){ //........... ret = ivars->interface->CopyPipe(endpoint->bEndpointAddress, &ivars->pipe); ret = ivars->interface->CreateIOBuffer(kIOMemoryDirectionInOut, ivars->MAX_LENGTH, &ivars->inDataBuffer); ret = CreateActionReadComplete(ivars->MAX_LENGTH, &ivars->ioCompleteCallback); //........... } kern_return_t MyDriver::ReadData(int nbytes, int timeout) { //........... kern_return_t ret = ivars->pipe->AsyncIO(ivars->inDataBuffer, ivars->MAX_LENGTH, ivars->ioCompleteCallback, 0); //........... } void IMPL(MyDriver, ReadComplete) { Log("ReadComplete() - status - %d; bytes count - %d", status, actualByteCount); //AsyncCompletion(ivars->callbackAction, .................. } virtual void ReadComplete(OSAction* action, IOReturn status, uint32_t actualByteCount, uint64_t completionTimestamp) TYPE(IOUSBHostPipe::CompleteAsyncIO);

Bjr. Je ne parviens plus à réinstaller aucune application après avoir formaté ou réinitialisé mon iPhone. Comment résoudre se problème rapidement. mon système c'est IOS 17.5.1. Peut être faut-il faire une mise à jour du système pour résoudre définitivement ce problème d'installation d'applications. sil vous plaît trouver une solution rapidement. Je veux récupérer mes données d’urgence. Merci

the battery charge is discharging at 12% charge even when switching to battery saver it is discharging very quickly

I'm writing a C/C++ command line program which, at some point, calls IOHIDManagerOpen. I've added both my program executable and lldb as permitted for input monitoring (as far as I remember, my program was added after showing up a permission prompt, I've added lldb manually later, trying to resolve the problem). My problem is that when I run my program from within lldb in Terminal, the call to IOHIDManagerOpen returns kIOReturnNotPermitted. When I run my program directly in the terminal session (without lldb), this call returns kIOReturnSuccess. Such behaviour means it will be impractical to use lldb for any debugging of this program. What can be done to make lldb session behave the same way, the normal execution works? I'm on: 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:55:06 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6020 arm64 and: lldb-1500.0.200.58 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)

When application requires apple reciepts, apple server returns 21107 satus. Why apple server return 21107?

Where do I get. PerfPowerTelemetryClientRegistrationService which is suddenly missing from my system since upgrading to MacOS15/IOS18?

I have a USBDriverKit driver which tries to send vendor-specific DeviceRequests to the IOUSBHostDevice. A few short months ago this worked, and as far as I know, the only change since it last worked is an update to macOS 14.5. The dext user client calls through to the driver, which wants to do this: ivars->mDevice->Open() ivars->mDevice->DeviceRequest() ivars->mDevice->Close() the problem is that the call to Open returns 0xe00002cde, which is kIOReturnNotOpen. If I don't call Open, but simply call DeviceRequest, I get the same result, kIOReturnNotOpen, which I would expect. I'm pretty sure that in macOS 14.4, the call to Open() did not return an error. I haven't seen any system logs that clue me in to why Open() is failing. It would be handy if the error gave me some reason why the device cannot be opened. Has anyone else seen this? I've searched high and low and I can't find any examples of dexts which actually do anything at all with a USB device.

Hello forum, I'm trying to build communications between a non-MFi HID device (say, a keyboard with a USB-C port) and an iOS device over a MFi-licensed cable with Swift, what framework would you suggest? The USB-C cable is MFi-licensed. The keyboard is not MFi-licensed.

I use NETransparentProxyProvider transparent proxy the outbound data ports 80 and 443, at the same time using CocoaAsyncSocket third party open source libraries for data forwarding At first, handleNewFlow will be called normally, but after running for a period of time, handleNewFlow will not be called again, and the system will not be able to access the Internet unless the vpn is disabled By checking the terminal app log, I found that handleNewFlow will not be called again when the following information is displayed. # Domain=NEAppProxyFlowErrorDomain Code=1 "The operation could not be completed because the flow is not connected" UserInfo={NSLocalizedDescription=The operation could not be completed because the flow is not connected" #

hi all. I subscribe the notify write event, every time I recieve a notify write event message i will send log data and reply block(didn't do nothing) with async method to host app(Objc XPC API).host app will reply immediately once it recieves data. after a while my sysext crashed, then I checked system log find the log below. launchd: exited with exit reason (namespace: 30 code: 0xc40000000004aaaa) - (unknown reason) is it because of exceeding the maximum limit of xpc's block queue length, or too many memory allocation, or... by the way, host app didn't crash. how this happened exactly? how could i solve it?

Hello. Is there a legal way to block iOS devices from being mounted on macOS? I noticed, that when an iOS device is connected, it pretends to be like a storage device but it is not. It not even going through diskArbitration. It seems that some fileProvider is taking place there. I know that it is possible to do via the MDM profile: <key>PayloadContent</key> <dict> <key>.GlobalPreferences</key> <dict> <key>Forced</key> <array> <dict> <key>mcx_preference_settings</key> <dict> <key>ignore-devices</key> <true/> </dict> </dict> </array> </dict> </dict> But is there some programmatic solution? If I use EndpointSecurity and block file operations for the usbmuxd process on /var folder, it prevents iOS devices from being mounted. But wouldn't be there any negative side effects from such a solution?

How do I adjust the latency timer for the AppleUSBFTDI driver? I am developing an app in Swift using Xcode on a MacBook Pro M1 running Big Sur, for clinical brain-computer interface (BCI) research. The app needs very low-latency streaming from an external USB device. The external device is a headset which connects via Bluetooth to an FT231X chip mounted on a USB-Serial dongle. The FT231X chip reads timestamped EEG data from the headset. The issue is that the AppleUSBFTDI driver is buffering the packets coming in from the headset, which causes jitter in the timestamps. Typically, with proprietary drivers from FTDI, the solution is to reconfigure them to reduce the latency timer to 1ms. The Info.plist is edited to add new key/value pairs. Is there a similar solution for Apple's built-in driver?

Hi everyone, first-time caller, long-ti... wait, no, I just got here. :) I am relatively new to all things Apple, so apologies in advance if it takes me a few goes to properly explain things. We have a framework, which includes an API, an XPC service, etc, and we have a device driver. We also have some sample apps that use the framework, and if they have the app sandbox capability, then we expect them to use the XPC Service instead of accessing our driver directly. This works fine on Monterey and presumably has worked fine on all previous versions of MacOS. Something seems to have changed on Ventura, and we don't understand what. When we build the same app on Ventura, it appears to be in the sandbox (according to the Sandbox column in Activity Monitor), but in the Console there is this line (twice): default <time> <OurAppName> Revoking sandbox extension; key = 0 Which we suspect is linked to the fact that the app then does not use the XPC Service, and instead accesses the driver directly, much to our surprise. Software built on developer's machines is "Automatically managed" and "Signed to Run Locally" in case that matters. Do we need to change our code to support Ventura and onward? Or is it a bizarre bug? Oh, I should say that I'm running the latest version of Ventura (13.6.7 as of writing) but not the latest Xcode (14.2 (14C18)) and CLI tools... can't remember how to find that version... Apple clang version 14.0.0 (clang-1400.0.29.202). Any help would be appreciated, thanks. Jeremy

How can a Dext be activated from C++. Specifically we need to load our Dext from our c++ CoreAudio server plugin. I guess it all boils down to how to call the OSSystemExtensionRequest Swift interface from C++... Thanks for any hints!

Hi. I am new to ios development and I am using swift to try to develop a sample app to connect a Canon camera to an iphone via a usb cable and I want to use the ImageCaptureCore framework to do this (that is I want to use the USB PTP). Although I see the documentation on the Apple site, I am still unsure where to begin. Is there any tutorials, etc. about where I can get started with this? I was able to find a couple of code snipets and piece together something with ICDeviceBrowser but when I load the program onto my iphone and connect the camera via usb, I am not able to detect any camera. So ideally I am looking for some sort of tutorial that goes through how to do this or if not, what do I have to do to at least be able to detect the camera from the iphone?

We have developed a library and a DriverKit driver on Mac platform. And we need to disable SIP to install dext and later point of time if we enable SIP then the dext is non functional. So is it mandatory to disable the SIP for whole life time of dext? Also it is not recommended to disable the SIP for a long time, as it may create a security hole. Standard ways are given on Apple support page that how to notarise an application to distribute over the internet. Here one mandatory account is required that is Apple Developer account which is a paid account we believe. Standing at this point can you share the complete steps of software distribution process which will include code signing, notarisation process and stapling.

Using IOServiceMatching and IOServiceGetMatchingServices api's written in swift to extract the info of both internal and external USB devices connected. For the same code Intel based Mac OS devices gives all the info like product id , vendor id , Serial number and etc for both external and Internal USB devices( Apple and Non Apple devices connected either to Apple T2 bus or USB bus). For the same code M2 Mac Machine only gives the external device info which are connected to USB, doesn't give any info of Internal USB connected devices. Why is this difference ? Which api's need to be used to extract info of internal USB connected devices even in M2 based Mac machine. Thanks

The only one I can find it are some code comments in head files, would like to know any detialed workflow or sample code for it. Thanks!

I am using SCSIPeripheralsDriverKit/IOUserSCSIPeripheralDeviceType00 to develop a Dext driver, which has only two classes: MyUserSCSIPeripheralDeviceType00 and MyUserClient, MyUserClient is responsible for receiving APP commands and passing them to MyUserSCSIPeripheralDeviceType00->UserSendCDB(), After the device is connected to the computer, the driver can match the device and start, calling MyUserSCSIPeripheralDeviceType00-->init(), MyUserSCSIPeripheralDeviceType00-->Start(), Any command sent by the APP to MyUserSCSIPeripheralDeviceType00 will return a failure: kIOReturnUnsupported (0xe00002c7), including UserSendCDB(), UserReportMediumBlockSize(), <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>IOKitPersonalities</key> <dict> <key>MySCSIDriver</key> <dict> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleIdentifierKernel</key> <string>com.apple.kpi.iokit</string> <key>IOClass</key> <string>IOUserService</string> <key>IOMatchCategory</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>IOProviderClass</key> <string>IOSCSIPeripheralDeviceNub</string> <key>IOResourceMatch</key> <string>IOKit</string> <key>IOUserClass</key> <string>MyUserSCSIPeripheralDeviceType00</string> <key>IOUserServerName</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>UserClientProperties</key> <dict> <key>IOClass</key> <string>IOUserUserClient</string> <key>IOUserClass</key> <string>MyUserClient</string> </dict> <key>bConfigurationValue</key> <integer>1</integer> <key>bInterfaceNumber</key> <integer>0</integer> <key>bcdDevice</key> <integer>1</integer> <key>idProduct</key> <string>*</string> <key>idVendor</key> <integer>12345</integer> <key>Peripheral Device Type</key> <integer>0</integer> <key>IOKitDebug</key> <integer>65535</integer> </dict> </dict> </dict> </plist> This is the method that receives client calls kern_return_t MyUserSCSIPeripheralDeviceType00::HandleExternalStruct(IOUserClientMethodArguments* arguments) { kern_return_t ret = kIOReturnSuccess; SCSIType00OutParameters command; SCSIType00InParameters response; SCSI_Sense_Data sense; UInt64 fSenseAddr = (intptr_t)&sense; bzero((void *)&command, sizeof(SCSIType00OutParameters)); bzero((void *)&response, sizeof(SCSIType00InParameters)); bool test = TEST_UNIT_READY(&command, &response, fSenseAddr); // test is true ret = this->UserSendCDB(command, &response); // ret is kIOReturnUnsupported （0xe00002c7） UInt64 blockSize; kern_return_t sizeRet = this->UserReportMediumBlockSize(&blockSize); // sizeRet is kIOReturnUnsupported （0xe00002c7） }; // Not called. As per the documentation, this should be called during enumeration. kern_return_t IMPL(I4UserSCSIPeripheralDeviceType00, UserDetermineDeviceCharacteristics) { // *result = true; return kIOReturnSuccess; }

Hi, does anyone know if IOUSBDeviceInterface187 and IOUSBInterfaceInterface190 interfaces will be available on application level next years and there is no any deprecation plans ? Common Recommendations are to use USBDriverKit, but is there a real need to complicate USB communication in this way?