jlempen / surface-go-2-opencore Goto Github PK

I find my Surface only gets about 1.5 hours of battery life from a full charge in macOS. I've done the best I can to disable spotlight, turn on low power mode, etc, but it's still sipping quite a bit of juice.

I do have scripts that turn turbo mode on and off, and I believe having turbo on is the thing that uses the most power. I'm wondering if this has to do with CFG lock?

Here are my scripts:

# pass 0 to disable, anything else to enable
function toggleturbo() {
    if [ "$1" -eq "0" ]
        then
            echo Disabling turbo mode
            sudo /Library/Application\ Support/VoltageShift/voltageshift turbo 0
        else
            echo Enabling turbo mode
            sudo /Library/Application\ Support/VoltageShift/voltageshift turbo 1
    fi
}

# pass 0 to disable, anything else to enable
function undervolt() {
    if [ "$1" -eq "0" ]
        then
            # Turbo off
            echo Undervolting with turbo off
            cd /Library/Application\ Support/VoltageShift/
            sudo ./voltageshift buildlaunchd -120 0 0 0 0 0 0 28 18 0.002 60
        else
            # Turbo on
            echo Undervolting with turbo on
            cd /Library/Application\ Support/VoltageShift/
            sudo ./voltageshift buildlaunchd -120 0 0 0 0 0 1 28 18 0.002 60
    fi
}

I generally operate with undervolt 1, which undervolts the CPU and enables turbo mode.

I know sleep doesn't work (wakes up to a Surface logo that never goes away), but I did find that hibernate works great with one caveat: if you have the Surface Type Cover connected, it instantly wakes up.

1. Disable all Bluetooth kexts -- these have also been causing some instant wake issues, so we want to rule them out for this test.
2. Enable hibernate with sudo pmset -a hibernatemode 25;
3. With the Surface Type Cover connected, choose Apple Menu -> Sleep. You'll see it go all the way to sleep and power off, then immediately wake up, boot to OpenCore, then restore from hibernate (it does so in 14-16 seconds!).
4. Run pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to" and observe:

2023-04-06 10:02:55 -0700 Sleep               	Entering Sleep state due to 'Software Sleep pid=167':TCPKeepAlive=disabled Using AC (Charge:100%) 32 secs   
2023-04-06 10:03:27 -0700 Wake                	Wake from Standby [CDNVA] : due to /Lid Open Using AC (Charge:100%) 

Then, disconnect the type cover and choose Apple Menu -> Sleep again. No instant wake! If you then press the power button, it wakes right back up and comes alive in 14-16 seconds.

As stated above, I was getting some GLAN XDCI wakes before removing all Bluetooth kexts, as well as a couple random kernel panics, but that's for another issue once I figure this out...

They worked fine on the Open Core boot screen, but stopped working completely once Mac OS booted into the installation UI, as if no Type Cover was connected.

Un/replug Type Cover didn't help. But the touch screen was fine.

I have tried to replace VoodooI2C.kext and VoodooI2CHID.text from #1 (comment) but still no luck.

Replacing VoodooI2C with the latest 2.8 version and rebuilding the config.plist accordingly didn't work either, unfortunately.

I haven't been able to get this to work since Big Sur, it stopped working in Monterey.

I use a Cable Matters USB C Multiport Adapter since I need to use DisplayPort to get full refresh rate on my 24" Dell retina monitor. I'll give some basic Type-C to HDMI adapters at try to verify the adapter isn't a problem, but I do recall this adapter working in Big Sur.

Has anyone tested this recently on Sonoma?

I noticed the README says Capslock still needs work, but I'm happy to report that it's working fine here.

I had working iMessage, logged in and everything, and after updating to Sonoma with the new Sonoma Airportitlwm, it no longer sends/receives messages... I read something about itlwm working, but Airportitlem not, so it's worth looking into that.

I'm currently using config-easy.plist and would like to give config-hard.plist a try, but the documentation does not inspire confidence. I understand what needs to be changed, and that there are two tools I can use to do so, but I'd definitely benefit from detailed step-by-step instructions, especially since the machine can be bricked if this is done incorrectly.

The README says:

Dortania OpenCore Post-Install guide has detailed instructions on how to use the RU.efi tool.

However, the linked page doesn't mention RU.efi and instead details a different method that involves a modified GRUB shell, leaving me worried I'd be missing something critical and end up bricking the machine.

I think it would be worth documenting this delicate procedure directly in the repository. I'd be willing to write the docs if I knew what I was doing. Any guidance?

Howdy, I'm in the process of updating to Sonoma, and ahead of this I went ahead and upgraded OpenCore by copying in your newly updated EFI.

I have working hibernate in Monterey, but I noticed that, in your README, you mention you couldn't get hibernate to work. Here's how you do it:

1. In config.plist, Misc -> Boot -> HibernateMode = NVRAM
2. In config.plist, Misc -> Boot -> HibernateSkipsPicker = true

Then, run the following:

sudo pmset restoredefaults
sudo pmset -a hibernatemode 25

Reboot, then close the cover on your Surface. Wait about 30-40 seconds, then open the cover back up. Press the power button for like 1-2 seconds, and you'll see the Windows logo. Within about 13 seconds of pressing the power button, it should restore from hibernation, skipping OC completely.

I just tested this on Monterey using your latest EFI folder from this repo on OC 0.9.7 and can confirm it works.

Let me know if you get it working!

I'm happy to report display rotation works just fine with Display Rotation Menu from Mage Software! Previously, when I tried this, I remember that scroll direction was reversed, but that's not the case now.

Not all the HiDPI options are available, really only 640x960 is usable, but it's pretty cramped.

It just does nothing... I think it may have been broken in VoodoI2C 2.7 (see VoodooI2C/VoodooI2C#500), or perhaps I broke it when I removed this for loop in VoodooI2C/VoodooI2CHID#69 (which was fixed in VoodooI2C/VoodooI2CHID#73).

In any case, we need to build VoodooI2CHID from the master branch and see if it's fixed. I'm working on that now, but unfortunately XCode 15.2 on Sonoma doesn't have IOKit, so I can't build it at the moment. I'll figure something out and will test/send a PR with the updated kexts if it works.