search

ayilm1 / gMUXBypass

Bypass graphics multiplexer on 820-2914 and 820-2915
GNU General Public License v3.0
38 stars 14 forks source link

AppleGraphicsControl.kext (from Sierra version 3.13) can control brightness even if the dGPU is missing on PCIe #2

Closed protocold closed 4 years ago

protocold commented 4 years ago

I have a 820-2915 with r8911 removed(also with nvram variable set), so dGPU is NOT powered and therefore missing on PCIe(can be further confirmed also via lcpci under linux). It was mentioned on the README that AppleMuxControl.kext will not load when dGPU is missing on. This is true for latest version of AppleMuxControl.kext.

However, when old version of AppleMuxControl.kext (version 3.13, from Sierra 10.12.1) is installed on this machine, it will actually works and can control the brightness with the iGPU(I tested myself and this works also on High Sierra, Mojave, Catalina). Source: https://forums.macrumors.com/threads/disable-a-failed-amd-gpu-on-a-2011-macbook-pro-grub-solution.2087527/post-27525770

The linux gmux driver must have done a great deal to reverse engineer this gMux thing and documented it pretty well. (https://github.com/torvalds/linux/blob/master/drivers/platform/x86/apple-gmux.c), it has defined

define GMUX_PORT_MAX_BRIGHTNESS 0x70

define GMUX_PORT_BRIGHTNESS 0x74

define GMUX_PORT_VALUE 0xc2

define GMUX_PORT_READ 0xd0

define GMUX_PORT_WRITE 0xd4

along with many other things, as well as a code block of brightness control.

Is there a way to get gMUXBypass to work with AppleMuxControl.kext version 3.13 to control the brightness without the soldering the microvia?

ayilm1 commented 4 years ago

I've already done some work here on sniffing the bus activity. This was on the advanced reworks post which you've identified as 404'd now. Here is a Google cache link. One of my suggestions was to either make a third-party kext in combination with Lattice's LPC IP block. I stopped going down this path because the whole point was to make the fix update-proof. This is the only way to achieve that. If you want zero HW modding; sure, it's possible to talk to the MUX via LPC to send it brightness control commands. But you will be doing so either with a custom kext, or overwriting the original with the 10.13 one as you identified.

protocold commented 4 years ago

if i want to overwrite with 10.13 kext, what changes do i need on the gMuxBypass code? Would the PWM version work as is? or need other change (N2 is now high-impedance or other reason)?

ayilm1 commented 4 years ago

The NoPWM version just writes the backlight PWM pin high to set it to max brightness. The PWM version sets the FPGA pin high impedance so the PCH can drive the line instead. Currently neither version would work for what you want. The kext requires there to be an LPC slave on the bus. By reconfiguring the FPGA, you remove the LPC slave that's a part of Apple's original configuration. You would need to as a minimum include the Lattice LPC IP and configure it to respond appropriately to the inits sent by the kext (LADs, etc.). For anyone that wants to go down the route of implementing this, I've linked the IP block in the readme.

protocold commented 4 years ago

Many thanks for your sharing, very much appreciated.

Unfortunately my skillsets is too limited to do what you suggest regarding the LPC slave. I hope the info is useful to someone with the right skills.