Issue with close lid to sleep

[erinviegas]

I'm facing an issue where the laptop won't sleep when the lid is closed. It works perfectly fine when putting to sleep using the power menu.

erin@MacBook-Pro ~ % pmset -g assertions
2020-08-24 17:12:47 +0530 
Assertion status system-wide:
   BackgroundTask                 0
   ApplePushServiceTask           0
   UserIsActive                   1
   PreventUserIdleDisplaySleep    0
   PreventSystemSleep             0
   ExternalMedia                  0
   PreventUserIdleSystemSleep     0
   NetworkClientActive            0
Listed by owning process:
   pid 118(hidd): [0x000000210009806c] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle serviceID:100000310 name:IOHIDEventDriver product:Keyboard eventType:3"  
    Timeout will fire in 240 secs Action=TimeoutActionRelease
No kernel assertions.
Idle sleep preventers: IODisplayWrangler

Workaround when using clover It's a bit of a weird bug. When I was using clover bootloader, I had the same issue, when I close the lid, nothing would happen. The display would remain on even with the lid closed and it would never sleep. One workaround I found to work 95% of the time was including the AppleBacklightFixup kext. I know this was made redundant by Whatevergreen, but I swear close lid to sleep would work most of the time if it was included in my kext folder.

This workaround doesn't work with opencore.

If anybody has a solution to this issue, please let me know!

[marianopela]

Same here, experiencing it lately. Gonna let you know if I find a solution (OpenCore)

[marianopela]

In the meantime, dumb question. Have you tried MacBookPro15,4 SMBIOS?

[erinviegas]

In the meantime, dumb question. Have you tried MacBookPro15,4 SMBIOS?

I may have when I was trying to find a fix to this issue, don't remember as it was a long time ago. Did changing the SMBIOS to 15,4 fix it for you?

[marianopela]

Did changing the SMBIOS to 15,4 fix it for you?

Yes, and it does indeed make the Lid work properly The thing is, USBs need to be re-mapped after SBIOS change (e.g Webcam not working). Would you be so kind to work on that?

I also think 15,4 is a much better choice, as its CPU is the most similar to - at least my- i7-8550u

[erinviegas]

The thing is, USBs need to be re-mapped after SBIOS change (e.g Webcam not working). Would you be so kind to work on that?

I also think 15,4 is a much better choice, as its CPU is the most similar to - at least my- i7-8550u

Could you upload your files? I tried using 15,4 but then my brightness adjustment stopped working.

[marianopela]

Could you upload your files? I tried using 15,4 but then my brightness adjustment stopped working.

No problem. Just use Acidanthera's BrightnessKeys. Here I also mapped my USBs (except for type c, which I don't use). Please note my CFG is unlocked, so you should enable the first two quirks under Kernel section) EFI.zip

[erinviegas]

No problem. Just use Acidanthera's BrightnessKeys. Here I also mapped my USBs (except for type c, which I don't use). Please note my CFG is unlocked, so you should enable the first two quirks under Kernel section) EFI.zip Man, I've tried everything and it still isn't working. Closing the lid did work initially once or twice. I've attached my EFI. Can you give it a look? Maybe a fresh pair of eyes will help.

[marianopela]

I was writing to you just now. Which CPU are you on? There are some incorrect settings in your config (e.g Kernel > Add section). Could you please try my EFI as-is (except for these of course, which you need).

Also, regarding audio, I saw your PR a few weeks ago but I've experienced some problems with headphones with your 14 layout-id too. Is your audio working fine all of the time?

[erinviegas]

My CPU is an i5-8250U. Audio Fix attached below.

[marianopela]

Man, I've tried everything and it still isn't working. Closing the lid did work initially once or twice.

Shit, you're right. I'm gonna have to investigate this further

[erinviegas]

There are some incorrect settings in your config (e.g Kernel > Add section). Could you please try my EFI as-is (except for these of course, which you need).

The Kernal> Add section is only used to add the kexts and their order. As long as the essential kexts are up top and in the right order, it really doesn't matter.

