noname33

Definitely I abandon Hackintosh. Well, I tried to fix it, but it is highly designed for not working out of the OEM OS. For example this a short list of the GNVS. The GNVS take values different according to the combination ACOS-OSYS. The worse case is given when you select OSYS=0x2710. If you write 2710 in the OSYS reg, the fields of the IGDM, GNVS, and others OperationRegion, will take at least 3 values before 'crash' and corrupt all the OperationsRegion fields. The next are 3 logs of the same boot with OSYS=0x2710. The first is the value of several fields of GNVS before make any other thing, the first thing that the dsdt do is take the fields value. The second logs, are the same, but the values are read just after running the OS. And the 3, is the same, but the values were read 5 min after run. (There is a lot of fields, so I omit a lot, but the changes are similar some other hundred of fields) This is before Write any thing (OSYS yet hasn't written, It's the default values): Now, is just running the OS, OSYS is 2710 how you can see. Also all the values of GNVS have take changes: And this is over 5 min after running the OS. All fields are corrupt: And this still is worse with the long field, for example it's a show other simple comparative example of some fields in the IGDM (Intel Graphics Device): Before running: the same, little time after running: And, at least for my, the best case is when I select OSYS=Windows 2006 and ACOS 0x20. If I try OSYS=Linux and ACOS 0x40, the fields are corrupt in the same way, but with C0 instead of FF,. Almost all the fields take C0C0C0 etc as its value. If try OSYS=WinXP, then all the digits becomes to 0 and F. So, Ok, it's no viable, and I rather abandon because it could works very fine, but it's designed highly to it not work if the OS is not a Windows, and ok, I can see the display and I can use other OS, but none will work properly, and well, it's all

I put your provided code in my DSDT, and nothing happened. It seem a good code, thank you. But it doesn't work to me, and at this moment, I hesitate seriously about that code gets work in any Dell. Well, the code seem to be good, at least I think so, but the issue is that the method _Q66 never is triggered!. This method's _Qxx, are called from the BIOS or embedded controller, and, I thought your code should work, fine or bad, but it should work in some way because it's under the unique _Q that exist ion this DSDT. Then, because it's doesn't work, I made a script, which add a debug store inside every thing, and I run it. The result was very very disappointed, but in the other hand this help me to understand better what happen here. This is a example of the debug code that I added almost in every line: And this is the poor result I got: Then I traced that log in the dsdt, and this is the result. ( You can follow the steps, they are ordered by //number_step, there are only 32 ) And that is all. It's like the aliens do something. It stooping abruptly without a clear reason and disappears in the middle of code execution. No longer will back to work anything of the ACPI. No longer a line of ACPI debug is written. The ACPI dead there, and you can connect or disconnect what you want, usb, display, etc.. but the ACPI doesn't work anymore. In this point, I can see the ACPI code is used for the OS (not Windows) like a schedule of the hardware tree, but given the conditions, the OS do not used that ACPI code anymore. And the BIOS neither, simply the ACPI doesn't exist because doesn't work, and nobody use it. Before that, you don't back to get a debug line about the ACPI. Of course that include the _Q66 method, which never is called. I made some progress about the topic, by adding a ECDT table which achieve that the _Q66 works in the ACPI events, and now I'm rebuilding the .dsl for make it works, and also I had to change the method PCI0._INI for avoid it works beyond of OSYS=0x2710. Now I have a big load of ACPI methods that are loaded in the logs, and when the display turn off or on, and when I plug and play any usb, the logs show the ACPI works. This is very short log of the log that now I got from the ACPI when plug and USB (The _Q66 works activated by the BIOS): Well, now you know your Dell DSDT does't work anything, and it's readed by the OS like a 'boot component' for have some idea of the hardware system, but the ACPI Dell computer, are designed aware for it doesn't work, and probably after running, if you don't use windows and you use Linux, BSD, Mac , you don't have ACPI anymore, because Dell think you are Idiot and they know what is the better for you, and what OS can you use and what you can not use.

