whatnameisit Posted July 4, 2019 Share Posted July 4, 2019 (edited) I was creating an SSDT for my laptop's battery. Why I posted this topic was that even though I could just get away with adding the directory from root (\) and be done with patching (which I already did and got working battery status), it bothers me that I need to save as .aml and reopen it to check if the external declarations are what I intended them to be. Here's what I mean with pictures because I am so bad at explaining things in word also in my native language. I just straight-copied what I needed from the SSDT with EC in it. The highlighted code above is a part of what I needed, and since the ObjectType is not known here (compilation error), I looked into the original SSDT and found the directory (BTW, is "directory" the correct terminology?) to be _SB.PCI0.LPCB.EC.TMP1 and Type FieldUnitObject, so I added the declaration like below: And I was done with everything, compiled with no error and saved as .aml. I used this SSDT and saw that the battery was always at 100 % in macOS which can't be right (I checked in Windows and the battery was at something like 70 %). I opened it again and an external declaration was created with a warning sign like below: There is no object named TMP1 that I have in the SSDT I created (that is in the root in the whole ACPI table). Since this is wrong, I added the directory in the body like below: Deleted the external with warning, saved, and there was no bogus external, and I got a properly working battery status. This is just one example of about twenty objects that brought up the same issue, same bogus externals. And some objects are fine as the way they are. Also only that specific line with Store (TMP1,Local0) is the one responsible for bogus external of TMP1. Take a look below: These TMP1's did not matter whether they were like \_SB.PCI0.LPCB.EC.TMP1 or just TMP1. RehabMan's .app and Acidanthera's .app exhibit the same behavior with making up a bogus external when saving the SSDT as .aml. I don't know where to ask questions. Actually, I do not know how to ask this question or search this thing...so I ended up here. If anyone can shed light on anything, please do The questions: Why does it not matter in the original DSDT/SSDTs to have just the bare object as they way it originally is but it sometimes does matter and I have to give its full name from the root when I make my own SSDT to inject? Thanks. SSDT-GramBAT.aml Answer: DSDT has objects mostly defined in it which makes itself look up objects and fix their definite locations everywhere in the table. SSDT has objects defined elsewhere and the only thing that tell where they belong are external declarations which are weak in defining the locations of the objects. Edited September 16, 2019 by displhehynehym solved Link to comment Share on other sites More sharing options...
Asher- Posted September 13, 2019 Share Posted September 13, 2019 External just tells the compiler that in this AML file there will be references to scopes that are not in this file. If your DSL compiles properly there is no reason to open the AML back up. Are you actually getting errors during compile? Link to comment Share on other sites More sharing options...
whatnameisit Posted September 14, 2019 Author Share Posted September 14, 2019 12 hours ago, Asher- said: External just tells the compiler that in this AML file there will be references to scopes that are not in this file. If your DSL compiles properly there is no reason to open the AML back up. Are you actually getting errors during compile? Read what I wrote again. Link to comment Share on other sites More sharing options...
Asher- Posted September 15, 2019 Share Posted September 15, 2019 I did. Which made me conclude you are making an issue out of nothing. Link to comment Share on other sites More sharing options...
whatnameisit Posted September 15, 2019 Author Share Posted September 15, 2019 7 hours ago, Asher- said: I did. Which made me conclude you are making an issue out of nothing. You're not reading. What's my issue? You don't have to answer. You can just leave. Link to comment Share on other sites More sharing options...
Asher- Posted September 16, 2019 Share Posted September 16, 2019 Being a {censored} is always a good strategy for getting help. 1 Link to comment Share on other sites More sharing options...
whatnameisit Posted September 16, 2019 Author Share Posted September 16, 2019 21 minutes ago, Asher- said: Being a {censored} is always a good strategy for getting help. It certainly does have to do with you not reading what I wrote in post #1 and not getting help from others. Thank you for stating the obvious, Mr. Headache-to-others. And I also thank you for being such a non-helping idiot that you made me give more thorough thinking why this issue, that you don't understand occurs and I figured it out but even If I tell you it will not make sense to you because you are just the way you are, an idiot for not giving an actual {censored} about what the problem is but only think about how he might be right: "mE cOnCLudE yoU ArE mAkiNG aN IsSuE oUt oF NotHIng" and being unable to state the problem stated in the first post. To the intelligent others, DSDT has objects mostly defined in it which makes itself look up objects and fix their definite locations everywhere in the table. SSDT has objects defined elsewhere and the only thing that tell where they belong are external declarations which are weak in defining the locations of the objects. Problem solved, but not for that idiot because they dun understand what the problem was. Link to comment Share on other sites More sharing options...
Recommended Posts