OS X WindowServer: No matching context for device (xxxxx) on real mac

Question

I have a Macbook Air 13" (2017 model, base 1.8Ghz) and I wanted to see if I could run Mavericks on it. The 2017 model is identical to the 2015 save the upgraded processor and different Board-ID (Mac-937CB26E2E02BB01). Its Board-ID isn't whitelisted until Sierra 10.12.4 or something. I could go as far back as 10.10.3 (added support for 2015 macbook airs) and run fully supported with just a platformsupport.plist patch, but I wanted to go further. Keep in mind that Yosemite and Mavericks are very similar in terms of architecture (very few changed kernel functions) AppleIntelBDWGraphics is the driver for Broadwell Intel HD 6000.

It has a Broadwell chip, and of course the 10.9.5 kernel does not whitelist it and so it would refuse to start. Using this helpful post (https://pikeralpha.wordpress.com/2013/06/11/xnu-10-8-3-haswell-compatibility/) I found the files I needed to edit to add support for Broadwell. I downloaded the OS X xnu source from here: opensource.apple.com/tarballs/xnu/xnu-2422.115.4.tar.gz

and got to work. I added the relevant information, and finally compiled a kernel and Mavericks booted. (Of course after also editing PlatformSupport.plist and whitelisting my board-id) mavericks-on-mba2017

However, virtually everything didn't work. The keyboard backlight worked, the Broadcom bcm4360 worked, and that was it. The keyboard and trackpad are spi, and after simply copying the relevant kexts (applehsspihidriver, etc) from 10.10.3 (the first os to include them) and kextloading them, the keyboard and trackpad worked as if they were native to Mavericks. The AppleIntelBDWGraphics and related drivers didn't work, however. (Also pulled from 10.10.3) AppleIntelBDWGraphicsFramebuffer did load, and that gave me CI (CoreImage) support, but not the much sought-after translucent menubar (Quartz Extreme-related) and so I got to work. Just invoking kextutil immediately gave me what went wrong:

$ sudo kextutil AppleIntelBDWGraphics.kext
Diagnostics for /System/Library/Extensions/AppleIntelBDWGraphics.kext:
Code Signing Failure: code signature is invalid
WARNING - Invalid signature -67061 0xFFFFFFFFFFFEFA0B for kext "/System/Library/Extensions/AppleIntelBDWGraphics.kext"
(kernel) kxld[com.apple.driver.AppleIntelBDWGraphics]: The following symbols are unresolved for this kext:
(kernel) kxld[com.apple.driver.AppleIntelBDWGraphics]:  _IOLockWakeup_darwin14
(kernel) kxld[com.apple.driver.AppleIntelBDWGraphics]:  _gpu_accumulate_time
(kernel) kxld[com.apple.driver.AppleIntelBDWGraphics]:  _gpu_describe
(kernel) Can't load kext com.apple.driver.AppleIntelBDWGraphics - link failed.

I could easily fix IOLockWakeup_darwin14, as a quick google search confirmed my suspicions that IOLockWakeup is identical and that truncating darwin14 would cause no harm. I hex edited the executable, and that reduced my unresolved symbols to just _gpu_accumulate_time and _gpu_describe. After going back to the source and tracking down the relevant code to osfmk/kern/energy_perf.c in Darwin 14.0.0 (Yosemite) I then painstakingly copied all necessary files to resolve those 2 symbols and then by hand corrected compiler errors. Once the kernel (finally) compiled, I immediately tested it and indeed the symbols were resolved, as the kext loaded:

$ sudo kextutil AppleIntelBDWGraphics.kext
Diagnostics for /System/Library/Extensions/AppleIntelBDWGraphics.kext:
Code Signing Failure: code signature is invalid
WARNING - Invalid signature -67061 0xFFFFFFFFFFFEFA0B for kext "/System/Library/Extensions/AppleIntelBDWGraphics.kext"

$ kextstat | grep AppleIntel
   14    0 0xffffff7f808e7000 0x2b000    0x2b000    com.apple.driver.AppleIntelCPUPowerManagement (217.92.1) <7 6 5 4 3 1>
   24    0 0xffffff7f809a3000 0x3000     0x3000     com.apple.driver.AppleIntelCPUPowerManagementClient (217.92.1) <7 6 5 4 3 1>
   36    1 0xffffff7f80a58000 0x8000     0x8000     com.apple.driver.AppleIntelLpssDmac (2.0.57) <11 10 5 4 3>
   37    1 0xffffff7f80a60000 0xa000     0xa000     com.apple.driver.AppleIntelLpssGspi (2.0.57) <11 10 7 5 4 3>
   43    1 0xffffff7f80b28000 0x14000    0x14000    com.apple.driver.AppleIntelLpssSpiController (2.0.57) <37 36 10 5 4 3>
   78    0 0xffffff7f81248000 0x54000    0x54000    com.apple.driver.AppleIntelBDWGraphicsFramebuffer (10.0.6) <77 76 75 18 11 10 7 6 5 4 3 1>
  111    0 0xffffff7f81689000 0x79000    0x79000    com.apple.driver.AppleIntelBDWGraphics (10.0.6) <110 76 75 11 7 6 5 4 3 1>

I won't go into too much detail of how and what files I edited in the source code yet, because there is still one problem: QE (Quartz Extreme) still doesn't work in the GUI. Quickly checking Console.app reveals why:

10/2/17 9:19:36.687 PM WindowServer[523]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7ff91241e030) - disabling OpenGL

Another google search doesn't reveal anything helpful. All links relate to simply silencing the messages, and they have to do with those USB DisplayLink monitors that obviously don't have QE/CI drivers written for them. However, I am using a supported graphics card with a loaded kext, and I wanted to see if it was possible to binary patch WindowServer or something like that to manually enable support for my device. Thank you.

I wasn't sure which one to put it on but this is rather more programming related than just power-user stuff. I may be wrong, but I think it's better here as I'm directly modifying kernel-mode stuff. — Daniel Rodriguez, Oct 03 '17 at 01:32

score 0 · Answer 1 · answered Oct 03 '17 at 11:29

I have no idea what you're trying to do is even possible to achieve within reasonable effort. I'm going to assume you have an excellent reason why the more obvious solutions of using VMs, older hardware, using a Mavericks-Supported GPU in a Thunderbolt enclosure, etc. won't do…

One thing to check for though is whether the appropriate WindowServer plugins are loaded. For acceleration to work, the userspace part of the driver also needs to be loaded into any process that uses it, including WindowServer. For Broadwell, this should be

/System/Library/Extensions/IOAccelerator2D.plugin/Contents/MacOS/IOAccelerator2D
/System/Library/Extensions/AppleIntelBDWGraphicsGLDriver.bundle/Contents/MacOS/AppleIntelBDWGraphicsGLDriver

On 10.11 and newer there's a Metal one as well of course, but that won't help you on Mavericks.

You can check if they're loaded by opening Activity Monitor as root and inspecting the "Open Files and Ports" for the WindowServer process. If not, that's likely where your problem lies. Of course, there are lots of possible reasons why the plugin(s) might not be loading. The most obvious and easily fixable one is if you didn't copy the userspace driver bundle across. Then there's the deployment target with which it was built - that can probably be circumvented if necessary. Of course, it's possible they changed the WindowServer<->GL plugin interfaces between 10.9 and 10.10, in which case you're in for a rough ride.

OS X WindowServer: No matching context for device (xxxxx) on real mac

1 Answers1