Contribute
Register

Conceptual question about SSDT "patching"

Status
Not open for further replies.
Joined
Mar 8, 2015
Messages
69
Motherboard
MSI Z370m Mortar; ASUS Zenbook Pro UX535LI
CPU
i5-9600k; i7-10750H
Graphics
UHD 630
Mac
  1. iMac
  2. MacBook Pro
If there is such a thing as google fatigue, I have it!

Have a fundamental question about SSDT patching in particular as used with OpenCore general to any feature.

When you generate a custom SSDT for some feature and keep it in the ACPI of OC, do the methods defined in this SSDT override/replace the same method in the same scope in the DSDT and nothing else needs to be done or does the method in the DSDT need to renamed if the method is redefined in the custom SSDT?

I have seen examples of both but trying to figure out the order and semantics of how the custom SSDTs placed in ACPI directory change/modify/override related code in DSDT from the device. If the answer is it depends, what are the different use cases that does not and does require renaming?

Also, do these changes still apply if you boot MS Windows from OC menu and therefore you need the if "Darwin" test everywhere? Again I have seen examples with and without this test. Or does MS Window boot with vanilla DSDT in the device with no change from Clover?

Just trying to understand what the basic principle is before writing my own which seems necessary for the laptop I have started to work on.

Thanks. Just a pointer where these basic principles/tutorial can be easily found if available would also be enough.
 
A custom SSDT adds to what is already defined by the DSDT and SSDTs which loaded earlier. Attempts to overrride or replace would result in "ACPI Error: [SYMBOL] already exists". To override an existing method, one needs to first rename the original (e.g. _STA to XSTA) and then add a "new" method with the same name in a SSDT to replace the functionality (or adds to it by calling back the renamed original function).
 
@etorix Thank you for the clear reply. That helps.

Problem with Opencore style SSDT-patching where you just place the modified SSDTs in a folder (each one is compiled on its own, so it isn't aware of the symbol already existing in DSDT) and boot, that renaming error isn't obvious and any runtime failure may be silent.

I see a lot of SSDT patching suggestions out there for making trackpads work with VoodooI2C which seem to be redefining without doing that renaming and I suspect many of the reported failures to make trackpads work might be due to not renaming.

Now the detailed thread here on various uses cases to patch
makes a lot more sense to translate to Opencore.
 
ACPI errors will show up during verbose boot (boot argument -v), which should be used until the hack is confirmed to be finished and stable.

By design, each DSDT/SSDT do not know what's in other ACPI tables; it's not specifically an "OpenCore style" issue. It is ultimately the programmer's responsibility to consider the whole set of tables—including the effects of the loading order. Separating pieces of code makes it easier to modify one without altering the others, as long as the hooks by which these pieces connect (External() references) remain the same.
The "Clover style" alternative, if that's what's in your mind, of replacing the whole DSDT is more complex and more difficult to maintain, as you then have to re-do your work each time the DSDT is modified by a BIOS update—and you still have to watch out for any impact of your modifications on the native SSDTs.
 
I like the "Opencore style" by which I mean no patched DSDT dropping all OEM tables in embedded DSDT replacing it with a patched one, just individual SSDT adds (both are possible with Clover). There are pros and cons to both types depending on what you wish to achieve. Just wanted to understand it conceptually how it worked. Whether new definitions created duplicate definitions (if old ones weren't renamed) or did a O-O like override. I now understand it is the former.
 
Status
Not open for further replies.
Back
Top