The following code sequence works on Catalina and on Intel Big Sur devices, it does not work on the new Apple M1 devices running Big Sur.
CFMutableDictionaryRef matching = IOServiceMatching("IODisplayConnect");
io_iterator_t iter = 99;
kern_return_t err = IOServiceGetMatchingServices( kIOMasterPortDefault, matching, &iter );
The "matching" variable seems valid:
matching CFMutableDictionaryRef 1 key/value pair
[0] "IOProviderClass" : "IODisplayConnect"
		key __NSCFConstantString * "IOProviderClass"
		value __NSCFString * "IODisplayConnect"
The call to "IOServiceGetMatchingServices" sets the "iter" value to 0.
If I use another class name in the "IOServiceMatching" call, say "IOMediaBSDClient", "IOServiceGetMatchingServices" returns a valid iterator.
Would Big Sur on Apple M1 devices need additional calls, or has this service class been deprecated?
Using "IODisplayConnect" allows me to get display information via "IODisplayCreateInfoDictionary".
Suggestions...
alanfromtewksbury
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Can anyone provide an example (preferably in C++) of how to read the EDID data for the current display?
I can do it on an Intel based Mac, the same code does not work on the new Apple M1 devices. The Intel code looks something like:
CFMutableDictionaryRef matching = IOServiceMatching("IODisplayConnect");
io_iterator_t iter = 99;
kern_return_t err = IOServiceGetMatchingServices( kIOMasterPortDefault, matching, &iter );
io_service_t serv;
serv = IOIteratorNext( iter );
CFDictionaryRef displayInfo;
displayInfo = IODisplayCreateInfoDictionary( serv, kIODisplayOnlyPreferredName );
( . . . )
It appears that the new Apple M1 devices have a new video architecture, so the IOServiceMatching / IOServiceGetMatchingServices on longer works.
For normal testing I build an application using Xcode and selecting "Build for Profiling" from the Product menu.
For production I do
"xcodebuild clean build -configuration Release ......."
I notice a big performance difference.
In my case the XCode profiling build runs in under a minute, the xcodebuild version takes over 4 minutes.
The XCode profiling build uses the Release configuration, the xcodebuild is also using the Release configuration.
What additional configuration options are being set/used when "Building for Profiling"?
I'm having a hard time finding an answer to this question.