[Success] Hp Elitebook 8570w 99% QM77 i7-3720QM Quadro K2000M

[RehabMan]

The only things different about that boot compared to the boot from the previous problem report, is nv_disable=1 is added to the boot arguments, and that I renamed SSDT-1.aml to SSDT-GFX1.aml as per your suggestion. It's still reading it since GFX1 is still in IORegistryExplorer. Nothing else was changed.

My guess is that it is not pulling it in due to @0 having the property of "NVDA,NVMac" injected, and NVDA being disabled this time with nv_disable=1.

I've attached a problem report of the system without nv_disable=1.

I would not recommend the DGFX._STA trick.
Just rename DGFX->GFX1 with config.plist/ACPI/DSDT/Patches.
And then you will probably also need the _DSM->XDSM patch to avoid OEM _DSM methods in native ACPI.

 

[Mezmaron]

To clear up the confusion I may have caused, I've restored the SSDT-GFX1.aml file to the one I had with the EDID properly injected, and updated problem reports are attached. I totally forgot that I screwed with it more.

30227 is with nv_disable=1, and 10005 is with NVDA.

 

[Mezmaron]

I would not recommend the DGFX._STA trick.
Just rename DGFX->GFX1 with config.plist/ACPI/DSDT/Patches.

I'm currently dropping all OEM tables. If I attempt this patch, I want to then keep the OEM tables, correct? And I would also want to omit the SSDT-GFX1.aml I made?

And then you will probably also need the _DSM->XDSM patch to avoid OEM _DSM methods in native ACPI.

Is this also done in config.plist, or in the ACPI files?

 

[RehabMan]

I'm currently dropping all OEM tables.

config.plist/ACPI/SSDT/DropOem=true is a bad idea.
And you should not be injecting CStates/PStates (Generate/CStates, Generate/PStates should be false).

 

[Mezmaron]

Just rename DGFX->GFX1 with config.plist/ACPI/DSDT/Patches.
And then you will probably also need the _DSM->XDSM patch to avoid OEM _DSM methods in native ACPI.

config.plist/ACPI/SSDT/DropOem=true is a bad idea.
And you should not be injecting CStates/PStates (Generate/CStates, Generate/PStates should be false).

I have these changes ready to go. Do I want to also use the smart merge?

 

[RehabMan]

I have these changes ready to go. Do I want to also use the smart merge?

config.plist/ACPI/AutoMerge=true only matters if you have patched SSDTs in ACPI/patched (note: "add-on" SSDTs are not "patched" SSDTs).

 

[Mezmaron]

config.plist/ACPI/AutoMerge=true only matters if you have patched SSDTs in ACPI/patched (note: "add-on" SSDTs are not "patched" SSDTs).

Do I also want to omit my SSDT-GFX1.aml patch? Would it conflict with the new patches in config.plist, or would it still help to inject the EDID?

If I have to inject the EDID in config.plist instead, what are the other values I need to put in, in regards to these screenshots from the EDID section from your backlight guide? Such as the ProducrID, PciRoot, ig-platform-id, and device-id? I know that I'll have to insert my EDID into the AAPL00, but that's about it.

 

[RehabMan]

Do I also want to omit my SSDT-GFX1.aml patch? Would it conflict with the new patches in config.plist, or would it still help to inject the EDID?

If I have to inject the EDID in config.plist instead, what are the other values I need to put in, in regards to these screenshots from the EDID section from your backlight guide? Such as the ProducrID, PciRoot, ig-platform-id, and device-id? I know that I'll have to insert my EDID into the AAPL00, but that's about it.

View attachment 360870
View attachment 360871

SSDT-GFX1.aml is your add-on SSDT for injecting HDAU, related properties, and Nvidia specific properties on GFX1.
Nothing wrong with injecting EDID via ACPI (SSDT-GFX1.aml), but that may not be the actual cause of your problem.

 

[Mezmaron]

SSDT-GFX1.aml is your add-on SSDT for injecting HDAU, related properties, and Nvidia specific properties on GFX1.
Nothing wrong with injecting EDID via ACPI (SSDT-GFX1.aml), but that may not be the actual cause of your problem.

Could the internal display issue be a missing or incorrect framebuffer for the internal display? I noticed that normally the frame buffer for all ports is called "NVDA". But when booted with nv_disable=1, the internal one is called ".Display_boot" while the others are called "IONDRVFramebuffer". Perhaps there's a property I need to add into my SSDT-GFX1.aml that distinguishes this as an internal display, either something related to the framebuffer, or something else entirely.

 

[RehabMan]

Could the internal display issue be a missing or incorrect framebuffer for the internal display? I noticed that normally the frame buffer for all ports is called "NVDA". But when booted with nv_disable=1, the internal one is called ".Display_boot" while the others are called "IONDRVFramebuffer". Perhaps there's a property I need to add into my SSDT-GFX1.aml that distinguishes this as an internal display, either something related to the framebuffer, or something else entirely.

Completely different drivers are used (VESA/base drivers) when you disable the Nvidia drivers.
You can't really compare ioreg from one to the other.