[erinviegas]

@marianopela @marcusbalo I have implemented the fix for EAPD. It should be available when it's merged with AppleALC. But for now, I am attaching the built kext below so you can try it out. No more need for any scripts or aggregate devices. Be sure to remove VerbStub, CodecCommander, ALCWakeFix, ComboJack, ALC Plug Fix, JackFix, and any other helper that may be installed. AppleALC-1.5.5-RELEASE.zip

[marianopela]

@erinviegas That's sick, thanks! Gonna try it and give you feedback asap

Also I'm gonna try and fix the lid problem when I have time, as I don't personally own the device

[erinviegas]

@erinviegas Lol, what was Marcus saying?

Btw I'm trying your AppleALC patch as of now

Haha, nothing man, I just wanted to keep this topic to the lid issue. Will delete these other comments in a few days.

[erinviegas]

@marianopela after the latest update to Big Sur and opencore, the issue seems to be resolved. I had to move back to the 14,1 config otherwise the webcam wouldn't work. Inclined to close this issue. Will do so only after some more testing.

[kasti0]

i don´t know how your DSDT looks, but i had the same issue and fixed it with a little edit to the _LID method in the DSDT. LID close works 100% for me, currently using OpenCore. My laptop is a Ideapad 330s 15ikb 81F5

DefinitionBlock ("", "SSDT", 2, "hack", "_LID", 0x00000000)
{
    External (_SB_.PCI0.LPCB.H_EC.LID0, DeviceObj)
    External (_SB_.PCI0.LPCB.H_EC.LSTE, FieldUnitObj)
    External (LSTE, FieldUnitObj)

    Scope (_SB.PCI0.LPCB.H_EC.LID0)
    {
        Method (_LID, 0, NotSerialized)  // _LID: Lid Status
        {
            If ((LSTE == One))
            {
                Return (One)
            }
            Else
            {
                Return (Zero)
            }
        }
    }
}

Renames: find: 5F4C4944 00A00E93 45 replace: 584C4944 00A00E93 45

[kasti0]

Do you have an SSDT for this? I'm trying to only use the Hotpatch method.

I couldn´t upload my SSDT, so that is the code for the SSDT. just copy-paste it to maciASL, save as .aml and put it in the ACPI folder of OpenCore. then add it in the OpenCore config.plist under ACPI/Add and the rename under ACPI/Patch

[erinviegas]

If anyone wants to give this a try. SSDT-LID.zip

[marianopela]

I'll try this in a couple hours, thanks. Still on Catalina and MacBookPro15,4 atm

[kasti0]

I'll try this in a couple hours, thanks. Still on Catalina and MacBookPro15,4 atm

let me know if it works, as I have a slightly different IdeaPad

EDIT: also disable AppleBacklightFixup.kext when trying this SSDT, as the kext is heavily out-dated

[marianopela]

let me know if it works, as I have a slightly different IdeaPad

EDIT: also disable AppleBacklightFixup.kext when trying this SSDT, as the kext is heavily out-dated

Sure, I'll check my DSDT of course before inserting the SSDT. I also don't use that kext, but only WeG and SSDT-PNLF

