It's been known that there is indeed support for VGA in Coffe Lake and that support for prior iGPUs was deprecated as the VGA port was removed since Sierra. However, using port patches in Devices Properties (Open Core), I made the VGA port to work again with graphics acceleration.
But there's a catch, the port is glitchy. Once macOS displays the accounts, you can see the Enter Password box with the blur effect. But after some seconds, the whole display will turn to another color (depends on the background). I'm not sure why that happens.
I would suggest learning what are Ports, Connectors, Indexes, Types, and BusIDs before continuing, otherwise, you would get lost.
These are the patches that are supposed to enable the VGA port according to the Whatevergreen Intel guide:
06020000 02000000 30000000 // Option 1
06020000 01000000 30000000 // Option 2
None of those ports seem to work. The first problem is that the Index is 6, which does not make any sense as the Azul framebuffer only supports up to 3 Indexes (software ports). So we first have to change the Index for the VGA port on your motherboard, which is 2 (physical port is 0x06)) for me.
So that means that the target port is the Index 2, which is 02040A00 00040000 87000000.
bus-id 4 is for DP so we would change that to 2, which is VGA. That is according to what Hackintool says. I also proved other bus-ids but none of the other ones seem to work.
I have no idea what pipe does so I just type zeros.
I think pipe is basically another way group ports. So later I changed that to 10, which is 0A in hex. That means pipe remains the same as it was originally. 02020A00 01000000 87000000
The next part is the connector-type, for which I used 02000000.
I tried the VGA connector-types that Hackintool suggested but I noted some weird differences whereas 02000000 and 01000000 seem to work okay.
Finally, I don't know what flags do so I tried with 30000000 and 87000000. The only difference is that with 87000000 I'd gain more seconds before the whole screen turns to another color.
This is the final configuration:
framebuffer-con1-alldata <02020A00 0100000 87000000>
This is the video proof:
Recently I had been looking for ways to control the battery charging on my hackintosh which is a Thinkpad T460 with dual batteries. On Windows there's a program Lenovo Vantage that lets you set the Battery Charging Start and Stop Thresholds. These thresholds continue to apply even when the laptop is turned off as these thresholds are managed by the embedded controller, so from that perspective its a set once and forget.
But there was one more thing that was frustrating me. By default Lenovo uses the external battery first and once its almost drained (less than 5%), it switches to the internal battery.
Although the Charging Start and Stop Limits are a good way to increase the life span of Lithium batteries (by lowering the max charge limit), the complete drainage of the external battery prior to switching to internal is not a good idea.
Fortunately Lenovo EC provide options to force drain (use) a battery (even with the ac adapter connected) thereby allowing to manually switch to the internal one, however these are manual controls. In Linux, there's a program tpacpi-bat that runs as a daemon and performs an efficient management of the dual batteries such as switching to internal battery when the external one reaches a configurable lower limit. However, this is Linux only and uses the ACPI interface.
I did some research to understand my options in macOS. I found RehabMan's ACPIDebug.kext and its ability (using another RehabMan's tool ioio) to call a function defined in the DSDT. With information collected tpacpi-bat and ACPIDebug.kext, I have created a dirty version.
So this is how you use it...
1. Use the attached SSDT-RMDT. As this was just a rough work to validate my understanding, I just did a hard coding for the first battery.
2. Install ACPIDebug.kext
3. After the reboot, you can trigger the following battery operations...
a. Set Battery Charge Start Threshold
ioio -s org_rehabman_ACPIDebug dbg1 <start-percent>
a. Set Battery Charge Stop Threshold
ioio -s org_rehabman_ACPIDebug dbg2 <stop-percent>
a. Force Discharge
ioio -s org_rehabman_ACPIDebug dbg3 <0|1> //0 to disable, 1 to enable
a. Inhibit battery charging for specified number of minutes
ioio -s org_rehabman_ACPIDebug dbg4 <minutes> //0 to disable
a. View Battery Info
ioio -s org_rehabman_ACPIDebug dbg5 <anything> //pass anything, its ignored
a. View Battery Charge Start/Stop Thresholds
ioio -s org_rehabman_ACPIDebug dbg0 <anything> //pass anything, its ignored
At this time, I just hard-coded for the BAT0 to quickly validate my understanding and its working well.
What's next? As I understand (and please correct me if I'm wrong), I can't return values with ACPIDebug.kext along with ioio, plus this is also all very hacky.
To be able to create a program that reads the current remaining capacity (percent) and switches control to internal batter, I need a way to return this info. Currently I'm just outputting it to the logs.
My thinking is to modify ACPIDebug.kext or one of these other kexts (ACPISensors.kext) to add code for above and then create a program to optimally manage the operation of my two batteries.
However, I'm very new to all of this and will take some time.
In the meanwhile, here is it for your playing pleasures. Please be aware that my SSDT-RMDT is currently hard-coded for BAT0 and doesn't have all the validations.
Credits to RehabMan, tpacpi-bat, and other resources on internet.