[solved] Skylake Framebuffer Patch Not Sticking

[KNNSpeed]

Hi,

I'm trying to make a Clover binary patch for AppleIntelSKLGraphicsFramebuffer to patch the port layout on my Dell XPS 15 9560. The config.plist is in the attached zip, and I must be missing something because the eDP patch right above the framebuffer patch works, and I'm trying to do a similar thing.

I've also noticed that ioreg reports my framebuffer@1 and framebuffer@2 connector-types as HDMI ports (00 08) instead of DisplayPorts (00 04) as I would expect given the framebuffer data stored in AppleIntelSKLGraphicsFramebuffer. Any ideas what might be causing ioreg to not match the SKL framebuffer driver? (That's why I think the patch is not being applied.)

Also, I know in the past on AMD cards doing this framebuffer hackery was necessary for video output. Is there any point in doing this to the Intel GPU (like, will it help with HDMI audio/negate the need to spoof board-ids in AppleGraphicsDevicePolicy)?

EDIT: Basically I'm trying to turn this:

00001B19 00000000 5D880800 00000000 01030303 00002002 00005001 00000060 6C050000 6C050000 00000000 00000000 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00040000 87010000 FF000000 01000000 20000000 0F110000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 C0411C00 00000000 C0421C00 00000000 10431C00 00000000 01000000 08000000 01000000 00000000

into this

00001B19 00000000 5D880800 00000000 01030303 00002002 00005001 00000060 6C050000 6C050000 00000000 00000000 00000800 00040000 98000000 01050900 00080000 87010000 02040A00 00040000 87010000 FF000000 01000000 20000000 0F110000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 C0411C00 00000000 C0421C00 00000000 10431C00 00000000 01000000 08000000 01000000 00000000

in AppleIntelSKLGraphicsFramebuffer, but it seems like there's something else going on that I'm not accounting for. :/

 

[RehabMan]

Hi,

I'm trying to make a Clover binary patch for AppleIntelSKLGraphicsFramebuffer to patch the port layout on my Dell XPS 15 9560. The config.plist is in the attached zip, and I must be missing something because the eDP patch right above the framebuffer patch works, and I'm trying to do a similar thing.

I've also noticed that ioreg reports my framebuffer@1 and framebuffer@2 connector-types as HDMI ports (00 08) instead of DisplayPorts (00 04) as I would expect given the framebuffer data stored in AppleIntelSKLGraphicsFramebuffer. Any ideas what might be causing ioreg to not match the SKL framebuffer driver? (That's why I think the patch is not being applied.)

Also, I know in the past on AMD cards doing this framebuffer hackery was necessary for video output. Is there any point in doing this to the Intel GPU (like, will it help with HDMI audio/negate the need to spoof board-ids in AppleGraphicsDevicePolicy)?

EDIT: Basically I'm trying to turn this:

00001B19 00000000 5D880800 00000000 01030303 00002002 00005001 00000060 6C050000 6C050000 00000000 00000000 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00040000 87010000 FF000000 01000000 20000000 0F110000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 C0411C00 00000000 C0421C00 00000000 10431C00 00000000 01000000 08000000 01000000 00000000

into this

00001B19 00000000 5D880800 00000000 01030303 00002002 00005001 00000060 6C050000 6C050000 00000000 00000000 00000800 00040000 98000000 01050900 00080000 87010000 02040A00 00040000 87010000 FF000000 01000000 20000000 0F110000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 C0411C00 00000000 C0421C00 00000000 10431C00 00000000 01000000 08000000 01000000 00000000

in AppleIntelSKLGraphicsFramebuffer, but it seems like there's something else going on that I'm not accounting for. :/

Your framebuffer patch cannot work because you're including data that has fix-ups. It is changed from 00000 by the time the kext loads/links, so the pattern does not match.

You need to reduce the data to the part without any fixups.

I think you're just trying to change the 0105 connector to HDMI.

Find: 01050900 00040000 87010000
Replace: 01050900 00080000 87010000

Note: This patch is nonsense: '10.12.2 fudge USB 3.1 device ID'. You don't have any such device that this patch applies to...

 

[KNNSpeed]

Hmm. I was trying to condense 3 patches into one.
1. Display connector to eDP from LVDS.
2. HDMI as you said.
3. This, once I get an answer to my question in this thread.

The fudge USB 3.1 device ID is in preparation for this. Dell hard powers on/powers off the type C connector as-needed, much like what Linux has to work with to enable thunderbolt support for Macs with Thunderbolt 1 and 2 connectors. From what I understand the fudging patch is needed as part of a set to keep the connector powered up.

 

[RehabMan]

Hmm. I was trying to condense 3 patches into one.
1. Display connector to eDP from LVDS.
2. HDMI as you said.

The patch you have is not an LVDS->eDP patch (it is LVDS->DP).
You could combine the DP->HDMI and LVDS->DP patch you have as follows...
Find: 00000800 02000000 98000000 01050900 00040000 87010000
Replace: 00000800 00040000 98000000 01050900 00080000 87010000

And if you really wanted eDP:
Find: 00000800 02000000 98000000 01050900 00040000 87010000
Replace: 00000800 04000000 98000000 01050900 00080000 87010000

3. This, once I get an answer to my question in this thread.

Use separate patch. The target data of the two patches has too much other data between (which may have fixups).

