No need to generate the _CRS to XCRS patch for OpenCore

[Drovosek01]

OpenCore applies ACPI replacement/renaming patches after an attempt to implement SSDT in DSDT. In order for this patch to benefit, it needs to be applied before attempting to implement SSDT in DSDT. I wrote about it here - https://github.com/acidanthera/bugtracker/issues/2174

Together (or together with) the generation of this patch, it is better to output a message to the user that he must manually rename _CRS to XCRS in the "Device HPET" area in DSDT. Or display a dialog for the user with a suggestion to change DSDT so that SSDTTime itself replaces _CRS with XCRS in the DSDT file

P.S. Perhaps the OpenCore developers will satisfy my request and make sure that ACPI patches are applied before the introduction of SSDT, then you can forget about this issue

[corpnewt]

Hey there, SSDTTime's objective is to implement SSDT hot patches for a number of situations/hardware. In doing so, The DSDT is only leveraged for patching/naming references, and should not be injected via EFI -> OC -> ACPI.

Any patches you have in config.plist -> ACPI -> Patch are applied by OpenCore before any tables are injected, so if you intend to inject a patched DSDT, it must be manually patched first - and the ACPI -> Patches will not apply to it.

If I'm misunderstanding what you're saying, please let me know, but it sounds like SSDTTime is working as intended, you're just also injecting your DSDT which overrides the patches.

-CorpNewt

[Drovosek01]

@corpnewt thanks for the clarification, now I probably understand the logic of ACPI processing in OpenCore.

It seems to me that this sequence/pipeline works differently in Clover.

I think this issue can be closed, but it would be cool if SSDT conducted a small heuristic analysis and, for example, if the path to DSDT.aml is selected as /EFI/OC/ACPI/DSDT.aml, then after generating patches, a notification was displayed in the terminal that when using custom DSDT patches must be implemented manually

[corpnewt]

The order should work the same in both boot managers - as the idea is that if you are injecting your own manually edited/created tables, they should not need the boot manager to also patch them. Patching them after injection would also break a number of current "tricks" used in SSDT hot patching.

SSDTTime's objective is explicitly for SSDT hotpatching - in which a patched DSDT is not used at all. As such, I don't think it's worth adding a warning or doing any extra path checking. If you intend to patch your DSDT, you can manually change anything that SSDTTime would normally generate patches for - as well as adding new devices, or making whatever other edits you intend. The two aren't designed to be used together. Though I still stand by the statement that a patched DSDT is quite heavy handed - and SSDT hot patching is a much more elegant approach overall.

-CorpNewt