to anyone who reads this, the solution is “easy” (after four freakin’ hours!!):
there are two issues, both stemming from disagreements between CoreFoundation and IOKit: 1. a collision with the return type of the “random” function in libkern/libkern.h and C’s stdlib.h, which is an easy fix. > #define CF_EXCLUDE_CSTD_HEADERS 1 2. another collision between the collision comes from CoreFoundation (specifically CoreFoundation/CFBase.h) including MacTypes.h, which we do not need since the IOKit headers will, by their nature, include everything on their own. so, we define the CF_OPEN_SOURCE macro to avoid including MacTypes: > #define CF_OPEN_SOURCE 1 at this point, you can include CoreFoundation/CoreFoundation.h without issue, but not CoreMIDI/CoreMIDI.h as it looks for two typedefs from MacTypes.h: > typedef unsigned long ByteCount; > typedef unsigned long ItemCount; put this all together and we have > #define CF_OPEN_SOURCE 1 > typedef unsigned long ByteCount; > typedef unsigned long ItemCount; > #include <CoreMIDI/CoreMIDI.h> which allows us to build the kext with both the CoreMIDI and IOKit headers included. this fix seems reasonably-safe and i’m hopeful there aren’t going to be issues when i actually start using the library, but we shall see. i thought this would be worth sharing because someone else had the exact same collision but for a different source, and the solution wasn’t really given there (https://github.com/dart-lang/ffigen/pull/193) i hope this helps any reader experiencing these kinds of collisions. Thanks, Gagan > On Dec 11, 2022, at 1:05 PM, Gagan Sidhu via Coreaudio-api > <[email protected]> wrote: > > someone shared some helpful information regarding CoreMIDI and also some code > for a USB device using it. > > however, i don’t think that can work here. > > after some preliminary testing, i’m not sure i can implement MIDI in a PCI > device. > > there are header conflicts between IOKit/pci/IOPCIdevice.h and CoreMIDI/*.h > > this is disappointing, but right now i’m getting header conflicts. > >> Showing All Messages >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:228:7: >> Functions that differ only in their return type cannot be overloaded >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/MacTypes.h:287:41: >> Typedef redefinition with different types ('UnsignedWide' vs 'UInt64' (aka >> 'unsigned long long')) >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/MacTypes.h:309:41: >> Typedef redefinition with different types ('unsigned char' vs 'bool') >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/MacTypes.h:596:9: >> Unknown type name 'wide' >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/MacTypes.h:689:9: >> Unknown type name 'wide' >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/MacTypes.h:708:1: >> Conflicting types for 'Debugger' > > > relevant includes are: > >> #include <IOKit/pci/IOPCIDevice.h> >> #include <CoreMIDI/MIDIServices.h> >> #include <IOKit/audio/IOAudioControl.h> >> #include <IOKit/audio/IOAudioLevelControl.h> >> #include <IOKit/audio/IOAudioToggleControl.h> >> #include <IOKit/audio/IOAudioDefines.h> >> #include <IOKit/audio/IOAudioPort.h> > > i recall getting this kind of error early-on (with other headers) but > obviously it got resolved. i’m hoping there is something similar i can do > this time. > > i don’t know if it’d be possible to communicate with the CFBundle in an > interrupt context the way apple is suggesting. > > i am thinking CoreMIDIServer.h is what i need, but unsurprisingly there is no > header in the frameworks directory. > > i’ll keep you guys updated, but there has to be a way around this. of course > apple would make it difficult given their direction in the past 2+ years. > > midi in a pci audio device is too obvious of a “need” > > Thanks, > Gagan > >> On Dec 11, 2022, at 7:08 AM, Gagan Sidhu via Coreaudio-api >> <[email protected]> wrote: >> >> hi again all, >> >> before i begin my testing, i wanted to ask about handling rudimentary MIDI >> calls. >> >> the documentation reads: >> >>> "Note: MIDI device drivers are not I/O Kit drivers. The MIDI device driver >>> model is based on the CFPlugIn architecture and typically loads a CFPlugIn >>> bundle from /System/Library/Extensions or Library/Audio/MIDI Drivers. >>> >>> For MIDI devices that cannot be directly addressed from a user-space device >>> driver (for example, a MIDI interface built into a PCI card), you must >>> split your driver into two parts: an I/O Kit device driver that matches >>> against the device and a CFPlugIn bundle that manipulates the I/O Kit >>> driver using a user client.” >> >> (https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/WritingAudioDrivers/AudioOnMacOSX/AudioOnMacOSX.html#//apple_ref/doc/uid/TP30000730-TPXREF103) >> >> this is exactly the case i’m trying to handle, but i’m not sure if a >> PCIAudioDevice driver is considered user-space or not. >> -this may sound like a noobish confession, but i understand this line >> is drawn differently for BSD and Linux, and i don’t know where exactly it >> was at the time these docs were writen. >> -i do know that the newer (bad) SampleIOAudioDevice (from >> wwdc21) driver highlights being more “user-space”, so maybe a driver written >> for IOKit is considered “kernel space” >> >> anyways, i have a MIDI device that should be accessible within the device >> driver, as Clemens does here with the creation of am MPU401 device: >> >> https://elixir.bootlin.com/linux/v4.14.298/source/sound/pci/oxygen/oxygen_lib.c#L702 >> >> i have googled around the terms “ioaudiodevice” and midi, only to find >> nothing. >> >> the OS-X and Kernel Programming book by halvorson and clarke says: >> >> "Core MIDI / MIDI Server framework contains APIs for working MIDI.” >> >> i was hoping one of the readers could point me to some documentation that >> may be helpful on this topic. i am hopeful the midi/uart interface can be >> dealt with inside the driver. >> >> and if it can’t, i am hoping this bundle i’d need to write wouldn’t be that >> bad. but i already have all of the uart stuff put in the right spot, so it’s >> just a matter of having a way to handle a uart interrupt on the workloop for >> a midi device. >> >> see the interrupt handling for the driver here: >> https://elixir.bootlin.com/linux/v4.14.298/source/sound/pci/oxygen/oxygen_lib.c#L117 >> >> >> i just converted this function to the IOWorkLoop-equivalent. >> >> >> Thanks, >> Gagan >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Coreaudio-api mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/coreaudio-api/broly%40mac.com >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/broly%40mac.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
