Contribute
Register

[Release] Hackintool v3.x.x

What I think would be really useful is if we could understand what pipe is exactly and why setting it to 0x12 prevents a KP. I made a post about it here. If my theory is correct and the first two bits are for pipe A, B, C and D with bit 3 sometimes set then your value of 0x12 would be no different to setting it to 0x0A (Pipe C) and 0x18 would be the same as 0x08 (Pipe A).
The value 0x12 comes from existing framebuffer data where some HDMI connectors use 0x12.
So bit 4 probably has some meaning, otherwise Apple would not use it.
 
The value 0x12 comes from existing framebuffer data where some HDMI connectors use 0x12.
So bit 4 probably has some meaning, otherwise Apple would not use it.

I don't think the bit is used anymore. None of the frames in Haswell have it set by default in Mojave.
 
I don't think the bit is used anymore. None of the frames in Haswell have it set by default in Mojave.

Two possibilities:
- the bit means nothing assuming the code for it was removed
OR
- the bit is just not used anymore in the new framebuffer data

Difficult to know which.
Testing both ways to see if a difference is measurable is something reasonable to do.
 
Testing both ways to see if a difference is measurable is something reasonable to do.

It would be useful if @toleda could try with this bit unset to see if it makes a difference. So bit 4 may be unused but bit 3 is still used for something. The rest of the bits (I'm guessing) refer to pipe A, B, C and D. Understanding the pipe value would certainly be valuable info to know.
 
Just going through IntelFramebuffer.bt and Pike's blog post I'm not so sure the pipe value determines A, B, C or D anymore.

So let's have a look at Mojave's values for pipe for all Intel gen's.
Code:
Pipe|Bits|Type(s)
3   |0011|DP, HDMI
8   |1000|DP, LVDS
9   |1001|DP, HDMI, DigitalDVI
10  |1010|DP, HDMI
11  |1011|DP

According to IntelFramebuffer.bt the ConnectorType (LVDS, HDMI, DP etc.):
Interestingly connector type is not so important nowadays, e.g. VGA works fine on Kaby on DP.
As of SKL and newer ConnectorType is converted to fPortType by the following algo:
- connector with zero index (LVDS) gets fPortType 3.
- connector with ConnectorHDMI type gets fPortType 1.
- otherwise a connector has fPortType 2 (DisplayPort-like).

So from this if we look at some of Pike's output we have:
Code:
IG:: MapFBToPort:1756 Map fb0 -> Port A (fPortType=3)
IG:: MapFBToPort:1756 Map fb1 -> Port B (fPortType=2)
IG:: MapFBToPort:1756 Map fb2 -> Port C (fPortType=1)

According to this output eDP must use Port A:
Code:
IG:: %s:%d The final Pipe is not A\n
IG:: %s:%d Pipe A is not eDP\n
IG:: %s:%d return (Pipe A is already taken)\n

So it looks like Port A, B or C is determined by fPortType which is determined by ConnectorType.

So what is the pipe value? According to IntelFramebuffer.bt it:
Appears to be used for grouping ports just like Piker says, but I cannot find the usage.
 
So let's have a look at Mojave's values for pipe for all Intel gen's.
Code:
Pipe|Bits|Type(s)
3 |0011|DP, HDMI
8 |1000|DP, LVDS
9 |1001|DP, HDMI, DigitalDVI
10 |1010|DP, HDMI
11 |1011|DP
Clearly, an HDMI connector on Pipe 8 is not supported. Note, Console showed IA-32 errors at the time or two I saw the crash happen.
If interested, I can test Pipes 3, 9, 10 and 11.
 
Skylake Desktop Core i3-6300, iMac17,1

How come the red highlight for an external display doesn't seem to work in the recent FB Patcher versions?

FB Patcher v1.4.3
FB-Patcher Connectors-1.4.3.png

FB Patcher v1.5.1
FB-Patcher Connetors-1.5.1.png

Plist-Connector-Edits.png



In FB Patcher, I'm using Framebuffer macOS 10.14 (18A391)

Also, the HDMI connector output is not recognized when the DP connector is already connected at boot (no dual display). Could it be because both the DP and HDMI connectors are on pipe 10 and DP is a higher priority connector than HDMI?
 
Back
Top