>> Is this the end?

While it is still a mystery why the maximum link rate reported by the internal display is zero, I believe that this is the almost ultimate solution I can find so far. This patch is written in an elegant way without having other negative side effects such as no display after waking up and no signal on external monitors. Besides, it is easy to apply this fix via WhateverGreen by hooking the call of ReadAUX(). Since the framebuffer instance is also passed in ReadAUX(), we could check the port number at there and decide whether or not to modify the given DPCD buffer.

// Code example illustrating how to apply the fix in hooked ReadAUX()
// @Author: FireWolf
int AppleIntelFramebufferController::ReadAUX(AppleIntelFramebufferController* this,
                                             AppleIntelFramebuffer* framebuffer,
                                             UInt32 address,
                                             UInt16 length,
                                             void* buffer,
                                             AppleIntelDisplayPath* displayPath)
    // Call the original ReadAUX()
    int retVal = orgReadAUX(this, framebuffer, address, length, buffer, display);

    // Guard: Check the address
    if (address != 0)
        return retVal;

    UInt32 port = *reinterpret_cast<UInt32*>(reinterpret_cast<UInt8*>(framebuffer) + 0x1dc);

    // Guard: Check the framebuffer port number
    if (port != 0)
        return retVal;

    UInt8* dpcd_caps = reinterpret_cast<UInt8*>(buffer);

    // A better way is to read the value specified by the user instead of using a constant at here
    // e.g. Users can define a property, say cfl-dpcd-max-link-rate, in Clover's config.plist.
    // Or even better, allow users to define a property to specify the framebuffer port number.
    dpcd_caps[1] = 0x14;

    return retVal;

Furthermore, it is worth knowing that Intel’s Linux graphics driver handles this issue by setting a fallback value (0x6, RBR, 1.62 Gbps) and returning no error. In comparison, Apple’s Intel graphics driver does the same thing but returns an error. Although it is completely reasonable for Apple’s driver to return an error on reading an invalid value, I think, with no responsibility, that it would be better to try every possible link rate value from the largest to the smallest one and pick the one that actually works during link training.

So far, the internal 4K display and the graphics accelerations work great without any issue, but this is still not the end of the story. I will keep researching on this issue and try to figure out why the maximum link rate reported by the display is zero. Is this related to eDP 1.4? Let's see what happens!

results matching ""

    No results matching ""