ftrela Posted August 7, 2019 Author Share Posted August 7, 2019 After the wake? Yes, that's actually how I know the system is waking properly apart from the screen - when trying to adjust brightness with shortcuts (f5 and f6 without Fn for my laptop) I can hear the "blocked" sound because I'm in the login screen and apparently they don't work there. Link to comment Share on other sites More sharing options...
eC//FrEaK Posted August 7, 2019 Share Posted August 7, 2019 Sad... Anyways... which config are you using in clover for booting your system, "config.plist" or "config 2.plist"? Link to comment Share on other sites More sharing options...
ftrela Posted August 7, 2019 Author Share Posted August 7, 2019 config.plist, I should just remove the other one, I only used it for testing a fix to another issue Link to comment Share on other sites More sharing options...
eC//FrEaK Posted August 7, 2019 Share Posted August 7, 2019 (edited) Well... so far i'm at the end of my knowledge... I now have no more ideas why your screen remains black after awaking from sleep... Edited August 7, 2019 by eC//FrEaK Link to comment Share on other sites More sharing options...
Administrators Hervé Posted August 7, 2019 Administrators Share Posted August 7, 2019 What about those "GraphicsPolicy" patches you've got configured in Clover? Tried to see how wake behaves when you remove them? Link to comment Share on other sites More sharing options...
ftrela Posted August 7, 2019 Author Share Posted August 7, 2019 Disabling them didn't make any difference. I've tried switching some other sleep/graphic-related patches in Clover but no improvement so far. Link to comment Share on other sites More sharing options...
Administrators Hervé Posted August 7, 2019 Administrators Share Posted August 7, 2019 To me, there is something weird on your system... You obviously aim to disable your GeForce 920M (Kepler) dGPU through that SSDT-Disable-dGPU table. You quite rightly rename PEGP device to GFX0 in your Clover config. Looking at your extracted tables, the dGPU could be believed connected to root device PEG0.PEGP @1. But then, in IOReg, I see that dGPU active under root device RP05 @1C,4. We would need to confirm what is what through an IOReg extract taken without any DSDT/SSDT patches affecting or aiming to affect dGPU. I also derive from your IOReg that you're using Clover config called "config.plist" which sets SMBIOS to MBP12,1. The only other SMBIOS you could use for your Broadwell platform would normally be MBA7,1 or MBA7,2, not MBA6,2 which is Haswell... Can you please explain what you patched in your DSDT? Link to comment Share on other sites More sharing options...
ftrela Posted August 7, 2019 Author Share Posted August 7, 2019 I most likely messed up some SSDT patches while trying to disable the dGPU. I was trying to disable it with the _OFF method manually and probably injected it in the wrong place along the way. I think I'm going to give it another go. Thank you for looking into that! I have eventually managed to fix the black screen issue by injecting EDID and setting ig-platform-id to 0x1620006. Thank you @Hervé, @Jake Lo and @eC//FrEaK for your invaluable help with getting my device to sleep properly Link to comment Share on other sites More sharing options...
Administrators Hervé Posted August 7, 2019 Administrators Share Posted August 7, 2019 @ftrela, could you please: remove that SSDT-Disable-DGPU table reboot the laptop save an output of SysProfiler/SysInfo + IORegistryExplorer and post a zipped copy of them dGPU definition and controls will be in the following tables: DSDT.Aml SSDT-8-SaSsdt.aml SSDT-9-SgPch.aml SSDT-10-OptTabl.aml It's important to identify the correct device used for the dGPU in order to try and disable it properly. Link to comment Share on other sites More sharing options...
ftrela Posted August 7, 2019 Author Share Posted August 7, 2019 I removed the SSDT-Disable-DGPU table and now the dGPU is back. Attaching the zip: asus.zip Link to comment Share on other sites More sharing options...
Recommended Posts