2012 MacBook Pro screen won't wake up from sleep when running Catalina to bigsur(patched sur)

Here is a recap of your initial report:

1. You've used third-party software to allow Catalina to be installed on a system which is too old to be natively supported.
2. You've noticed that (A) your display lacks a brightness slider and (B) the display won't turn on after sleep.

Now, both symptoms (A) and (B) can occur on their own for a number of different reasons. The fact that they occur simultaneously and that nothing appears to resolve them strongly suggests that there is a failure somewhere in the path of the display backlight chain. Without additional information, this can mean a hardware, firmware, or software root cause. So we should investigate each of these areas separately.

The display backlight consists of dedicated circuitry and software components. The circuitry includes the LED backlighting panel itself along with a hardware controller for it which interfaces with the CPU and allows system (and user) software to command it. This controller therefore requires driver software that is specifically written for the exact controller hardware used in your particular machine. If the driver isn't present and running, the system has no way to issue commands to the backlight controller to change the amount of electrical current it sends to the LED panel (i.e., changing the brightness).

So we should first check that the driver is present and loaded. To do this, I asked you to check the output of kextstat and systemextensionsctl for the presence of backlight controller kernel extensions. Your output confirms that the necessary KEXTs are, in fact, loaded correctly.

It is critical to remember that Apple is free to change the implementation of the backlighting hardware between any two models of computer. When they do, the driver software needs to be updated in order to add support for a new hardware implementation. If an old driver is used with new hardware, there is a strong likelihood that the backlight will either malfunction or not work at all.

(For example, a new microcontroller may have a different IO address map and sending commands to the address of a peripheral on the old microcontroller will (1) prevent the peripheral from seeing the command and (2) likely unintentionally corrupt an unrelated register.)

Because of this, drivers, in general, are necessarily partially or wholly hardware-specific, so before a driver attempts to talk to hardware it needs to make sure that it's only targeting the exact hardware that it supports. There are many ways of accomplishing this. One primitive way, which only works because Apple is a vertical vendor, is by gating driver loading on the model of Mac that you have. This is done through IOKit via the board-id property on the Platform Expert node. This is a UUID that has a 1:1 correspondence to your machine type and generation (e.g., MacBookPro10,1). If a driver queries your board-id and it matches the driver's list of supported boards, then the driver knows that it's familiar with your hardware and can proceed to start controlling it. If your board isn't on the list, then the driver can gracefully fail and not attempt to drive hardware that it doesn't know how to talk to.

One of the possibilities I suspected with your issue, due to you running on an unsupported system, is that the backlight driver wasn't written with knowledge of your specific backlight hardware and is therefore unable to control it. With a little digging, I think I found the place where that determination is made: During active probing on the AGDCBacklightControl driver. When you take a look at the driver's IORegistry entry (ioreg -r -c AGDCBacklightControl) you will notice that (1) it is always going to passively match and (2) there is a property called ConfigMap which is an array of board-ids. The obvious conclusion is that this is the list which AGDCBacklightControl uses to determine whether or not it supports your backlight.

That is why I asked for you to run the second set of commands. I wanted to compare your board-id with the driver's list. Sure enough, your ID (Mac-C3EC7CD22292981F) isn't there.

What that means for you, unfortunately, is not great news: It's likely that your system will never have a working backlight in Catalina because Catalina's driver is incompatible with your hardware.

I should also point out here that Apple routinely scrubs all of its software and removes code for hardware that it no longer wants to support. This is good practice for many reasons (increased stability, decreased attack surface, lower code size, higher performance, reduced code/engineering complexity, reduced testing matrix). So while the driver code for your specific backlight controller is officially supported in Mountain Lion, it was intentionally removed in Catalina.

Your best options are to either (1) accept the limitation or (2) use a supported macOS release.

There are, however, two experiments that you could try here:

1. You can attempt to fool AGDCBacklightControl into loading and trying to drive your backlight. This is unlikely to work due to the reasons I gave above, and might cause unanticipated damage to your hardware for the same reasons (unlikely, but possible). It would be straightforward to try (you'd just need to add an entry to ConfigMap in /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AGDCBacklightControl.kext/Contents/Info.plist after disabling the appropriate protections and then update your kernel cache) but I am not going to spell out the procedure here. Follow that route at your own risk!
2. You could also try to copy the Mountain Lion version of the driver over to your Catalina install and hope that doing so will avoid calling into incompatible SPI/API. Again, this is left as an exercise.