Post

Replies

Boosts

Views

Activity

is com.apple.developer.usb.host-controller-interface managed?
I'm posting this here after reading Quinn's post here: https://developer.apple.com/forums/thread/799000 The above entitlement is mentioned in IOUSBHostControllerInterface.h. It isn't an entitlement one can add using the + button on the Capabilities panel in Xcode. If I try to add it by hand, Xcode complains that it isn't in my profile. Is this a managed entitlement? We'd like to create a local USB "device" to represent a real device reachable over a network.
7
1
953
5d
USB HID Digitizer support on macOS
I'm investigating supporting a touchscreen digitizer on macOS. I'd like to receive multi-touch reports from the device, and have them intercepted by my app. I also want to suppress the default absolute positioning 'mouse' behavior of the touch screen. The device exposes three HID interface: #0 - multi-touch (PrimaryUsagePage 0xD, PrimaryUsage 4) #1 - vendor-specific #2 - single-touch (PrimaryUsagePage 1, PrimaryUsage 2) I've only been able to achieve half of my goal using a HIDDriverKit dext - I can outmatch the OS for the single-touch HID interface and ignore its 7-byte single-touch reports. However, although I can match to the multi-touch interface, I never see any reports at all there, as if the OS never polls the interrupt endpoint. On Windows, the device "just works" - I've traced its behavior in Wireshark. The OS doesn't do any special setup, it sends no SET_FEATURE commands, it just reads from the multi-touch interrupt endpoint, where it receives 54-byte reports. Windows doesn't even get any 7-byte single-touch reports. On macOS, I managed to use Wireshark on an old Intel Mac, where I can still use XHC20 for logging. Here, macOS tries to read from all the interrupt endpoints for all the HID interfaces, and the digitizer only responds on the single-touch interface. MSDN's documentation for multi-touch support is quite unhelpful here, because it just says "use the OS driver", but doesn't detail how a digitizer switches between multi-touch and single-touch mode. If I were making a digitizer, I'd send reports on both interfaces, expecting the OS to read the single- or multi-touch interface as required. Although unlikely, it seems that this digitizer changes its behavior based on how it is accessed. I can outmatch the USB interface for the single-touch reports, so that the OS HID driver doesn't even see it. That doesn't change the device behavior. The HIDDriverKit APIs I use imply setting up an interrupt read. I call Open on the interface, and implement a ReportAvailable callback. This works for the single-touch interface, but I get no reports on the multi-touch interface. All the calls with return values return kIOReturnSuccess. Does anyone know how multi-touch digitizers switch between single- and multi-touch mode (if indeed they have a mode at all), or why macOS apparently doesn't even read the multi-touch interrupt end point? Does anyone know how I can ensure that my HID driver actually reads the interrupt endpoint on the HID interface it is matched to? Does macOS deliberately prevent access to multi-touch HID interfaces?
2
0
156
6d
how to inhibit -fprofile-instr-generate passed to linker
I'm struggling to build a driver for iPadOS in a particular project configuration. If I put the driver code and dext target into the same Xcode project which contains the iPad app, all is well. This is the way the Xcode driver template does it. However, I'd like to build and debug the dext on macOS, while eventually deploying on iPadOS. So I put the dext into a different project, which has a macOS target, a minimal iPadOS target and a DriverKit target. I made a workspace which contains both projects. I dragged the macOS project into the iPadOS project so that I can refer to the products of the macOS project (specifically, its driver target) as a dependency of the iPadOS target. Note that the main iPad app target depends on the driver target. So the workspace organization looks like this: Workspace iPad project main iPad app target (depends on driver) test project reference test project test macOS/iPad app target DriverKit dext target When I build the iPadOS target, it builds the dependent driver target in the macOS project, but it fails to link because Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a is not found. If I just build the driver target directly in Xcode, there is no such complaint. I looked closely at the build logs, and I see for the failed link, there are these two linker flags set which are not set in the successful case -debug_variant -fprofile-instr-generate I can't seem to control the generation of this flag. I tried turning off the Profile switch in the Scheme editor for the driver, but is makes no difference. When I directly build the driver target, no -fprofile-instr-generate is set and it compiles and links. When i build the driver as a dependency of another target, -fprofile-instr-generate is passed to the linker, which fails. The obvious workaround is to put the driver source code into a separate driver target in the iPadOS project, but I'd rather have just one DriverKit driver for both platforms, with a few settings (such as bundle ID) controlled by a configuration file. Has anyone else encountered this problem, and know of a workaround?
3
1
1.5k
Mar ’26
is the output frame rate of a CMIOExtension rounded or capped?
I made a CMIOExtension (a virtual camera) which generates its own output, for use in our in-house software testing. I wanted to make a video source with 29.97, 30, 59.94 and 60fps output. To this end, I created a CMIOExtensionDeviceSource which creates a CMIOExtensionDevice with one CMIOExtensionStreamSource with various stream formats contained in [CMIOExtensionStreamFormat], including one with both maxFrameDuration and minFrameDuration = CMTimeMake(value: 1000, timescale: 30000) and another with both maxFrameDuration and minFrameDuration = CMTimeMake(value: 1001, timescale: 30000) I've held off on the creation of the 59.94/60fps source for now until this problem is resolved. my virtual camera works, it produces a signal, but when I examine its associated AVCaptureDevice in the debugger, I find (lldb) po self.captureDevice?.formats[0].videoSupportedFrameRateRanges[0].maxFrameDuration ▿ Optional<CMTime> ▿ some : CMTime - value : 1000000 - timescale : 30000000 ▿ flags : CMTimeFlags - rawValue : 1 - epoch : 0 I get the same value, 1000000/30000000, or exactly 30fps, for all the formats of my AVCaptureDevice. Is there something I'm doing wrong, or do CMIOExtensionDevices always round the frame rates? I can't force CoreMediaIO to produce frames at exactly my desired frame interval, but I'd like to ensure that the average frame rate is my desired rate. How can I do that? Frame emission is governed by a repeating DispatchSourceTimer with a repeat time specified in nanoseconds with the TimerFlags set to 'strict'.
2
0
906
Jan ’26
Should UserSendCBD work on UAS interfaces?
The device I am trying to develop a firmware updater for is an NVMe drive with a USB4 interface. It can connect in USB4 mode (tunneled NVMe), in USB 3 mode or in USB 2 mode. In USB 2 and USB 3 mode, the device descriptor shows one interface with two alternates. Alternate 0 uses the bulk-only protocol, with one IN and one OUT pipe. Alternate 1 uses the UAS protocol, with two IN and two OUT pipes. I use identical code in my driver to send custom CDBs. I can see using IORegistryExplorer that in USB 2 mode, macOS chooses alternate 0, the bulk-only protocol. My custom CDBs and their accompanying data pay loads are put on the bus, more or less as expected. In USB 3 mode, macOS chooses alternate 1, the UAS protocol. My custom CDB is put on the bus, but no payload data is transferred. Is this expected behavior? If so, is there a way to force the OS to choose alternate 0 even when on USB 3, perhaps with another dext? I'll file a bug about this when Feedback Assistant lets me.
8
0
521
Oct ’25
PCIDriverKit entitlements during development
I'm trying to help out one of our vendors by building a skeleton PCI dext which they can flesh out. However, I can't seem to get the signing right. I can't sign it at all using no team or my personal team. "Signing for requires a development team", and "Personal development teams ... do not support the System Extension capability". I can't sign the driver because "DriverKit Team Provisioning Profile: doesn't match the entitlements file's value for the com.apple.developer.driverkit.transport.pci entitlement. I think this problem occurs because our company has already been assigned a transport.pci entitlement, but for our own PCI vendor ID. But I want to build and test software that works with our vendor's PCI device. I tried generating a profile for the driver manually, it contained only our own company's PCI driver match: IOPCIPrimaryMatch = "0x0000MMMM&0x0000FFFF"; where MMMM is our own PCI vendor ID. Is there a better way to inspect the profile Xcode is using than the postage-stamped sized info popup which truncates the information? I would download the generated profile but it doesn't appear on the profile, but Xcode is accessing it from somewhere. When I look at the available capabilities I can add to an app identifier on the Developer portal, I see com.apple.developer.driverkit.transport.usb, which is "development only". There's no "development only" capability for PCI. Does this mean it isn't possible to develop even a proof-of-concept PCI driver without being first granted the DriverKit PCI (Primary Match) entitlement? When adding capabilities to a driver, the list of available capabilities shown in Xcode has one "DriverKit PCI (Primary Match) entry", but if I double click it, two such entries appear in the Signing and Capabilities tab for my driver target. On the Developer portal, when I look at my driver's Identifier, there are two Capabilities labelled DriverKit PCI (Primary Match). Why?
7
0
1.5k
Oct ’25
limitations of UserSendCDB in SCSIPeripheralsDriverKit?
I've made a dext and a user client that overrides IOUserSCSIPeripheralDeviceType00, with the object of writing device firmware to the driver. I can gain and relinquish exclusive access to the device, I can call UserReportMediumBlockSize and get back a sensible answer (512). I can build command parameters with the INQUIRY macro from IOUserSCSIPeripheralDeviceHelper.h and send that command successfully using UserSendCB, and I receive sensible-looking Inquiry data from the device. However, what I really want to do is send a WriteBuffer command (opcode 0x3B), and that doesn't work. I have yet to put a bus analyzer on it, but I don't think the command goes out on the bus - there's no valid sense data, and the error returned is 0xe00002bc, or kIOReturnError, which isn't helpful. This is the code I have which doesn't work. kern_return_t driver::writeChunk(const char * buf, size_t atOffset, size_t length, bool lastOne) { DebugMsg("writeChunk %p at %ld for %ld", buf, atOffset, length); SCSIType00OutParameters outParameters; SCSIType00InParameters response; memset(&outParameters, 0, sizeof(outParameters)); memset(&response, 0, sizeof(response)); SetCommandCDB(&outParameters.fCommandDescriptorBlock, 0x3B, // byte 0, opcode WriteBuffer command lastOne ? 0x0E : 0x0F, // byte 1 mode: E=save deferred, F = download and defer save 0, // byte 2 bufferID (atOffset >> 16), // byte 3 (atOffset >> 8), // byte 4 atOffset, // byte 5 (length >> 16), // byte 6 (length >> 8), // byte 7 length, // byte 8 0, // control, byte 9 0, 0, 0, 0, 0, 0); // bytes 10..15 outParameters.fLogicalUnitNumber = 0; outParameters.fBufferDirection = kIOMemoryDirectionOut; outParameters.fDataTransferDirection = kSCSIDataTransfer_FromInitiatorToTarget; outParameters.fTimeoutDuration = 1000; // milliseconds outParameters.fRequestedByteCountOfTransfer = length; outParameters.fDataBufferAddr = reinterpret_cast<uint64_t>(buf); uint8_t senseBuffer[255] = {0}; outParameters.fSenseBufferAddr = reinterpret_cast<uint64_t>(senseBuffer); outParameters.fSenseLengthRequested = sizeof(senseBuffer); kern_return_t retVal = UserSendCDB(outParameters, &response); return retVal; }
3
0
685
Sep ’25
Xcode fails to provision target
I've alluded to this before in these posts and there are some posts from others about this, e.g. https://developer.apple.com/forums/thread/759845 and I've filed some bugs related to the behavior. FB20212935 FB19451832 FB19450508 FB19450162 FB19449747 Our company owns the USB vendor IDs X and Y . We've been granted a USB transport entitlement for both of those IDs. The crux of the problem is that I want to build a driver for USB vendor ID Y. Xcode's well-hidden auto-generated provisioning profile for my driver contains com.apple.developer.driverkit.transport.usb: { idVendor = X; } which is obviously not what I want. Xcode fails to provision the target. But I have another, much older project with an auto-generated provisioning profile containing com.apple.developer.driverkit.transport.usb: { idVendor = X; }, { idVendor = Y; } I can build a driver for idVendor Y without problems in this project. But that doesn't help me with my new project. What can I do to fix this? Do I need to request our entitlements again? I fear if I do so, something will get lost in the process. Is there a way to inspect what we have already been granted? - I can't see a "managed entitlements" section on the account portal. I can go through the motions of making a new App ID, then I can see that some Capability Request have been "Assigned", but I don't see what their values are. A second question I have is about the userclient-access entitlement. Are these tied to the bundle ID of the app which claims the access? In other words, if I have two drivers com.mycompany.app1.driver1 com.mycompany.app2.driver2 and I would like to have com.mycompany.app1 communicate with com.mycompany.app1.driver1, I would ask for the com.apple.developer.driverkit.userclient-access capability for com.mycompany.app1.driver1. But must I request that access for each specific app bundle ID that will talk to that driver, or once the entitlement is granted, can I use com.apple.developer.driverkit.userclient-access = { com.mycompany.app1.driver1 } in any of my apps?
1
0
436
Sep ’25
How do I use IOUserSCSIPeripheralDeviceType00?
I am having similar problems to this guy on Stack Overflow over a year ago: https://stackoverflow.com/questions/77627852/functions-of-iouserscsiperipheraldevicetype00-class-in-scsiperipheralsdriverkit There are also a few questions on this forum about this object, none of which have answers. I can get my driver to match and instantiate, but nobody calls my UserDetermineDeviceCharacteristics (which does nothing, just returns kIOReturnSuccess) I can attempt to call UserSuspendServices(), UserResumeServices() or UserReportMediumBlockSize() and all of them return kIOReturnUnsupported. It doesn't matter if I've unmounted the disk or not. Is the custom driver supposed to be instantiated beside the kernel's IOSCSIPeripheralDeviceType00, or should it replace it? What should its IOProviderClass be? What should its IOClass be - IOUserService, or something else? see FB19678139 and FB19677920
5
0
356
Sep ’25
CoreAudio HAL plugin vs dext
The presentation "create audio drivers with DriverKit" from WWDC 2021 demonstrates how to use a dext to implement a virtual audio driver. It also says " If a virtual audio driver or device is all that is needed, the audio server plug-in driver model should continue to be used". Indeed, in AudioDriverKit/AudioDriverKitTypes.h, there is no IOUserAudioTransportType Virtual, although CoreAudio/AudioHardwareBase.h includes kAudioDeviceTransportTypeVirtual. For one of our products, we require virtual devices to implement a software loopback "cable". We've implemented this using the "traditional" HAL plugin, and as a proof-of-concept, also using a dext. In the dext, I tried setting the transport type to 'virt', which seems to only have the effect of changing the icon shown in Audio Midi Setup. HAL plugins require an installer, and the installer has to kill coreaudiod in a post-install script. You have to turn off SIP to debug them. Just like AudioDriverKit drivers, they are out-of-process and run in a process not owned by the hosting app. Our HAL plugin's interface is property based; we had to write a lot of boiler-plate code to implement required properties. Writing an AudioDriverKit driver is in most respects easier - a lot of the scaffolding is implemented in the base driver, which we only alter where required. Debugging and installation is much easier. The dext works just fine, as far as we can ascertain, just as well as a HAL plugin. So, my question is - is the advice to use a HAL plugin for a virtual device still correct in 2025? And if so, what's the objection? We'd really prefer to ship the AudioDriverKit virtual audio device.
2
1
608
Mar ’25
Swift Testing environment differences from regular executable
I am working on a Swift package which uses CoreAudio, and includes some tests in a testTarget which use the Testing framework, and a couple of executableTarget targets which exercise the same code. I'm using Xcode 16.2 on macOS 15.3.1. One of the things I do in the test code is create a HAL plugin, then find that plugin using the kAudioHardwarePropertyTranslateUIDToDevice. Finding the plugin that I just created always fails from within a Swift Testing test, unless I run the test which creates the plugin individually first, then separately, run the test which finds the plugin, by clicking on the little arrows next to the function names. If I put the tests in a serialized suite (so creation always happens first, then finding), running the suite always fails - it creates the plugin, but can't find it. If I run the 'find my plugin' test again manually, it is always found. If I call the same functions from a regular executable (the thing created by a "executableTarget" in my .package.swift file), the just-created plugin is always found. Is there a way to mimic the runtime environment of a regular executable in a Swift Testing target, or am I misunderstanding something? this my be related to this issue: https://github.com/swiftlang/swift/issues/76882 but I don't understand it well enough to be sure.
4
0
681
Feb ’25
DriverKit target built as dependency, header not found
I have an Xcode project with a main app target, and a dext target which builds a DriverKit driver which is embedded in the main app. That all works, if I build the DriverKit target first, then switch to the app target and build that. The app and the driver work. If I make the Driver target a dependency of the App target, building the Driver fails because a header is not found, thus building the app fails. This doesn't make much sense - why does building a target as a consequence of dependence on another target produce a different result from building the same target manually? Has anyone else seen behavior like this? Have any hints on how to fix it? I've tried comparing the detailed build logs, but they don't shed much light - the lines are very long and the build steps appear to be executed in a different order. One strange thing I notice is that although I am building on an M1 Mac, with "build active architectures only" set to YES for both targets, in the Driver-target-only case, Driver.cpp is compiled for arm64, while in the failure case, Driver.cpp is compiled for x86_64. That doesn't make any sense to me either.
1
0
727
Sep ’24
USB drive invisible to our app on supervised iPad
We have an iPad app which can write to user-specified locations on USB-connected storage devices. On unmanaged devices, this works just fine. However, when the device is under MDM, although the Files app can see the external USB storage device, it does not show up in the file browser in our own app. There's a restriction called "allowFilesUSBDriveAccess" which is set to true (the default), but there's no restriction called "allowOtherAppsUSBDriveAccess". Are MDM-managed iPads simply not allowed to access USB drives (except through the Files app)?
2
0
1.1k
Aug ’24
App Sandbox entitlement stripped from dext by Xcode?
I have a macOS app which contains a dext. I'd like to distribute it to external testers using TestFlight, so it has to pass Mac App Store review. It failed, because the App Sandbox entitlement was missing. I checked the app, it has the entitlement, but the dext does not. However, the .entitlements file used by the dext does contain App Sandbox set to true. I tried adding a "fake-entitlement" value to the .entitlements file, and that made it into the dext's code signature, but the App Sandbox entitlement appears to be stripped out by the build process? For a dext target, it isn't possible to add the App Sandbox capability in Xcode's Signing and Capability section. I have to add the entitlement manually in the .entitlement file (or it was put there by the Xcode driver template, I don't remember). I've tried clean building several times, I've tried Xcode 15.0.1, 15.2 and 15.3, but the result is always the same. I'm inspecting the entitlements using codesign -dvvv --entitlements - Does anyone know what I can do to put the App Sandbox entitlement into my dext's signature? Is this happening to anyone else?
4
2
1.3k
Jul ’24
is com.apple.developer.usb.host-controller-interface managed?
I'm posting this here after reading Quinn's post here: https://developer.apple.com/forums/thread/799000 The above entitlement is mentioned in IOUSBHostControllerInterface.h. It isn't an entitlement one can add using the + button on the Capabilities panel in Xcode. If I try to add it by hand, Xcode complains that it isn't in my profile. Is this a managed entitlement? We'd like to create a local USB "device" to represent a real device reachable over a network.
Replies
7
Boosts
1
Views
953
Activity
5d
USB HID Digitizer support on macOS
I'm investigating supporting a touchscreen digitizer on macOS. I'd like to receive multi-touch reports from the device, and have them intercepted by my app. I also want to suppress the default absolute positioning 'mouse' behavior of the touch screen. The device exposes three HID interface: #0 - multi-touch (PrimaryUsagePage 0xD, PrimaryUsage 4) #1 - vendor-specific #2 - single-touch (PrimaryUsagePage 1, PrimaryUsage 2) I've only been able to achieve half of my goal using a HIDDriverKit dext - I can outmatch the OS for the single-touch HID interface and ignore its 7-byte single-touch reports. However, although I can match to the multi-touch interface, I never see any reports at all there, as if the OS never polls the interrupt endpoint. On Windows, the device "just works" - I've traced its behavior in Wireshark. The OS doesn't do any special setup, it sends no SET_FEATURE commands, it just reads from the multi-touch interrupt endpoint, where it receives 54-byte reports. Windows doesn't even get any 7-byte single-touch reports. On macOS, I managed to use Wireshark on an old Intel Mac, where I can still use XHC20 for logging. Here, macOS tries to read from all the interrupt endpoints for all the HID interfaces, and the digitizer only responds on the single-touch interface. MSDN's documentation for multi-touch support is quite unhelpful here, because it just says "use the OS driver", but doesn't detail how a digitizer switches between multi-touch and single-touch mode. If I were making a digitizer, I'd send reports on both interfaces, expecting the OS to read the single- or multi-touch interface as required. Although unlikely, it seems that this digitizer changes its behavior based on how it is accessed. I can outmatch the USB interface for the single-touch reports, so that the OS HID driver doesn't even see it. That doesn't change the device behavior. The HIDDriverKit APIs I use imply setting up an interrupt read. I call Open on the interface, and implement a ReportAvailable callback. This works for the single-touch interface, but I get no reports on the multi-touch interface. All the calls with return values return kIOReturnSuccess. Does anyone know how multi-touch digitizers switch between single- and multi-touch mode (if indeed they have a mode at all), or why macOS apparently doesn't even read the multi-touch interrupt end point? Does anyone know how I can ensure that my HID driver actually reads the interrupt endpoint on the HID interface it is matched to? Does macOS deliberately prevent access to multi-touch HID interfaces?
Replies
2
Boosts
0
Views
156
Activity
6d
Identifiers - what do the icons mean?
On the Certificates, Identifiers and Profiles section of the Account section of developer.apple.com, if you manually configure the Capabilities of an App Identifier, there are icons with no tooltips. Does anyone know what they mean? (I'm particularly interested in the two different icons shown in my screenshot, with the same name)
Replies
1
Boosts
0
Views
141
Activity
1w
how to inhibit -fprofile-instr-generate passed to linker
I'm struggling to build a driver for iPadOS in a particular project configuration. If I put the driver code and dext target into the same Xcode project which contains the iPad app, all is well. This is the way the Xcode driver template does it. However, I'd like to build and debug the dext on macOS, while eventually deploying on iPadOS. So I put the dext into a different project, which has a macOS target, a minimal iPadOS target and a DriverKit target. I made a workspace which contains both projects. I dragged the macOS project into the iPadOS project so that I can refer to the products of the macOS project (specifically, its driver target) as a dependency of the iPadOS target. Note that the main iPad app target depends on the driver target. So the workspace organization looks like this: Workspace iPad project main iPad app target (depends on driver) test project reference test project test macOS/iPad app target DriverKit dext target When I build the iPadOS target, it builds the dependent driver target in the macOS project, but it fails to link because Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a is not found. If I just build the driver target directly in Xcode, there is no such complaint. I looked closely at the build logs, and I see for the failed link, there are these two linker flags set which are not set in the successful case -debug_variant -fprofile-instr-generate I can't seem to control the generation of this flag. I tried turning off the Profile switch in the Scheme editor for the driver, but is makes no difference. When I directly build the driver target, no -fprofile-instr-generate is set and it compiles and links. When i build the driver as a dependency of another target, -fprofile-instr-generate is passed to the linker, which fails. The obvious workaround is to put the driver source code into a separate driver target in the iPadOS project, but I'd rather have just one DriverKit driver for both platforms, with a few settings (such as bundle ID) controlled by a configuration file. Has anyone else encountered this problem, and know of a workaround?
Replies
3
Boosts
1
Views
1.5k
Activity
Mar ’26
is the output frame rate of a CMIOExtension rounded or capped?
I made a CMIOExtension (a virtual camera) which generates its own output, for use in our in-house software testing. I wanted to make a video source with 29.97, 30, 59.94 and 60fps output. To this end, I created a CMIOExtensionDeviceSource which creates a CMIOExtensionDevice with one CMIOExtensionStreamSource with various stream formats contained in [CMIOExtensionStreamFormat], including one with both maxFrameDuration and minFrameDuration = CMTimeMake(value: 1000, timescale: 30000) and another with both maxFrameDuration and minFrameDuration = CMTimeMake(value: 1001, timescale: 30000) I've held off on the creation of the 59.94/60fps source for now until this problem is resolved. my virtual camera works, it produces a signal, but when I examine its associated AVCaptureDevice in the debugger, I find (lldb) po self.captureDevice?.formats[0].videoSupportedFrameRateRanges[0].maxFrameDuration ▿ Optional<CMTime> ▿ some : CMTime - value : 1000000 - timescale : 30000000 ▿ flags : CMTimeFlags - rawValue : 1 - epoch : 0 I get the same value, 1000000/30000000, or exactly 30fps, for all the formats of my AVCaptureDevice. Is there something I'm doing wrong, or do CMIOExtensionDevices always round the frame rates? I can't force CoreMediaIO to produce frames at exactly my desired frame interval, but I'd like to ensure that the average frame rate is my desired rate. How can I do that? Frame emission is governed by a repeating DispatchSourceTimer with a repeat time specified in nanoseconds with the TimerFlags set to 'strict'.
Replies
2
Boosts
0
Views
906
Activity
Jan ’26
Should UserSendCBD work on UAS interfaces?
The device I am trying to develop a firmware updater for is an NVMe drive with a USB4 interface. It can connect in USB4 mode (tunneled NVMe), in USB 3 mode or in USB 2 mode. In USB 2 and USB 3 mode, the device descriptor shows one interface with two alternates. Alternate 0 uses the bulk-only protocol, with one IN and one OUT pipe. Alternate 1 uses the UAS protocol, with two IN and two OUT pipes. I use identical code in my driver to send custom CDBs. I can see using IORegistryExplorer that in USB 2 mode, macOS chooses alternate 0, the bulk-only protocol. My custom CDBs and their accompanying data pay loads are put on the bus, more or less as expected. In USB 3 mode, macOS chooses alternate 1, the UAS protocol. My custom CDB is put on the bus, but no payload data is transferred. Is this expected behavior? If so, is there a way to force the OS to choose alternate 0 even when on USB 3, perhaps with another dext? I'll file a bug about this when Feedback Assistant lets me.
Replies
8
Boosts
0
Views
521
Activity
Oct ’25
PCIDriverKit entitlements during development
I'm trying to help out one of our vendors by building a skeleton PCI dext which they can flesh out. However, I can't seem to get the signing right. I can't sign it at all using no team or my personal team. "Signing for requires a development team", and "Personal development teams ... do not support the System Extension capability". I can't sign the driver because "DriverKit Team Provisioning Profile: doesn't match the entitlements file's value for the com.apple.developer.driverkit.transport.pci entitlement. I think this problem occurs because our company has already been assigned a transport.pci entitlement, but for our own PCI vendor ID. But I want to build and test software that works with our vendor's PCI device. I tried generating a profile for the driver manually, it contained only our own company's PCI driver match: IOPCIPrimaryMatch = "0x0000MMMM&0x0000FFFF"; where MMMM is our own PCI vendor ID. Is there a better way to inspect the profile Xcode is using than the postage-stamped sized info popup which truncates the information? I would download the generated profile but it doesn't appear on the profile, but Xcode is accessing it from somewhere. When I look at the available capabilities I can add to an app identifier on the Developer portal, I see com.apple.developer.driverkit.transport.usb, which is "development only". There's no "development only" capability for PCI. Does this mean it isn't possible to develop even a proof-of-concept PCI driver without being first granted the DriverKit PCI (Primary Match) entitlement? When adding capabilities to a driver, the list of available capabilities shown in Xcode has one "DriverKit PCI (Primary Match) entry", but if I double click it, two such entries appear in the Signing and Capabilities tab for my driver target. On the Developer portal, when I look at my driver's Identifier, there are two Capabilities labelled DriverKit PCI (Primary Match). Why?
Replies
7
Boosts
0
Views
1.5k
Activity
Oct ’25
limitations of UserSendCDB in SCSIPeripheralsDriverKit?
I've made a dext and a user client that overrides IOUserSCSIPeripheralDeviceType00, with the object of writing device firmware to the driver. I can gain and relinquish exclusive access to the device, I can call UserReportMediumBlockSize and get back a sensible answer (512). I can build command parameters with the INQUIRY macro from IOUserSCSIPeripheralDeviceHelper.h and send that command successfully using UserSendCB, and I receive sensible-looking Inquiry data from the device. However, what I really want to do is send a WriteBuffer command (opcode 0x3B), and that doesn't work. I have yet to put a bus analyzer on it, but I don't think the command goes out on the bus - there's no valid sense data, and the error returned is 0xe00002bc, or kIOReturnError, which isn't helpful. This is the code I have which doesn't work. kern_return_t driver::writeChunk(const char * buf, size_t atOffset, size_t length, bool lastOne) { DebugMsg("writeChunk %p at %ld for %ld", buf, atOffset, length); SCSIType00OutParameters outParameters; SCSIType00InParameters response; memset(&outParameters, 0, sizeof(outParameters)); memset(&response, 0, sizeof(response)); SetCommandCDB(&outParameters.fCommandDescriptorBlock, 0x3B, // byte 0, opcode WriteBuffer command lastOne ? 0x0E : 0x0F, // byte 1 mode: E=save deferred, F = download and defer save 0, // byte 2 bufferID (atOffset >> 16), // byte 3 (atOffset >> 8), // byte 4 atOffset, // byte 5 (length >> 16), // byte 6 (length >> 8), // byte 7 length, // byte 8 0, // control, byte 9 0, 0, 0, 0, 0, 0); // bytes 10..15 outParameters.fLogicalUnitNumber = 0; outParameters.fBufferDirection = kIOMemoryDirectionOut; outParameters.fDataTransferDirection = kSCSIDataTransfer_FromInitiatorToTarget; outParameters.fTimeoutDuration = 1000; // milliseconds outParameters.fRequestedByteCountOfTransfer = length; outParameters.fDataBufferAddr = reinterpret_cast<uint64_t>(buf); uint8_t senseBuffer[255] = {0}; outParameters.fSenseBufferAddr = reinterpret_cast<uint64_t>(senseBuffer); outParameters.fSenseLengthRequested = sizeof(senseBuffer); kern_return_t retVal = UserSendCDB(outParameters, &response); return retVal; }
Replies
3
Boosts
0
Views
685
Activity
Sep ’25
Xcode fails to provision target
I've alluded to this before in these posts and there are some posts from others about this, e.g. https://developer.apple.com/forums/thread/759845 and I've filed some bugs related to the behavior. FB20212935 FB19451832 FB19450508 FB19450162 FB19449747 Our company owns the USB vendor IDs X and Y . We've been granted a USB transport entitlement for both of those IDs. The crux of the problem is that I want to build a driver for USB vendor ID Y. Xcode's well-hidden auto-generated provisioning profile for my driver contains com.apple.developer.driverkit.transport.usb: { idVendor = X; } which is obviously not what I want. Xcode fails to provision the target. But I have another, much older project with an auto-generated provisioning profile containing com.apple.developer.driverkit.transport.usb: { idVendor = X; }, { idVendor = Y; } I can build a driver for idVendor Y without problems in this project. But that doesn't help me with my new project. What can I do to fix this? Do I need to request our entitlements again? I fear if I do so, something will get lost in the process. Is there a way to inspect what we have already been granted? - I can't see a "managed entitlements" section on the account portal. I can go through the motions of making a new App ID, then I can see that some Capability Request have been "Assigned", but I don't see what their values are. A second question I have is about the userclient-access entitlement. Are these tied to the bundle ID of the app which claims the access? In other words, if I have two drivers com.mycompany.app1.driver1 com.mycompany.app2.driver2 and I would like to have com.mycompany.app1 communicate with com.mycompany.app1.driver1, I would ask for the com.apple.developer.driverkit.userclient-access capability for com.mycompany.app1.driver1. But must I request that access for each specific app bundle ID that will talk to that driver, or once the entitlement is granted, can I use com.apple.developer.driverkit.userclient-access = { com.mycompany.app1.driver1 } in any of my apps?
Replies
1
Boosts
0
Views
436
Activity
Sep ’25
How do I use IOUserSCSIPeripheralDeviceType00?
I am having similar problems to this guy on Stack Overflow over a year ago: https://stackoverflow.com/questions/77627852/functions-of-iouserscsiperipheraldevicetype00-class-in-scsiperipheralsdriverkit There are also a few questions on this forum about this object, none of which have answers. I can get my driver to match and instantiate, but nobody calls my UserDetermineDeviceCharacteristics (which does nothing, just returns kIOReturnSuccess) I can attempt to call UserSuspendServices(), UserResumeServices() or UserReportMediumBlockSize() and all of them return kIOReturnUnsupported. It doesn't matter if I've unmounted the disk or not. Is the custom driver supposed to be instantiated beside the kernel's IOSCSIPeripheralDeviceType00, or should it replace it? What should its IOProviderClass be? What should its IOClass be - IOUserService, or something else? see FB19678139 and FB19677920
Replies
5
Boosts
0
Views
356
Activity
Sep ’25
CoreAudio HAL plugin vs dext
The presentation "create audio drivers with DriverKit" from WWDC 2021 demonstrates how to use a dext to implement a virtual audio driver. It also says " If a virtual audio driver or device is all that is needed, the audio server plug-in driver model should continue to be used". Indeed, in AudioDriverKit/AudioDriverKitTypes.h, there is no IOUserAudioTransportType Virtual, although CoreAudio/AudioHardwareBase.h includes kAudioDeviceTransportTypeVirtual. For one of our products, we require virtual devices to implement a software loopback "cable". We've implemented this using the "traditional" HAL plugin, and as a proof-of-concept, also using a dext. In the dext, I tried setting the transport type to 'virt', which seems to only have the effect of changing the icon shown in Audio Midi Setup. HAL plugins require an installer, and the installer has to kill coreaudiod in a post-install script. You have to turn off SIP to debug them. Just like AudioDriverKit drivers, they are out-of-process and run in a process not owned by the hosting app. Our HAL plugin's interface is property based; we had to write a lot of boiler-plate code to implement required properties. Writing an AudioDriverKit driver is in most respects easier - a lot of the scaffolding is implemented in the base driver, which we only alter where required. Debugging and installation is much easier. The dext works just fine, as far as we can ascertain, just as well as a HAL plugin. So, my question is - is the advice to use a HAL plugin for a virtual device still correct in 2025? And if so, what's the objection? We'd really prefer to ship the AudioDriverKit virtual audio device.
Replies
2
Boosts
1
Views
608
Activity
Mar ’25
Swift Testing environment differences from regular executable
I am working on a Swift package which uses CoreAudio, and includes some tests in a testTarget which use the Testing framework, and a couple of executableTarget targets which exercise the same code. I'm using Xcode 16.2 on macOS 15.3.1. One of the things I do in the test code is create a HAL plugin, then find that plugin using the kAudioHardwarePropertyTranslateUIDToDevice. Finding the plugin that I just created always fails from within a Swift Testing test, unless I run the test which creates the plugin individually first, then separately, run the test which finds the plugin, by clicking on the little arrows next to the function names. If I put the tests in a serialized suite (so creation always happens first, then finding), running the suite always fails - it creates the plugin, but can't find it. If I run the 'find my plugin' test again manually, it is always found. If I call the same functions from a regular executable (the thing created by a "executableTarget" in my .package.swift file), the just-created plugin is always found. Is there a way to mimic the runtime environment of a regular executable in a Swift Testing target, or am I misunderstanding something? this my be related to this issue: https://github.com/swiftlang/swift/issues/76882 but I don't understand it well enough to be sure.
Replies
4
Boosts
0
Views
681
Activity
Feb ’25
DriverKit target built as dependency, header not found
I have an Xcode project with a main app target, and a dext target which builds a DriverKit driver which is embedded in the main app. That all works, if I build the DriverKit target first, then switch to the app target and build that. The app and the driver work. If I make the Driver target a dependency of the App target, building the Driver fails because a header is not found, thus building the app fails. This doesn't make much sense - why does building a target as a consequence of dependence on another target produce a different result from building the same target manually? Has anyone else seen behavior like this? Have any hints on how to fix it? I've tried comparing the detailed build logs, but they don't shed much light - the lines are very long and the build steps appear to be executed in a different order. One strange thing I notice is that although I am building on an M1 Mac, with "build active architectures only" set to YES for both targets, in the Driver-target-only case, Driver.cpp is compiled for arm64, while in the failure case, Driver.cpp is compiled for x86_64. That doesn't make any sense to me either.
Replies
1
Boosts
0
Views
727
Activity
Sep ’24
USB drive invisible to our app on supervised iPad
We have an iPad app which can write to user-specified locations on USB-connected storage devices. On unmanaged devices, this works just fine. However, when the device is under MDM, although the Files app can see the external USB storage device, it does not show up in the file browser in our own app. There's a restriction called "allowFilesUSBDriveAccess" which is set to true (the default), but there's no restriction called "allowOtherAppsUSBDriveAccess". Are MDM-managed iPads simply not allowed to access USB drives (except through the Files app)?
Replies
2
Boosts
0
Views
1.1k
Activity
Aug ’24
App Sandbox entitlement stripped from dext by Xcode?
I have a macOS app which contains a dext. I'd like to distribute it to external testers using TestFlight, so it has to pass Mac App Store review. It failed, because the App Sandbox entitlement was missing. I checked the app, it has the entitlement, but the dext does not. However, the .entitlements file used by the dext does contain App Sandbox set to true. I tried adding a "fake-entitlement" value to the .entitlements file, and that made it into the dext's code signature, but the App Sandbox entitlement appears to be stripped out by the build process? For a dext target, it isn't possible to add the App Sandbox capability in Xcode's Signing and Capability section. I have to add the entitlement manually in the .entitlement file (or it was put there by the Xcode driver template, I don't remember). I've tried clean building several times, I've tried Xcode 15.0.1, 15.2 and 15.3, but the result is always the same. I'm inspecting the entitlements using codesign -dvvv --entitlements - Does anyone know what I can do to put the App Sandbox entitlement into my dext's signature? Is this happening to anyone else?
Replies
4
Boosts
2
Views
1.3k
Activity
Jul ’24