No graphics / USB / Audio after wake

[Micky1979]

No desktop PC has switchable graphics (that I know of). Apple has both GPUs enabled in the iMac, but the IGPU is "hidden" (by using a platform ID with no connectors, which makes it disappear from System Information/Graphics). The iMac doesn't have a GMUX device, and doesn't have switchable graphics (though it does actually use the IGPU, mainly for QuickSync H.264 encoding with AirPlay/FaceTime).

Probably is no longer possible, but it was

[TheRacerMaster]

Probably is no longer possible, but it was

gfxCardStatus is for MacBooks Pros (which do have switchable graphics / a GMUX device).

[Slice]

 

I also observed that the primary display always gets the "AAPL,boot-display" property, on real Macs with IPGU and/or discrete GPU. This is also true for an hackintosh with onboard graphics but on an hackintosh with an AMD GPU as the primary display this property is missing, no matter what you selected in BIOS setup. You might think that this is just a cosmetic issue but I think it's not. Searching through the source code of IOGraphics.kext that Apple published, I found these lines of code in IOBootFramebuffer.cpp:

 

@Slice: Do you know how OS X detects the primary display adapter?

 

Mieze

Clover does inject this property.

AtiDevProp ati_devprop_list[] = {
	{FLAGTRUE, FALSE, "@0,AAPL,boot-display", get_bootdisplay_val, NULVAL }, 

 You have a choice. Inject->ATI = true or false.

You may set false and got graphics fully working (resolutions, QE/CI, DVD play) but in this case you have no some properties like this one.

You may set true. But in this case you should make a patch for connectors to have an output to screen while in the first case the output will be found automatically.

There is a trick to not make all property as Clover do but inject anyway some custom properties:

	<key>Devices</key>
	<dict>
		<key>NoDefaultProperties</key>
		<true/>
		<key>AddProperties</key>
		<array>
			<dict>
				<key>Device</key>
				<string>ATI</string>
				<key>Key</key>
				<string>@0,AAPL,boot-display</string>
				<key>Value</key>
				<data>AQAAAA==</data>
			</dict>

Anyway as I already said this is not the way to resolve wake problem. We tested hundreds of variants.

This is my ioreg

[Mieze]

@Slice: Sorry, I forgot to mention that I disabled graphics injection in Clover completely. I'm injecting graphics device properties, including "@0,AAPL,boot-display", in the DSDT but it doesn't help. On the other hand this property get's created automatically by OS X when using HD4600 onboard graphics which tells me that the lack of this property is not the cause but the result of a failure in an earlier stage of booting.

 

Mieze

[Fl0r!an]

My real MacPro (#91) also doesn't have this APPL,boot-display property when running a stock PC card, and still it wakes...

[Slice]

@Slice: Sorry, I forgot to mention that I disabled graphics injection in Clover completely. I'm injecting graphics device properties, including "@0,AAPL,boot-display", in the DSDT but it doesn't help. On the other hand this property get's created automatically by OS X when using HD4600 onboard graphics which tells me that the lack of this property is not the cause but the result of a failure in an earlier stage of booting.

 

Mieze

Real Mac got this property by EfiAppleDeviceProperty protocol. It means prepared by EFI BIOS.

[Mieze]

Real Mac got this property by EfiAppleDeviceProperty protocol. It means prepared by EFI BIOS.

 

So far, so good, but this still doesn't explain why it gets created automatically by OS X on a hack with IGPU only.

 

Mieze

[wern apfel]

Look at this BIOS picture, if i choose "UEFI OpROM" instead legacy i have no wakeup with init first IGPU

 

[TheRacerMaster]

Ah, interesting. That might explain why wakeup is not working for me (even though IGPU is set to Primary), I keep the CSM disabled (full UEFI since GPU has UEFI GOP).

[Mieze]

Look at this BIOS picture, if i choose "UEFI OpROM" instead legacy i have no wakeup with init first IGPU

If I choose Legacy instead of UEFI OpROM, I get a kernel panic on boot. 

 

Mieze

[Slice]

Look at this BIOS picture, if i choose "UEFI OpROM" instead legacy i have no wakeup with init first IGPU

 

BIOS.png

I think this is not related because the graphics card got a signal to wake. Exclude, for example, AMD6000Controller. The screen will wake up. All preconditions are fulfilled including BIOS and ACPI.

The problem that the kext will not wake FB because ....

 

 

Ah, interesting. That might explain why wakeup is not working for me (even though IGPU is set to Primary), I keep the CSM disabled (full UEFI since GPU has UEFI GOP).

 

As me. UEFI only, CSM disabled. All is fine in 10.9.5. 

And no, it doesn't explain why.

 

PS. Meanwhile we have a dependency on IntelGFX 

[Slice]

Hey,

I found a difference with real Mac.

My hardware is like a iMac12,2 that also has Radeon Turks series but mobile.

It also has integrated IntelHD3000 graphics with deviceID=0x0102 that has support in kexts.

I disabled the Intel graphics in BIOS and exclude it from DSDT. Anyway, I see two graphics cards in System Profiler.

I looks at real iMac12,2 and there is only Radeon graphics presents. Why? 

The answer is in PCI space.

My Intel has class-code=0x030000 as normal graphics.

Real mac has class-code=0x038000 as disabled graphics.

At least I can inject this property. Will test this evening.

		<key>AddProperties</key>
		<array>
			<dict>
				<key>Device</key>
				<string>IntelGFX</string>
				<key>Key</key>
				<string>class-code</string>
				<key>Value</key>
				<data>AIADAA==</data>
			</dict>
 

Is this value in PCI space writable? It will be more correct method.

[Mieze]

Hey,

I found a difference with real Mac.

My hardware is like a iMac12,2 that also has Radeon Turks series but mobile.

It also has integrated IntelHD3000 graphics with deviceID=0x0102 that has support in kexts.

I disabled the Intel graphics in BIOS and exclude it from DSDT. Anyway, I see two graphics cards in System Profiler.

I looks at real iMac12,2 and there is only Radeon graphics presents. Why? 

The answer is in PCI space.

My Intel has class-code=0x030000 as normal graphics.

Real mac has class-code=0x038000 as disabled graphics.

At least I can inject this property. Will test this evening.

 

Is this value in PCI space writable? It will be more correct method.

 

The class code register is read only, but its value may be changed through a configuration register on some Intel CPUs. For Haswell CPUs, this is register GMCH Graphics Control Register which can be locked so that it's uncertain if the BIOS leaves it in a writable state. I attached the data sheet as a reference. SandyBridge and IvyBridge CPUs might be similar, but I haven't checked.

 

EDIT: I can confirm that this register also exists in SB and IB CPUs and has a similar function.

 

Unfortunately class-code=0x0380000 is only found on SandyBridge machines like my iMac 12,1 but on IB and Haswell based Macs it's still 0x030000, at least on those I checked (iMac13,1, iMac14,2 and iMac15,1).

 

Mieze

4th-gen-core-family-desktop-vol-2-datasheet.pdf

Edited November 20, 2015 by Mieze

[Slice]

Thanks, Mieze!

I see GMCH byte 0x50 bit 1 = 1 then class-code will be 0x038000. If the bit is not locked by bit 0.

I may check this and I hope on DeviceProperties injection.

 

About iMac13,1 users have a success with wake up if Intel HD4000 graphics works and the display is primary. They have normal class-code.

Strange.

In my old dump I see lspci output says that @0x50==0x03. Already done? And this old report contains only Radeon graphics.

New dump

50: 11 02 00 00 

[Mieze]

One more thing: If the IGPU is enabled this also means that it claims VGA memory and I/O cycles. As a result of that any attempt to access the AMD GPU using these methods will fail. I don't know if the driver still uses the legacy registers, but it would be an explanation.

 

In my old dump I see lspci output says that @0x50==0x03. Already done? And this old report contains only Radeon graphics.

New dump

50: 11 02 00 00 

GMCH Graphics Control Register set to 0x3 means that the register is locked, IGPU VGA access is disabled and that there is no memory preallocated for the IGPU.

 

Mieze

[Vlada.]

I can confirm also that wakeup is working properly when I switch on internal graphics first option in BIOS. 

 

I’m using DSDT patch for Intel HD3000, but my SMBIOS is MP6,1 for which I was made, additional MacPro6,1.plist file as a support for Sandy Bridge CPU. This file is inserted inside ACPI_SMC_PlatformPlugin.kext which is part of the IOPlatformPluginFamily.kext and its purpose is to set up properly GPU and P-State values in this combination.

 

I’ll leave this file here, because someone might want to check it. 

 

All in all, the system is working properly that way, except the fact that this is not the right solution. 

MacPro6_1.plist.zip

[Mieze]

Ran a few more tests on my Asrock B85 Killer and got the following results:

• IGPU selected as primary device: IGPU class-code 0x030000
• PCIe selected as primary device: IGPU class-code 0x038000

In both cases, no wakeup which means that the VGA access doesn't have any influence on wakeup.

 

Mieze

[buoo]

Meize did you try disabling the IGPU device into DSDT?

 

Name (_STA, Zero)

[Mieze]

Meize did you try disabling the IGPU device into DSDT?

 

Name (_STA, Zero)

No, because it's still needed by OS X, but I might try this later.

 

EDIT: Tried it but it still doesn't wakeup. 

 

Mieze

Edited November 20, 2015 by Mieze

[Slice]

I want to disable intel graphics but I can't with any BIOS manipulations.

class-code is always 0300

[Vlada.]

That’s unusual, but you probably wouldn’t get much with that. In my case internal graphics is disabled and I still have the same problem, even with Name (_STA, Zero) inserted in DSDT, which successfully eliminate IGPU from the system.

[Slice]

I have an observation.

It was initially in ElCapitan but I still didn't understand what is happen.

See.

I have Mavericks fully working with fully working AMD Radeon HD6670 with Clover settings:

Inject=true

FBName=Ipomoea

AMD6000Controller patch for connectors

Additional cosmetic properties.

All is fine.

Now there is ElCapitan. Black screen. Why? Connector patch is not changed because IpomoeaFB was not changed.

My DeviceID=0x6758 is native for both systems.

Why it is not working in ElCapitan???

Follow workaround:

1. Set FakeID=0x67401002. It is the ID that presents in real iMac12,2 and this is the same chip Turks as in my case.

2. Inject->ATI=false

It works. It fully works... except wake up. Because there is Inject=false.

 

Trying to resolve wake up issue I made hundreds reboots with different setting, with and without different drivers, with all possible BIOS settings.

And I notice that I can boot into ElCapitan WITH Inject=true. How? What is changed?

There is no wake up because Intel graphics has no support.

When I revert Intel kexts back and fall into the issue again: I can't boot with Inject=true. Why????

The question is "Why reverting Intel Graphics drivers I can't boot with Inject->ATI=true?".  What is the dependency?

 

 

So I want to propose the follow:

AMD will wake if both graphics devices will be injected and worked.

There must be no "OOB" devices.

[Mieze]

I have another approach to find out what exactly the dependency is. The MacPro6,1 is equipped with a Radeon D300, which is basically a Radeon R9 270X according to its device ID. Unlike the iMac, it doesn't have Intel graphics but instead you can find device GCON and its driver AppleMGPUPowerControl.kext, which is in turn a plugin of AppleGraphicsControl.kext. Compared in size and complexity with the Intel graphics drivers, this driver is tightly structured and it seems to take the Intel driver's part when it comes to wakeup on these machines. If we can figure out how it helps the AMD driver to wake up, then we know what the Intel driver has to do on other machines with IGPU.

 

Mieze 

[Fl0r!an]

Now there is ElCapitan. Black screen. Why? Connector patch is not changed because IpomoeaFB was not changed.

My DeviceID=0x6758 is native for both systems.

Why it is not working in ElCapitan???

On my system this started to happen with 10.10.3 or 10.10.4 update. GPU is a R9 280 which matches Hamachi framebuffer. On my current Yosemite install, it will boot to black screen when when injecting that framebuffer, but the screen will come to live after sleeping & waking the machine. I also verified this with other Radeon graphics.

 

In El Capitan it behaves the same, except that I can't verify if waking the machine would enable display ( ).

[wern apfel]

@Slice the IvyBridge GPU can be disabled by platform-id not sure if SandyBridge too, you don't see the IGPU in systemprofiler only in ioreg.

There is a difference which Fb you choose

 

@Mieze, no success with DevicePolicy loaded (EDID added)