Yes you are right I think, even I believe in 2013 already should be irrelevant for them. The principal reason why I believe that is because my eyes can see that code, so of course they knew what thy made, and of course I don't go to enter to evaluate their corporation motivates. We were who decided bought Dell, I don't go to blame anybody for my decision.

For end the Story, I would swore that I remember get different result inside of BRT6 according to the order that I put LCD and PS2K notification. So in the other hand we can see a lot of event that never will execute via DSDT. Then I guess BRT6 is called from the BIOS directly like _SB.PCI0.VID.BRT6, and skip SMME and SMIE. Then probably this would be an aware bug for try to make difficult install other OS that Windows. I bought this laptop over 2012 and over 2017 the BIOS A24 was release, so I don't believe the people of Dell don't Know that all these functions don't works via AML ACPI.

Well, then I think, so, I go to try remove the GENS and make the evaluation directly with Arg0 instead of Local0, but is not easy even do that. how you can see here in other post by Hervé again: That function called SMME is called once from SMIE, and SMIE start by: Store (GENS (0x10, 0x00, 0x00), Local0) //<--- we already learned this return 0 alway while arg0 is a number and arg1 is 0 And later make a evaluation If Else, of Local0, where it expect Local0 will take the value of 0x02, 0x08, 0x10, 0x40 or 0x80, but never 0x00, and then, no one of the clause in this function works. It enter, and exit, without doing any single thing more.

Hi, Sorry my English. It's true this is a old topic, but for my, never worked properly. With the help of some kexts I could middle-solve the problem, but never ended for work fine 100% stable. Well, now I have a few of free time, and I searched in the dsdt all the code related with the BRT6. And what a found, gives me a clear explanation to what happen here. There are two post related with this. One is here: https://osxlatitude.com/forums/topic/19433-latitude-e6420-dsdt-review/#comment-120052. The other is the code showed by Hervé about the brightness (here: And this is the code of mi Latitude E6420 Method (SMEE, 1, NotSerialized) { Store (Arg0, Local0) Store (GENS (0x11, 0x00, 0x00), Local0) If (LGreaterEqual (\_SB.OSID (), 0x20)) { If (And (Local0, 0x04)) { \EV13 (0x01, 0x00) } If (And (Local0, 0x02)) { \EV13 (0x02, 0x00) } } If (And (Local0, 0x08)) { Store (GENS (0x1D, 0x00, 0x00), Local0) \EV14 (Local0, 0x00) } } If we follow a bit the code, we will have this: Method (SMEE, 1, NotSerialized) { Store (Arg0, Local0) Store (GENS (0x11, Zero, Zero), Local0) If (And (Local0, 0x04)) { \_SB.PCI0.PEG0.VID.BRT6 (One, Zero) \_SB.PCI0.VID.BRT6 (One, Zero) } Else { If (And (Local0, 0x02)) { \_SB.PCI0.PEG0.VID.BRT6 (0x02, Zero) \_SB.PCI0.VID.BRT6 (0x02, Zero) } } If (And (Local0, 0x08)) { \_SB.PCI0.IGPU.IBL1 (GENS (0x1D, Zero, Zero), Zero) } } Then you can see this: Store (GENS (0x11, Zero, Zero), Local0) And GENS is the 'manager' of the SNVP, SNVG, SNWB, SNRB, SNVC, etc functions what we already know. (see the first link). And know come the spectacle. Method (GENS,3) { //here arg0 = 17, arg1=0, and arg2=0, then: Store (Arg1, Local0)//<-- well, Local0 is 0 now. if type of Arg1 is equal to number { //we enter here, because 0 is a number type Store (SMBI (Arg0, Arg1), Local0) Now, we go to see 'Store (SMBI (Arg0, Arg1), Local0)' to know which value takes Local0. Method (SMBI, 2, NotSerialized) { SNVC (Arg0) //<-- we already know snvc Add (SMIB, 0x04, Local0) OperationRegion (WWPR, SystemMemory, Local0, 0x04) //we already know this Region Field (WWPR, ByteAcc, Lock, Preserve) { SDW0, 32 } Store (Arg1, SDW0) ASMI () Return (SDW0) } Then: //1 SNVC (Arg0) => Method (SNVC, 1, NotSerialized) { OperationRegion (WWPR, SystemMemory, SMIB, 0x04) Field (WWPR, DWordAcc, Lock, Preserve) { SCDW, 32 } Store (Arg0, SCDW)//<-- here we store 00 00 00 11 (0x11 in Dword)in SMIB pos } //2 OperationRegion (WWPR, SystemMemory, Local0, 0x04) //we already know this Reg Field (WWPR, ByteAcc, Lock, Preserve) { SDW0, 32 } Store (Arg1, SDW0)//<-- here we store 00 00 00 00 in SMIB + 4 position //3 ASMI() => OperationRegion (SMIR, SystemIO, PSMI, 0x01) Field (SMIR, ByteAcc, Lock, Preserve) { SCMD, 8 } Store (0x04, SCMD)// here we store 0x04 always and nothing more //4, The surprise! Return (SDW0) //<-- we two steep before, did something like Store (Arg1, SDW0), and Arg1 was 0. //this means return 0x00000000 Well, now we know that inside of GENS ' Store (SMBI (Arg0, Arg1), Local0) ' assign 0 to that Local0 when GENS is called, and GENS always return its Local0 to the Local0 of SMME, and you can see at the start of this mess-up that SMME expects three valid values, 2, 4, or 8. What happen?, well, Local0 of SMME always is 0 since GENS always return 0, and in this case, the call for BRT6 never will be triggered. In conclusion, the brightness never will can work. I don't say could work good or bad, it's more simple still, never will can work.

