Contribute
Register

What—*not how*—to edit in a DSDT.aml file & where to learn it

Status
Not open for further replies.
Joined
Feb 18, 2011
Messages
17
Motherboard
OS X 10.9
CPU
Intel Z97 LGA 1150/ i7 4790k
Graphics
PNY GTX 770
Mac
  1. 0
Classic Mac
  1. eMac
Mobile Phone
  1. iOS
Hi. I know next to nothing about hardware, but I'm coming up on my third Hackintosh (I've been using nothing but for... 5 or 6 years). Every time I try to get a little more competent at the process.

I write Python, PHP, Javascript, etc. (web developer ftw); so the editing part doesn't alarm me, I can pick up syntax in a jif. But I don't have the slightest clue about what sort of edits to make, why I should or should not make them, etc.. Semantically, a DSDT file is utterly opaque to me.

I'm sure this is a frequent question, but googling it really hasn't proved productive, mostly I find variations on how to open the file and make edits, not how to become informed about editing.

Can someone point me to resources? Or explain what knowledge(s) is/are involved in becoming DSDT savvy? When I write code for myself or a client, I am able to evaluate whether it's stupid code, whether it could be better, what appropriate values are, etc.—how do I gain this level of competence with DSDT editing? Or, if I don't, how do I know I don't? The idea of copying and pasting values from *any* resource and then applying them directly to my rig without being able to evaluate the quality thereof, to me, is just alarming and kind of stupid. But lots of people seem very confident about just slapping up a DSDT they find on the web. Where is this confidence coming from, what am I missing?
 
Hi. I know next to nothing about hardware, but I'm coming up on my third Hackintosh (I've been using nothing but for... 5 or 6 years). Every time I try to get a little more competent at the process.

I write Python, PHP, Javascript, etc. (web developer ftw); so the editing part doesn't alarm me, I can pick up syntax in a jif. But I don't have the slightest clue about what sort of edits to make, why I should or should not make them, etc.. Semantically, a DSDT file is utterly opaque to me.

I'm sure this is a frequent question, but googling it really hasn't proved productive, mostly I find variations on how to open the file and make edits, not how to become informed about editing.

Can someone point me to resources? Or explain what knowledge(s) is/are involved in becoming DSDT savvy? When I write code for myself or a client, I am able to evaluate whether it's stupid code, whether it could be better, what appropriate values are, etc.—how do I gain this level of competence with DSDT editing? Or, if I don't, how do I know I don't? The idea of copying and pasting values from *any* resource and then applying them directly to my rig without being able to evaluate the quality thereof, to me, is just alarming and kind of stupid. But lots of people seem very confident about just slapping up a DSDT they find on the web. Where is this confidence coming from, what am I missing?

This a good place to start: https://www.acpica.org/
 
Hell yeah, thanks.

And to anyone else reading, keep it coming!
 
Hell yeah, thanks.

And to anyone else reading, keep it coming!

The rest is kind of a "learn by doing"/"learn by reading"/"learn by making a lot of mistakes."

Because a lot of the things we do with DSDTs are specific to Apple's little universe and is not documented. (_DSM injection for mapping unsupported PCI device-ids to supported ones, injecting various properties into the ioreg because they are used by Apple's drivers, power management data specific to Apple stuffed into SSDTs, etc.)
 
OIC. So, if I understand you:

I've only had chance to skim the outlines of the APICA documentation, so I'm only marginally less informed now than above, but: you mention things like "mapping unsupported device IDs onto supported ones"—understanding, deeply, the APCICA documentation should provide the background to know when such a task is necessary/appropriate and the rudiments of how to go about it, whereas correct values and actual success at the task are going to be idiosyncratic to the problem and will just require a little bit of belligerent trial and error?

And, again, thanks, this is *precisely* the kind of information I was looking for!!
 
OIC. So, if I understand you:

I've only had chance to skim the outlines of the APICA documentation, so I'm only marginally less informed now than above, but: you mention things like "mapping unsupported device IDs onto supported ones"—understanding, deeply, the APCICA documentation should provide the background to know when such a task is necessary/appropriate and the rudiments of how to go about it, whereas correct values and actual success at the task are going to be idiosyncratic to the problem and will just require a little bit of belligerent trial and error?

ACPI docs are not going to tell you about mapping device ids. Because it is not part of the ACPI spec, but rather something OS X/Apple specific (Apple's rendition of _DSM method). But if you look at enough DSDT patches, you'll start to understand what is going on.

And, again, thanks, this is *precisely* the kind of information I was looking for!!

Cool... Happy reading...
 
Status
Not open for further replies.
Back
Top