@erinviegas When I add the SSDT I can post my EFI for you to have a look (I'm using BrightnessKeys, which needs no SSDT patches)

[erinviegas]

Just tried it and it does not seem to work for me. @kasti0 could you post your EFI?

[kasti0]

I`ll upload my EFI later, in the mean time check your DSDT how your original _LID method looks like. mine looked like this:

 Method (_LID, 0, NotSerialized)
                {
                    If ((ECRD (RefOf (LSTE)) == One))
                    {
                        Return (One)
                    }
                    Else
                    {
                        Return (Zero)
                    }
                }

the patched method removes the call to the ECRD method. It´s a while ago since I fixed this issue. unfortunately I can´t remember why there was an issue with ECRD, but it doesn´t give me any ACPI errors during boot anymore.

[kasti0]

EFI upload.zip

[marianopela]

Here is mine (lid patch not yet implemented) EFI.zip

[kasti0]

@erinviegas glad it works for you!

[erinviegas]

@kasti0 I think that celebration was a little premature for me. Thing is it works a couple of times after enabling the patch and then it doesn't. Don't know what's wrong.

[kasti0]

This could be a sleep issue. I already commented on your tonymacx86 post that you didn’t disable the second external port for the framebuffer you’re using, see the WEG manual: ID: 87C00000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000078B TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP

The framebuffer has 3 ports, 1 internal + 2 external DPs. You changed the first external to HDMI but didn’t disable the second one. That could fix your issue as well.

[kasti0]

regarding my SSDT-LID: a better solution for my approach of just removing the call to the ECRD method in the _LID method would be to figure out whats wrong with the ECRD method in the first place. Maybe you guys know more about ACPI than me

[marianopela]

@kasti0 I think that celebration was a little premature for me. Thing is it works a couple of times after enabling the patch and then it doesn't. Don't know what's wrong.

Put this EFI.zip on a USB device. It will extract your ACPIs, so we can have a look at your DSDT

[erinviegas]

Here is my DSDT @marianopela @kasti0 DSDT.aml.zip

[kasti0]

seems like you have the same original _LID method as me, so the patch should work did you do the following changes too?

• remove applebacklightfixup.kext
• disable second DP port of the framebuffer to prevent sleep issues (have a look in my config.plist, just copy paste the options for con2 under DeviceProperties/Add/PciRoot(0x0)/Pci(0x2,0x0))

[erinviegas]

seems like you have the same original _LID method as me, so the patch should work did you do the following changes too?

* remove applebacklightfixup.kext

* disable second DP port of the framebuffer to prevent sleep issues (have a look in my config.plist, just copy paste the options for con2 under DeviceProperties/Add/PciRoot(0x0)/Pci(0x2,0x0))

Doesn't work even after this.

[kasti0]

@erinviegas could still be a sleep issue. did you map your USB ports correctly? I just saw you have one additional USB port in your USBPorts.kext with the name "HS02". I think we have the same USB setup (2x USB-A 2.0/3.0, 1x USB-C 3.0, 1x SD Card Reader, 1x Webcam, 1x Bluetooth) that´s 8 in total, but your .kext has 9 in total. test again with removing the additional Port HS02, you can use my USBPorts.kext USBPorts.kext.zip

[erinviegas]

@erinviegas could still be a sleep issue. did you map your USB ports correctly? I just saw you have one additional USB port in your USBPorts.kext with the name "HS02". I think we have the same USB setup (2x USB-A 2.0/3.0, 1x USB-C 3.0, 1x SD Card Reader, 1x Webcam, 1x Bluetooth) that´s 8 in total, but your .kext has 9 in total. test again with removing the additional Port HS02, you can use my USBPorts.kext USBPorts.kext.zip

Ports are mapped correctly. Yes, it is the same USB setup, and no the HS02 port is not an 'additional' port.

HS01=Type-A port on the left when USB 2 device is inserted. HS02=Type-C port on the left when USB 2 device is inserted. HS03=Type-A port on the right when USB 2 device is inserted. HS04=Internal Wifi HS07=Internal Camera HS08=SD card slot. SS01=Type-A port on the left when USB 3 device is inserted. SS02=Type-C port on the left when USB 3 device is inserted. SS03=Type-A port on the right when USB 3 device is inserted.

[kasti0]

At that point I'd go over the section "fix sleep issues" of the dortania guide again, it's probably a sleep issue. Seems like everything's set up correctly and the LID patch was what helped me fix the issue.

[erinviegas]

At that point I'd go over the section "fix sleep issues" of the dortania guide again, it's probably a sleep issue. Seems like everything's set up correctly and the LID patch was what helped me fix the issue.

Yup, sleep works perfectly fine when I use it from the power menu or with the button. Just that closing the lid is an issue. Anyway, hopefully I'm able to solve it one day.

[kasti0]

It's really weird as that seems to be exactly the same problem I had. Using the menu bar sleep worked but not with lid close. Maybe give this one a try:

https://dortania.github.io/OpenCore-Post-Install/universal/sleep.html#displays

[erinviegas]

erin@MacBook-Pro ~ % pmset -g assertions 2020-11-18 14:12:43 +0530 Assertion status system-wide: BackgroundTask 0 ApplePushServiceTask 0 UserIsActive 1 PreventUserIdleDisplaySleep 0 PreventSystemSleep 0 ExternalMedia 0 PreventUserIdleSystemSleep 0 NetworkClientActive 0 Listed by owning process: pid 128(WindowServer): [0x000000270009806a] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle serviceID:100000470 name:IOHIDEventDriver product:Keyboard eventType:3" Timeout will fire in 240 secs Action=TimeoutActionRelease No kernel assertions. Idle sleep preventers: IODisplayWrangler Since the event has something to do with the keyboard maybe I need some modified version of this?

[marianopela]

Unfortunately I don't have the laptop at hand these days. Hope this helps (even though I think I've already tried it in the past) https://www.insanelymac.com/forum/topic/342400-idle-sleep-preventers-iodisplaywrangler/

[lucrative-menace]

@kasti0 Thanks man, your SSDT seems to be the solution indeed.

@erinviegas I looked at your DSDT and the patch (_LID to XLID) did indeed work fine there. What you did wrong I presume is used the exact asl code that @kasti0 provided. Remember, H_EC has been renamed to EC in order to fix battery (and trackpad) issues, so the correct external device to target is EC and not H_EC.

So, try this one:

DefinitionBlock ("", "SSDT", 2, "hack", "_LID", 0x00000000)
{
    External (_SB_.PCI0.LPCB.EC__.LID0, DeviceObj)
    External (_SB_.PCI0.LPCB.EC__.LSTE, FieldUnitObj)
    External (LSTE, FieldUnitObj)

    Scope (_SB.PCI0.LPCB.EC__.LID0)
    {
        Method (_LID, 0, NotSerialized)  // _LID: Lid Status
        {
            If ((LSTE == One))
            {
                Return (One)
            }
            Else
            {
                Return (Zero)
            }
        }
    }
}

Worked fine for me. Already restarted 5 times to test and the device went to sleep on lid close every single time. Going to check it a little more though before concluding.

What remains is to find out what's wrong with the original _LID method. Too lazy (and don't know much about ACPI) to figure it out, maybe sometime later.

[kasti0]

@erinviegas Completely oversaw that, @lucrative-menace is right! I'm not using a device rename for my EC but the SSDT-EC instead. So you need to change this in the SSDT-LID

[erinviegas]

@lucrative-menace you are right. I completely missed that too. Thanks a lot! I think this issue is finally resolved. Will test over the next few days before closing it.

[kasti0]

So now my SSDT is finally working?

[erinviegas]

With the modifications, looks like it.

[kasti0]

@erinviegas I just recently changed it and forgot about it, because it's now recommend to use the SSDT-EC instead of renaming the whole EC device which may break other methods.

[kasti0]

@erinviegas maybe the dumbest way to contact you but couldn´t find another way. tonymac somehow blocks me from making new comments on your thread and I can´t open the message you send me there. what was the content?

[erinviegas]

@kasti0 seems like I received a temporary ban for trying to message you. I'm not sure why. I'll post the exact same thing here. What exactly does the SSDT-Q0A_QC9.aml do? Does it help with the error mentioned here? I too get this many times while booting without being plugged in.

[kasti0]

Yes it's just a work around to get rid of the acpi errors. It removes the "GFX0.AFN2" part from both methods. For long term it would be better to find out how to actually fix the methods, but I couldn't find afn2 anywhere.

[erinviegas]

Cool, thanks. I've included in my repo as well. Could it be a bug in the ACPI firmware code itself? Also, are you on discord or telegram? Could make conversations easier, since tonymacx86 doesn't seem to like private discussions.