Hi! Excuse my bad English, I try it. Well, I have a Latitude, so, the name of the forum seems like tailored :). Also, that I go to write here, I think 'affect' almost every Dell, at least I found the same 'problem' for Latitude, Vostro, XPS and Inspiron. My original dsdt, (I have BIOS A24) had 100 error. Those error was clearly error, some of them difficult to accept because they were too big errors, but well, anyway I solved that. But, so many errors leaded me to think about the full code, even when it hasn't errors now, I readed shallow the code and easily I saw that code could be very much optimized, and I made willing to at least, give it a review, and due that, I have done a trace of my DSDT functions sequence, and I can't understand utterly. Here is a summary of the DSDT trace from the start of a Latitude: __________________ //Running DSDT of Dell e6420 Nvidia i7-2640 Scope (_SB.PCI0) { Method (_INI, 0, NotSerialized) { //Here go to ev1, and later to other, but the final point of the redirects is: Store (^LPCB.EC.ECR1 (0x06), APRE) ———— Then ECR1: Method (ECR1, 1, NotSerialized) { If (LEqual (ECRD, Zero)) { Return (EISC (0x80, Arg0, Zero)) ———— Then ECRD : Scope (\) { Name (ECRD, Zero) ———— Then, due ECRD=0, ECR1 return EISC (0x80, Arg0/*arg0=0x06*/, Zero) : Method (EISC, 3, NotSerialized) { Acquire (ECSX, 0xFFFF) Name (ECIB, Buffer (0x04) {}) CreateByteField (ECIB, Zero, ECIC) CreateByteField (ECIB, One, ECP1) CreateByteField (ECIB, 0x02, ECP2) Store (Arg0, ECIC) //<— here ECIB[0]=0x80 Store (Arg1, ECP1)//<— here ECIB[1]=0x06 Store (Arg2, ECP2)//<— here ECIB[2]=0x00 Store (GENS (0x08, ECIB, SizeOf (ECIB)), ECIB) ———— Then ECIB = GENS (0x08, ECIB, SizeOf (ECIB)) Method (GENS, 3, NotSerialized) { If (LEqual (ObjectType (Arg1), 0x03)) //<— obj type 3 = buffer, and arg1 is a buffer, so enter here { Store (SMBF (Arg0, Arg1, Arg2), Local0) ———— Then SMBF: Method (SMBF, 3, NotSerialized) { SNVC (Arg0) Divide (Arg2, 0x04, Local0, Local1) Store (Zero, Local1) While (LLess (Local1, Local0)) { SNWB (Arg1, Local1) Increment (Local1) } While (LLess (Local1, Arg2)) { SNVP (Arg1, Local1) Add (Local1, 0x04, Local1) } ———— ———— Let's go to stop here and repeat more in details SMBF //1) SNVC (Arg0) means => OperationRegion (WWPR, SystemMemory, SMIB, 0x04); Field (WWPR, DWordAcc, Lock, Preserve) {SCDW, 32 }; Store (Arg0, SCDW) //<-- then SCDW = 00 00 00 08 //If SMIB == 0x1000 then memory address 0x10000=00, 0x10001=00, 0x10002=00 and 0x10003=08 2) Divide (Arg2, 0x04, Local0, Local1) //=> 4/4 = 1, then local1=1 and local0=0 3) Store (Zero, Local1)//<-- set local1 to 0 4) While (LLess (Local1, Local0))//<— skip this because both, local1 and local0 are equal, { SNWB (Arg1, Local1) Increment (Local1) } 5) While (LLess (Local1, Arg2)) //<— enter here, because local1=0 and Arg2=4 { //6) SNVP (Arg1, Local1) means => OperationRegion (WWPR, SystemMemory, Add (Add (SMIB, Arg1), 0x04), 0x04); Field (WWPR, ByteAcc, Lock, Preserve) {SDW0, 32}; CreateDWordField (Arg0, Arg1, SVAL); Store (SVAL, SDW0); Add (Local1, 0x04, Local1)//<-- add 4, and now local1=4, and there is only one itinerancy for this time, and end here. } __________________ In the point 6, inside of SNVP function, I would say the real value of ECIB in that moment should be: ECIB = Buffer(0x04){0x80, 0x06, 0x00, 0x00} Well, then the SNVP 'while' clause, makes this: CreateDWordField (ECIB, 0, SVAL) //<— SVAL = 00 00 06 80 But, the access is ByteAcc, so, I believe that access force to get only one byte, and after math we will have: Store (SVAL, SDW0);//<— SDW0 = 00 00 00 80. Then the real value of than buffer, isn't stored in SDW0. I believe that access of ByteAcc for a Dword field with a dword region space, and a dword buffer, and a dword itineration, could be a mistake and perhaps should be dword access (like SNVC at the beginning of SMBF) Even the name 'SDW0' I would say stands for 'Storage Double Word 0', and the buffer have 4 bytes, even the itineration are 4 bytes to 4 bytes. All match for have a Dword access, but what there is written is ByteAcc I think if the field WWPR of SNVP would have a DwordAcc , then I guess in that point SDW0 would be 00 00 06 80 (which is the real buffer value) instead of 00 00 00 80 that is what I believe it will take with the ByteAcc. With a ByteAcc for a DwordField and only one itineration, I can't understand I searched and found DSDTs of other Dell model, but all of them are the same. For all Dell model from the same epoch, the SNVC (Storage Non Volatile Constant), SNVP, SNVG, SNWB, SNRB, are common ACPI functions and are the same functions. But I see those functions and I can't squaring the mean of them in a global manner, and as I said before, when you have some document which contains 100 well-know errors, you ended asking you self, how many more error it will have?, so a would rather ask about it. So I want to die happy, and I beg for help from someone that explain me what going on here. Any case, thank you very much people for so many useful help.