The fudge USB 3.1 device ID is in preparation for this. Dell hard powers on/powers off the type C connector as-needed, much like what Linux has to work with to enable thunderbolt support for Macs with Thunderbolt 1 and 2 connectors. From what I understand the fudging patch is needed as part of a set to keep the connector powered up.

Assuming you have a thunderbolt controller... Probably the device will not show unless you plug something into it prior to booting.

 

[KNNSpeed]

Thanks, slimming it down did the trick. Ultimately, with the framebuffer patch on the HDMI port, I'm trying to get HDMI audio to work. Here's a new set of problem reporting files if you'd like to take a look. Per your guide, everything seems to be showing up correctly in ioreg. :/

Note: Just so you know, I plan to open a new thread about the huge DSDT patch I have in config.plist; it's about fixing an odd thing that Dell did that breaks USB.

Assuming you have a thunderbolt controller... Probably the device will not show unless you plug something into it prior to booting.

Yes, the aim's to get hotplug working, though. I think it can be done. I already know USB-C hotplug can be made to work to a limited degree, and IIRC there're a couple people working on Thunderbolt.

 

[RehabMan]

Thanks, slimming it down did the trick. Ultimately, with the framebuffer patch on the HDMI port, I'm trying to get HDMI audio to work. Here's a new set of problem reporting files if you'd like to take a look. Per your guide, everything seems to be showing up correctly in ioreg. :/

Try without FakePCIID_Intel_HDMI_Audio.kext.

Note: Just so you know, I plan to open a new thread about the huge DSDT patch I have in config.plist; it's about fixing an odd thing that Dell did that breaks USB.

Such large patches not recommended.
What is the issue you're trying to address?
It may be better addressed with the "Rename and Replace" pattern as per my ACPI hotpatch guide...
Or with USBInjectAll.kext and custom SSDT...
FYI: Your ioreg shows USB is not correct at all.

Yes, the aim's to get hotplug working, though. I think it can be done. I already know USB-C hotplug can be made to work to a limited degree, and IIRC there're a couple people working on Thunderbolt.

Yes... there are few threads around... At this point, I don't have really any TB devices (just USB adapters, and a USB-C -> DP).
Removing _RMV is a good start, I suppose.
I think there may be a dependency on NHI0 name we see in real Mac TB ioreg/ACPI.

 

[KNNSpeed]

Try without FakePCIID_Intel_HDMI_Audio.kext.

No dice. It also stops my speakers from outputting any volume (despite the fact that macOS volume control thinks they work).

Such large patches not recommended.
What is the issue you're trying to address?
It may be better addressed with the "Rename and Replace" pattern as per my ACPI hotpatch guide...
Or with USBInjectAll.kext and custom SSDT...
FYI: Your ioreg shows USB is not correct at all.

See https://www.tonymacx86.com/forums/sierra-laptop-support.188/
(I was just loading the vanilla DSDT for this boot)

Yes... there are few threads around... At this point, I don't have really any TB devices (just USB adapters, and a USB-C -> DP).
Removing _RMV is a good start, I suppose.
I think there may be a dependency on NHI0 name we see in real Mac TB ioreg/ACPI.

Removing _RMVs caused hardlocks. I'd rather rename them and make them do something else than outright remove them.
I do also have both Thunderbolt and USB-C devices to test with, so it'll be interesting.

 

[RehabMan]

No dice. It also stops my speakers from outputting any volume (despite the fact that macOS volume control thinks they work).

Put FakePCIID_Intel_HDMI_Audio.kext back.
Try injecting different (valid) values for RM,device-id.

See https://www.tonymacx86.com/forums/sierra-laptop-support.188/
(I was just loading the vanilla DSDT for this boot)

I replied there.

Removing _RMVs caused hardlocks. I'd rather rename them and make them do something else than outright remove them.
I do also have both Thunderbolt and USB-C devices to test with, so it'll be interesting.

Renaming is the same as removing.

 

[KNNSpeed]

        <key>Intel HDMI Audio - 100-series 0xa171</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>org.rehabman.driver.FakePCIID</string>
            <key>FakeProperties</key>
            <dict>
                <key>RM,device-id</key>
                <data>
                cJ0AAA==
                </data>
            </dict>
            <key>IOClass</key>
            <string>FakePCIID</string>
            <key>IOMatchCategory</key>
            <string>FakePCIID</string>
            <key>IOPCIPrimaryMatch</key>
            <string>0xa1718086</string>
            <key>IOProviderClass</key>
            <string>IOPCIDevice</string>
        </dict>

Sir, you are a legend. It works now.
Thanks!

 

[RehabMan]

        <key>Intel HDMI Audio - 100-series 0xa171</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>org.rehabman.driver.FakePCIID</string>
            <key>FakeProperties</key>
            <dict>
                <key>RM,device-id</key>
                <data>
                cJ0AAA==
                </data>
            </dict>
            <key>IOClass</key>
            <string>FakePCIID</string>
            <key>IOMatchCategory</key>
            <string>FakePCIID</string>
            <key>IOPCIPrimaryMatch</key>
            <string>0xa1718086</string>
            <key>IOProviderClass</key>
            <string>IOPCIDevice</string>
        </dict>

Sir, you are a legend. It works now.
Thanks!

Instead of modifying the kext, you should inject RM,device-id (usually done with _DSM in ACPI).
FakePCIID is designed to be flexible/configurable that way...