views:

160

answers:

1

In Mac OS X, every display gets a unique CGDirectDisplayID number assigned to it. You can use CGGetActiveDisplayList() or [NSScreen screens] to access them, among others. Per Apple's docs:

A display ID can persist across processes and system reboot, and typically remains constant as long as certain display parameters do not change.

On newer mid-2010 MacBook Pro's, Apple started using auto-switching Intel/nVidia graphics. Laptops have two GPU's, a low-powered Intel, and a high-powered nVidia. Previous dual-GPU laptops (2009 models) didn't have auto-GPU switching, and required the user to make a settings change, logoff, and then logon again to make a GPU switch occur. Even older systems only had one GPU.

There's an issue with the mid-2010 models where CGDirectDisplayID's don't remain the same when a display switches from one GPU to the next. For example:

  1. Laptop powers on.
  2. Built-In LCD Screen is driven by Intel chipset. Display ID: 30002
  3. External Display is plugged in.
  4. Built-In LCD Screen switches to nVidia chipset. It's display ID changes: 30004
  5. External Display is driven by nVidia chipset.
  6. ...at this point, the Intel chipset is dormant...
  7. User unplugs External Display.
  8. Built-In LCD Screen switches back to Intel chipset. It's display ID changes back to original: 30002

My question is, how can I match an old display ID to a new display ID when they alter due to a GPU change?


Thought about:

I've noticed that the display ID only changes by 2, but I don't have enough test Mac's available to determine if this is common to all new MacBook Pro's, or just mine. Kind of a kludge if "just check for display ID's which are +/-2 from one another" works, anyway.


Tried:

CGDisplayRegisterReconfigurationCallback(), which notifies before-and-after when displays are going to change, has no matching logic. Putting something like this inside a method registered with it doesn't work:

// Run before display settings change:
CGDirectDisplayID directDisplayID = ...;
io_service_t    servicePort = CGDisplayIOServicePort(directDisplayID);
CFDictionaryRef oldInfoDict = IODisplayCreateInfoDictionary(servicePort, kIODisplayMatchingInfo);

// ...display settings change...

// Run after display settings change:
CGDirectDisplayID directDisplayID = ...;
io_service_t    servicePort = CGDisplayIOServicePort(directDisplayID);
CFDictionaryRef newInfoDict = IODisplayCreateInfoDictionary(servicePort, kIODisplayMatchingInfo);
BOOL match = IODisplayMatchDictionaries(oldInfoDict, newInfoDict, 0);

if (match)
    NSLog(@"Displays are a match");
else
    NSLog(@"Displays are not a match");

What's happening above is:

  1. I'm caching oldInfoDict before display settings change.
  2. Waiting for display settings to change
  3. Then comparing oldInfoDict to newInfoDict by using IODisplayMatchDictionaries()
  4. IODisplayMatchDictionaries() returns a BOOL, either YES they're the same, or NO they're different.

Unfortunately, IODisplayMatchDictionaries() doesn't return YES if the same display changed GPU's. Here's an example of the dictionary's it's comparing (look at the IODisplayLocation key):

// oldInfoDict  (Display ID: 30002)
oldInfoDict: {
    DisplayProductID = 40144;
    DisplayVendorID = 1552;
    IODisplayLocation = "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/IGPU@2/AppleIntelFramebuffer/display0/AppleBacklightDisplay";
}

// newInfoDict  (Display ID: 30004)
newInfoDict: {
    DisplayProductID = 40144;
    DisplayVendorID = 1552;
    IODisplayLocation = "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/P0P2@1/IOPCI2PCIBridge/GFX0@0/NVDA,Display-A@0/NVDA/display0/AppleBacklightDisplay";
}

As you can see, the IODisplayLocation key changes when GPU's are switched, hence IODisplayMatchDictionaries() doesn't work.

I can, theoretically, compared just the DisplayProductID and DisplayVendorID keys, but I'm writing end-user software, and am worried of a situation where users have two or more identical monitors plugged in (meaning they'll both have the same DisplayProductID/DisplayVendorID). In other words, it's a less-than-perfect solution open to potential glitches.


Any help is greatly appreciated! :)

+1  A: 

While I'm no pro, I believe the answer is to allow Apple to notify you when the user changes displays. The info inf the callback contains flags for adding and removing CGDirectDisplayIDs.

The user shouldn't be adding or removing graphics cards during operation, so I would play with making list at startup, and whenever you get the "remove" flag set the next "add" operation to replace that ID in the list.

I'd try just printing the information you get back each time CGDisplayRegisterReconfigurationCallback calls your function. See if you get one with a DeviceUID with a 'remove' flag, and then a subsequent call another with an 'add' flag. Checking those id's against CGGetActiveDisplayList would also aid in understanding what's going on.

That's my best bet, hope it helps!

Stephen Furlani
Thanks Stephen. Sadly, the notification's don't have anything saying "DisplayID ABC has now become DisplayID XYZ".What I've found out since posting this question is display ID's can change dynamically at runtime at any time. For example, if you launch Adobe Photoshop CS4, mid-2010 MacBook Pro's switch from Intel integrated graphics to nVidia discrete graphics. This makes sense since Photoshop CS4+ is GPU intensive. However, the displayID for your monitor changes during GPU-switches. Once you exist Photoshop, it falls back to the Intel GPU, and the displayID changes again. Fun! :)
Dave Gallagher
True, but you should still get one callback for the remove ID and one for the add ID, no?
Stephen Furlani