Patching connector flag 0x10 on desktop configurations

NanoSector commented 5 years ago

While debugging HDMI Audio issues on my Haswell desktop using an i5 4570/HD4600 and platform-id 0x0D220003, I noticed one of the connectors had flags 0x11 set for it while the other two had flags 0x87 set for them; all are natively DisplayPort ports, I patched them to be HDMI ports.

Seeing as the port with flags 0x11 was never recognised as an HDMI Audio device, I decided to remove the flags from it (set it to 0x0). Suddenly, it was recognised as an audio device!

It appears, at least on my system, flag 0x10 (CNUnknownFlag_10 as reported by Hackintool) has two effects as far as I'm aware:

The port number is set to 0x0. This is typical for LVDS/internal connectors.
Audio seems to be disabled?

In fact, looking at framebuffer dumps, all LVDS connectors seem to have flag 0x10 set. This leads me to believe that this flag is used somewhere as an indicator of an internal connector.

Further evidence is that certain iMacs use a DP connector with flag 0x10 set, while other DP ports on those iMacs are flagged differently. I think that means that this connector is specifically used for the internal LCD on those iMacs.

The fact that this flag seems to at least disable HDMI audio for that connector seemed like an issue. Perhaps this should be documented somewhere or incorporated as a patch?

vit9696 commented 5 years ago

Sorry for a slow reply, I was quite occupied with the stuff.

This is a very interesting find, did you try checking the driver logic to understand what exactly the bit does? I think that enabling it unconditionally may be no good as it may easily break many laptops (and I am not sure how), but naming & documenting probably is a good idea.

NanoSector commented 5 years ago

Unfortunately I am all but experienced so I wouldn’t have any idea where to start with checking the driver logic. The best of my abilities is toggling switches right now :P

Edit: Re-reading my original post, there is one item I left out:

I tried setting flag 0x10 for all of my 3 connectors (I have 3 displays attached). This works perfectly fine for 1 and even 2 displays (I did not expect that), but it kernel panics either when you have a third display plugged in on boot, or when hot plugging it. Unfortunately I don’t have the KP log anymore but if it’s needed I can trigger it again, it’s a consistent one.

Therefore I don’t think unconditionally _en_abling it is a good idea, I think you meant unconditionally _dis_abling?

07151129 commented 5 years ago

Can you share the panic log?

NanoSector commented 5 years ago

Sure, attached is a kernel panic log from the early boot panic. kp_0x10.txt

NanoSector commented 5 years ago

And here is one from a hot plug for the third monitor: kp_0x10_hotplug.txt

vit9696 commented 5 years ago

Um, could you at least add keepsyms=1 to boot arguments? We are not too happy to solve these panics logs.

And this looks like low Stolen Memory value in BIOS config.

NanoSector commented 5 years ago

I’m sorry! I’ll retake the logs with keepsyms=1 and also try to up the memory in my BIOS, it was set to 64MB.

Another interesting thing I noted is that the system will not cleanly shut down (KP) or reboot when no connectors have flag 0x10 set; perhaps this is why Mac Minis share a platform-id with MacBook Airs? I’ll add a panic log of this as well.

NanoSector commented 5 years ago

I've set my Intel graphics memory to 96M right now. Seems to make no difference in this case.

Instant reboot with 3 monitors attached: kp_0x10.txt

Hotplug kernel panic on plugging in third monitor: kp_0x10_hotplug.txt

Kernel panic on reboot without any displays having 0x10 set: kp_none_0x10.txt

vit9696 commented 5 years ago

To be honest, I do wonder whether it is actually 0x10 and not 0x1. We checked the database with @07151129, and this panic log is a bit cryptic:

"/Library/Caches/com.apple.xbs/Sources/GPUDriversIntel/GPUDriversIntel-10.30.14/Common/IONDRV/Intel/HSW/AppleIntelFramebuffer/AppleIntelController.cpp:17135 Assertion failed: E_FBMEMTYPE_NONE != pfbInfo->eMemType \n".

My suspect, based on AppleIntelFramebufferController::FBMemMgr_AllocSysMem logic, is that for LVDS displays this SysMem gets allocated, which is not desired for this assertion. But I honestly do not see any reference for 0x10. Perhaps it needs to be known, but I am quite a bit reluctant to add anything I do not understand at all.

NanoSector commented 5 years ago

Perhaps because there are no “internal” displays left marked with 0x10 (assuming this is partly what it marks based on the assumptions in my OP) it doesn’t allocate the memory at all and thus E_FBMEMTYPE_NONE is the value of the eMemType, failing that assertion?

I took another look at the Framebuffer dumps from headkaze and most platform ids for Haswell have at least one LVDS or DP connector with flag 0x10, save for the connector less ids and two other ids where the usage is marked as unknown. Maybe this flag is something specific to haswell?

If you have suggestions for flags to try or things to check then I’ll be happy to provide more panic logs if they occur.

realgudv1n commented 3 years ago

Hello!

My hardware specs: Intel Core i7-4790K ASUS Maximus VII Impact (Z97) HD 4600 (0x0d220003)

I was debugging HDMI too. Firstly, I set connector-type to HDMI and connector-pipe to 12. With this configuration, I have working HDMI hotplug and HDMI sound issue.

I tried this combo flags (table in the bottom). But, I haven't received worked HDMI hotplug and sound at the same time.

0x17 w/o hotplug, w/ sound 0x6 w/o hotplug, w/ sound 0x7 w/o hotplug, w/ sound 0x16 w/ hotplug, w/o sound 0x3 w/o hotplug, w/ sound 0x13 w/ hotplug, w/o sound 0x2 w/o hotplug, w/ sound 0x4 w/o hotplug, w/ sound 0x82 w/o hotplug, w/ sound 0x87 w/o hotplug, w/ sound 0x107 w/o hotplug, w/ sound 0x0 w/o hotplug, w/ sound 0x1 w/o hotplug, w/ sound 0x10 w/ hotplug, w/o sound 0x12 w/ hotplug, w/o sound 0x14 w/ hotplug, w/o sound

I noticed:

CNUnknownFlag_10 is present - Hotplug does work! HDMI Audio doesn't work. CNUnknownFlag_10 not present - hotplug doesn't work! HDMI Audio does work.

laszlo-t commented 2 years ago

Hello @vit9696, I run into the same issue as @Yoshi2889 on Haswell HD4600 and wasted some days to find out what's happening here. I think CNUnknownFlag_10 is responsible for making the screen built-in.

Here is my example:

CNUnknownFlag_10 is disabled

        <key>framebuffer-con1-enable</key>
        <data>AQAAAA==</data>
        <key>framebuffer-con1-type</key>
        <data>AAgAAA==</data>
        <key>framebuffer-con1-flags</key>
        <data>BwAAAA==</data>

External display, supported rotation, HDMI audio:

CNUnknownFlag_10 is enabled

        <key>framebuffer-con1-enable</key>
        <data>AQAAAA==</data>
        <key>framebuffer-con1-type</key>
        <data>AAgAAA==</data>
        <key>framebuffer-con1-flags</key>
        <data>FwAAAA==</data>

Built-in display, no rotation, no HDMI audio:

In fact, looking at framebuffer dumps, all LVDS connectors seem to have flag 0x10 set. This leads me to believe that this flag is used somewhere as an indicator of an internal connector.

I also agree on this and it confirms our theory.

naming & documenting probably is a good idea.

@vit9696 I support this idea. Could you rename the CNUnknownFlag_10 to something like CNBuiltInDisplay and write a comment that it disables the audio and rotation?

acidanthera / bugtracker

Patching connector flag 0x10 on desktop configurations #442