Closed EigenTom closed 4 years ago
EigenTom
commented
4 years ago I was finally able to trace the problem to the notorious 0D/6D issue. Problem solved after applying the GPRW patch (6D 00 to 69 00).
UPDATE: 6D-00 to 69-00 doesn't work all the time for me. I changed the patch to (6D-00 to Zero-Zero), working properly now.
EigenTom
commented
4 years ago By the way, the current UHD 620 implementation works abnormal on my machine. The HDMI output can only last for 5 seconds, then the signal simply stop streaming, with the monitor still being recognised by the machine. Changing the ig-platform-id to 0x00001659 solve the problem, works like a charm.
tylernguyen
commented
4 years ago I was finally able to trace the problem to the notorious 0D/6D issue. Problem solved after applying the GPRW patch (6D 00 to 69 00).
Yeah, I removed it on the last commit but it seems it's necessary after all. I'm actually in the process of transitioning the sleep patch on this repo to the experimental one by @benbender. That should improve things.
tylernguyen
commented
4 years ago By the way, the current UHD 620 implementation works abnormal on my machine. The HDMI output can only last for 5 seconds, then the signal simply stop streaming, with the monitor still being recognised by the machine. Changing the ig-platform-id to 0x00001659 solve the problem, works like a charm.
Do you have an EDID override applied? That's necessary for HDMI hotplug.
benbender
commented
4 years ago The problem with the framebuffer might be related to changes between OSX versions. @KirisameMarisaa what OSX version are you running exactly and did you upgrade recently (10.15.7?)
EigenTom
commented
4 years ago The problem with the framebuffer might be related to changes between OSX versions. @KirisameMarisaa what OSX version are you running exactly and did you upgrade recently (10.15.7?)
it was macOS 10.15.6.
EigenTom
commented
4 years ago By the way, the current UHD 620 implementation works abnormal on my machine. The HDMI output can only last for 5 seconds, then the signal simply stop streaming, with the monitor still being recognised by the machine. Changing the ig-platform-id to 0x00001659 solve the problem, works like a charm.
Do you have an EDID override applied? That's necessary for HDMI hotplug.
haven‘t considered about EDID override, but it should work fine since the screen I use is exactly the same as yours. After the patch the HDMI output (both USB-C dongle and HDMI port) including hotplug is working properly.
EigenTom
commented
4 years ago I was finally able to trace the problem to the notorious 0D/6D issue. Problem solved after applying the GPRW patch (6D 00 to 69 00).
Yeah, I removed it on the last commit but it seems it's necessary after all. I'm actually in the process of transitioning the sleep patch on this repo to the experimental one by @benbender. That should improve things.
after further lookup, I found that with your original 0x6D patch enabled, the XDCI problem still exists on my machine. It shouldn't happening, as my machine is completely identical on hardware perspective in theory. I think the difference may because my application of SSDT-USBC.aml and several USB-C hotplug settings in Modded BIOS 1.30 instead of the last ver. Wakeup reason XDCI has sth to do with the built-in USB-C USB3.1 controller, and I found this part of the code on my DSDT. I searched for the internet on tutorials about how to edit DSDT, no luck. Is any way to COMPLETELY DELETE the entire wakeup part of the XDCI ACPI method? I don't mind losing USB-C sleep wake, just want to be fully sure that it won't be affecting my sleep any more.
By the way, is breathing ThinkLight with hibernatemode=25 normal? In S3 sleep, the light should first blink for a second, and then completely OFF, isn't it?
H15teve
commented
4 years ago By the way, the current UHD 620 implementation works abnormal on my machine. The HDMI output can only last for 5 seconds, then the signal simply stop streaming, with the monitor still being recognised by the machine. Changing the ig-platform-id to 0x00001659 solve the problem, works like a charm.
Do you have an EDID override applied? That's necessary for HDMI hotplug.
haven‘t considered about EDID override, but it should work fine since the screen I use is exactly the same as yours. After the patch the HDMI output (both USB-C dongle and HDMI port) including hotplug is working properly.
I do have same issue here with a 1080p screen and the EDID override doesn't work for this problem. If I boot with HDMI plugged in, the monitor just doesn't get any signal. What's interesting is that HDMI output works fine on my XGA projector with a VGA adapter...
benbender
commented
4 years ago @KirisameMarisaa XDCI is USB-OTG (on the go)-support and it shouldn't be enabled on your system. I would guess that your setup confuses OSX while determine what caused the wakeup (details here: https://github.com/osy86/USBWakeFixup).
As I don't know what you have changed in bios (and even if, I may not be able to... :/) its hard to make further guesses. I would suggest to reflash the bios with known good / default settings and start over...
About your question regarding ACPI: It is not possible to delete large portions of the DSDT via hotpatch. The way you would actually do it is renaming the _STA()-method of the device and replacing it with one that returns zero to disable the device on boot.
@H15teve Please open another issue for the HDMI-problem to make it easier to track the issue.
EigenTom
commented
4 years ago @KirisameMarisaa XDCI is USB-OTG (on the go)-support and it shouldn't be enabled on your system. I would guess that your setup confuses OSX while determine what caused the wakeup (details here: https://github.com/osy86/USBWakeFixup).
Thank you for your instruction. I'l look into the document further to have a better understanding of it.
I think the main culprit is the SSDT-USBC.aml, which mask the TB3 USB-C controller as an Express Card. However, it's the only possible way to enable USB-C hotplug & USB-C 3.1/3.0 (although only one port work) with decent battery life at this moment. Thankfully I solved the problem.
By the way, could you please explain the latest TB3 exploit a little bit? by modification on both the TB3 firmware and opencore patch, does it mean we can gain perfect TB3 hotplug without suffering from high CPU package power consumption, with the cost of losing USB-C 3.1/3.0/2.0 functionality? Is it possible to have the USB-C ports fully working? Thank you.
As I don't know what you have changed in bios (and even if, I may not be able to... :/) its hard to make further guesses. I would suggest to reflash the bios with known good / default settings and start over...
I do not need to start over. In fact, as mentioned above, by forcing the GPRW 6D method to return Zero, I've successfully solved this problem, and it also works for X1 Yoga 3rd.
About your question regarding ACPI: It is not possible to delete large portions of the DSDT via hotpatch. The way you would actually do it is renaming the _STA()-method of the device and replacing it with one that returns
zeroto disable the device on boot.
Disabling the device and lost all of its functionality is not a rational choice. I only want to kill a small portion of the _PRW part which is responsible for returning values that waking the device up (see highlights in the MaciASL screenshot), instead of disable the entire device, which comes with compromises.
What I want to know is:
@H15teve Please open another issue for the HDMI-problem to make it easier to track the issue.
benbender
commented
4 years ago @KirisameMarisaa XDCI is USB-OTG (on the go)-support and it shouldn't be enabled on your system. I would guess that your setup confuses OSX while determine what caused the wakeup (details here: https://github.com/osy86/USBWakeFixup).
Thank you for your instruction. I'l look into the document further to have a better understanding of it.
I think the main culprit is the
SSDT-USBC.aml, which mask the TB3 USB-C controller as an Express Card. However, it's the only possible way to enable USB-C hotplug & USB-C 3.1/3.0 (although only one port work) with decent battery life at this moment. Thankfully I solved the problem.
Which protocol are you referring to by "USB-C" (USB-C is the connector, it can carry many protocols)? Am I right if I assume you are talking about USB 3.1 Gen 2 with 10Gbit/s?
Could you post your SSDT-USBC.aml for reference? There are plenty of versions around.
By the way, could you please explain the latest TB3 exploit a little bit? by modification on both the TB3 firmware and opencore patch, does it mean we can gain perfect TB3 hotplug without suffering from high CPU package power consumption, with the cost of losing USB-C 3.1/3.0/2.0 functionality? Is it possible to have the USB-C ports fully working? Thank you.
Its not a hack, but the port of @Osy86's work and apples original ACPI-implementation for their TB-drivers. More in depth here: https://github.com/osy86/HaC-Mini/blob/master/details/thunderbolt-3-fix.md.
Yes, it should be possible to have them working but I'm not quite done yet.
I do not need to start over. In fact, as mentioned above, by forcing the GPRW 6D method to return Zero, I've successfully solved this problem, and it also works for X1 Yoga 3rd.
Glad to hear, but the problem with that approach is that it practically forbids many devices to wake the computer entirely. That breaks many of OSX' native functions and is more like an overpainting of the symptoms as a solution to the root of the proble. Thats why I dropped it in the first place. But its also much harder to get our hardware to behave like a genuine mac in every situation. On the other hand: If it would be simple, it wouldn't be a challenge :)
Disabling the device and lost all of its functionality is not a rational choice. I only want to kill a small portion of the _PRW part which is responsible for returning values that waking the device up (see highlights in the MaciASL screenshot), instead of disable the entire device, which comes with compromises.
As I said, I don't believe its enabled in the first place. Check for yourself with ioregistryexplorer. But either way, you could rename its _PRW()-method with a patch - that would "delete" it.
What I want to know is:
- how can I learn the proper way to edit/build ACPI hotpatch? Where can I find the syntax/grammar instructions or some tutorials? I want to learn about the proper editing of ACPI hotpatch, then I can create or modify one by myself.
- Does opencore support other ACPI modification methods, like ACPI static inject method in Clover?
Nope, don't think so. At least not in the sense you probably want it to. See https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/Configuration.pdf
@H15teve Please open another issue for the HDMI-problem to make it easier to track the issue.
EigenTom
commented
4 years ago @KirisameMarisaa XDCI is USB-OTG (on the go)-support and it shouldn't be enabled on your system. I would guess that your setup confuses OSX while determine what caused the wakeup (details here: https://github.com/osy86/USBWakeFixup).
Thank you for your instruction. I'l look into the document further to have a better understanding of it. I think the main culprit is the
SSDT-USBC.aml, which mask the TB3 USB-C controller as an Express Card. However, it's the only possible way to enable USB-C hotplug & USB-C 3.1/3.0 (although only one port work) with decent battery life at this moment. Thankfully I solved the problem.Which protocol are you referring to by "USB-C" (USB-C is the connector, it can carry many protocols)? Am I right if I assume you are talking about USB 3.1 Gen 2 with 10Gbit/s?
Yes, its USB-C 3.1 Gen2 with 10Gbit/s.
Could you post your
SSDT-USBC.amlfor reference? There are plenty of versions around.
SSDT-USBC.aml.zip (remove .zip then it is, silly Github uploading system)
By the way, could you please explain the latest TB3 exploit a little bit? by modification on both the TB3 firmware and opencore patch, does it mean we can gain perfect TB3 hotplug without suffering from high CPU package power consumption, with the cost of losing USB-C 3.1/3.0/2.0 functionality? Is it possible to have the USB-C ports fully working? Thank you.
Its not a hack, but the port of @osy86's work and apples original ACPI-implementation for their TB-drivers. More in depth here: https://github.com/osy86/HaC-Mini/blob/master/details/thunderbolt-3-fix.md.
Yes, it should be possible to have them working but I'm not quite done yet.
Glad to hear that. Looking forward for further improvements.
I do not need to start over. In fact, as mentioned above, by forcing the GPRW 6D method to return Zero, I've successfully solved this problem, and it also works for X1 Yoga 3rd.
Glad to hear, but the problem with that approach is that it practically forbids many devices to wake the computer entirely. That breaks many of OSX' native functions and is more like an overpainting of the symptoms as a solution to the root of the proble. Thats why I dropped it in the first place. But its also much harder to get our hardware to behave like a genuine mac in every situation. On the other hand: If it would be simple, it wouldn't be a challenge :)
For me, the ultimate wish is to kill any other waking up ways (including keyboard &mouse wake up, I hate them) except for the lid and the PWRB. I'm very happy to break these OSX's native functions If then the system works totally fine with every important (at least for my self) functionalities working as expected (like now). After all, our machine is NOT a real mac, and it will never be possible to turn into a real mac, or behave exactly like a real mac without any differences.
Disabling the device and lost all of its functionality is not a rational choice. I only want to kill a small portion of the _PRW part which is responsible for returning values that waking the device up (see highlights in the MaciASL screenshot), instead of disable the entire device, which comes with compromises.
As I said, I don't believe its enabled in the first place. Check for yourself with ioregistryexplorer. Map the GPRW 0D/6D wakeup method away does not break the USB-C hotplug & data transfer & charging functionality.
But either way, you could rename its _PRW()-method with a patch - that would "delete" it.
I've implemented the _PRW() patch, hope it will further strengthen up the quality of idle sleep on the machine.
What I want to know is:
- how can I learn the proper way to edit/build ACPI hotpatch? Where can I find the syntax/grammar instructions or some tutorials? I want to learn about the proper editing of ACPI hotpatch, then I can create or modify one by myself.
- https://acpica.org/documentation
- https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf
- https://dortania.github.io/Getting-Started-With-ACPI/
- acpica.org/sites/acpica/files/asl_tutorial_v20190625.pdf
...Thank you! I can't wait to read them and gain a deep understanding of ACPI and ACPI patches.
- Does opencore support other ACPI modification methods, like ACPI static inject method in Clover?
Nope, don't think so. At least not in the sense you probably want it to. See https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/Configuration.pdf
@H15teve Please open another issue for the HDMI-problem to make it easier to track the issue.
Mifaxav
commented
3 months ago Im really sorry for the fact that this probably is the wrong chatbox for my issue due to the reason its regarding the X1YG3. How did you get sleep working @EigenTom ? in your latest efi?
upgraded it to sonoma, everything else other than sleep is working
Due to my inability to solve the sleep issue on ThinkPad X1 Yoga 3rd, I abandoned the machine and switched to the X1 Carbon 6th 20KH.
I was using BIOS 1.30+Modding (to avoid security patches and get better performance), macOS 10.15.6 Catalina, and the latest x1c6-hackintosh patch. By the way, I also remapped the win key to alt, left alt key to cmd, right prtsc to cmd with little modification of the SSDT-Keyboard.dsl:
What I was experiencing was the inconsistent sleep-wake issue: Sleep (0) works well on every cold boot, but it then went wrong (being able to sleep for a few seconds, and then the power indicator light up, while screen remain dark), after several sleeps or boot up for several hours. The log shows that there's sth wrong with the keyboard, but I was not touching any keys or the trackpad/trackpoint:
2020-10-26 00:09:51 +0800 Wake DarkWake to FullWake from Standby [CDNVA] : due to UserActivity Assertion Using AC (Charge:89%)
2020-10-24 22:53:36 +0800 Wake DarkWake to FullWake from Standby [CDNVA] : due to HID Activity Using AC (Charge:90%)
"
Attempts:
Also, 25/3 (S3) Sleep mode also doesn't seems to work: in sleep process, the power indicator remain breathing, instead of blinking for 3 times and then keep off. In any sleep modes, the time taken to enter sleep is always long, and the log indicates several kexts being "slow". I don't understand what caused these kexts being "slow" to prevent sleep or wakeup.