Contribute
Register

[Guide] How to patch DSDT for working battery status

Hi!
Just have to say that your work is perfect!

Tried to patch DSDT for Asus N55SL and it seems near to match with battery_ASUS-G75vw.txt (https://github.com/RehabMan/Laptop-DSDT-Patch/blob/master/battery/battery_ASUS-G75vw.txt) patch. Only 2 syntax errors encountered in which B1B2 method set out of DefinitionBlock's closing brace. Like this:
Code:
    Method (WAK, 1, NotSerialized)
    {
        \_SB.ATKD.GENW (Arg0)
        \_SB.PCI0.GFX0.OWAK (Arg0)
        \OEMW (Arg0)
    }
}
Method (B1B2, 2, NotSerialized) { Return(Or(Arg0, ShiftLeft(Arg1, 8))) }

I'm not sure I understand what you are referring to... Please clarify.

The Asus N55SL patch is already in the repo.

If you want me to add/change something, post your native DSDT. And your proposed changes.

Could you write some extension to your Guide about WECB Method and using it for writing to EC's fields.

There are plenty of examples in the repo. It is used when you have to write to an EC field of more than 32-bits (an EC buffer).

I know that it is usable now for some machines and very handy versus WRBA.

Either method for EC buffers works. The RDBA/WRBA was a technique I used prior to coming up with RECB/WECB. RECB/WECB use a loop, where in RDBA/WRBA the loop is unrolled.

Because in the repo it is not completely understandable what to do with the third Argument Arg2.

It is described in post #1.

It is very handy to use RECB and WECB for the "big" fields, but to 16, 32, 64 and so on it is handy too.

For fields larger than 32-bit, you should use RECB/WECB. For fields 32-bit or smaller, you should use B1B2/B1B4 and individual Stores (in the case of writes). Using RECB/WECB for fields 32-bit or smaller is messy and not recommended.

*** PS. Could you explain me one more time why it is needed to patch in ACPI code those >8bit fields, but not to translate them completely by kext?

It is not possible to fix this with a kext.
 
Thanks for your help. Fixed and deployed the updated DSDT on my surface pro 3. It seems to work better than before. battery icon used to show no battery every few seconds. it no longer does that with this updated patch

One small question though. Battery "until full time" does not seems accurate (says 10 min to charge from 50% to 110%). Do you think anything in the patch can help with that?

The time is based on the data reported by DSDT. You should use the debug ACPIBatteryManager.kext to take a look at the numbers.

How's that SP3 hack going anyway? I always dismissed the SP3 it because of the incompatible WiFi and the inability to replace it.
 
I'm not sure I understand what you are referring to... Please clarify.

The Asus N55SL patch is already in the repo.
battery_ASUS-N55SL.txt uses the old methods RDBA/WRBA that's why I wrote about battery_ASUS-G75vw.txt also matches, but with 1 syntax error (and maybe second error with B1B2 staing out of DefinitionBlock {} caused by strange factor)
If you want me to add/change something, post your native DSDT. And your proposed changes.
I'll post later.

There are plenty of examples in the repo. It is used when you have to write to an EC field of more than 32-bits (an EC buffer).
Examples in the pero looks like
Code:
WECB(0x1c,256,%1)
and not completely understandable what it should be in Arg2 (which is %1) till user completes that patch to his DSDT. That is because I asked you to complete your guide at 1st page. And in the attach your example of DSDT doesn't contain any B1B2, B1B4, L1L4 or RECB/WECB, RDBA/WRBA methods.
Just in few words about WECB write explanation, please!
I got it, but some users shouldn't.

Using RECB/WECB for fields 32-bit or smaller is messy and not recommended.
Why not? When I patch for some users their DSDT, I'm using manual patching and never used autopatches. It is handy to use only RECB/WECB w/o need to split 16 bit fields. I have only to count offsets and then can erase those fields completely from code, because they don't needed anymore.
 
battery_ASUS-N55SL.txt uses the old methods RDBA/WRBA that's why I wrote about battery_ASUS-G75vw.txt also matches, but with 1 syntax error (and maybe second error with B1B2 staing out of DefinitionBlock {} caused by strange factor)

The N55SL patch was written before I created the RECB/WECB methods (and before I wrote this guide). That doesn't mean that the patch needs to be rewritten.

There is no syntax problem that I know of. If you wish to provide further details, please do so.

Just in few words about WECB write explanation, please!

The parameters to WECB are fully described in post #1 of this thread. Perhaps you missed it.


Offsets are harder to calculate for most than simply splitting the field. In addition, changing the names of the fields allows the compiler to find all the code that needs to be changed. Not changing the names leaves the potential for human error (missing an access).

You, of course, are free to do what you want with your patches, but I'm not about to change the guide nor my own methods.
 
The parameters to WECB are fully described in post #1 of this thread. Perhaps you missed it.
Nope. Only 1 sentence:
This DSDT does not have any writes to EC buffers, but if it did, this utility method is useful:
and only 3 lines for argument values
Code:
Arg0 - offset in bytes from zero-based EC
Arg1 - size of buffer in bits
Arg2 - value to write
but no explanation with example on code how to use WECB and it's Args, especially for Arg2.

Sorry for misunderstanding.
 
Nope. Only 1 sentence:

and only 3 lines for argument values
Code:
Arg0 - offset in bytes from zero-based EC
Arg1 - size of buffer in bits
Arg2 - value to write
but no explanation with example on code how to use WECB and it's Args, especially for Arg2.

Correct. And with that information, coupled with knowledge of RECB, examples within the existing patches in the repo, plus numerous examples/explanations within this very thread, it is enough to determine the correct usage. Arg2 is, as the comment states, the value to write to the EC.
 
Correct. And with that information, coupled with knowledge of RECB, examples within the existing patches in the repo, plus numerous examples/explanations within this very thread, it is enough to determine the correct usage. Arg2 is, as the comment states, the value to write to the EC.
You are always referring users to your #1 post to read the MAN. But it is incomplete!
Sorry, but it is real incomplete! I read almost full thread, but can't remember anything about WECB usage, just whines for help :)
For example, when I needed WECB for first usage, I had completely at a deadlock how to use it.
I referred to RECB usage, but it was completely incorrect and broke me up for searching from your tutor to google and repos :)
For example, my first error was (completely as RECB usage):
Code:
// Correct RECB usage:
// Store (BDAT, Index (Local0, 0x02))
Store (RECB (0x1c, 256), Index (Local0, 0x02))
Code:
// Incorrect try:
Store (DerefOf (Index (Arg6, 0x01)), BDAT)
//  tried to add WECB here, but stopped with incomplete knowledge
Store (DerefOf (Index (Arg6, 0x01)), WECB (0x1C, 256, .?.))
and I was deadlocked here.

Now are you understand me, why I asked you to complete your tutor?!
 
You are always referring users to your #1 post to read the MAN. But it is incomplete!
Sorry, but it is real incomplete! I read almost full thread, but can't remember anything about WECB usage, just whines for help :)

Use search. There are two pages of results if you search this thread for WECB.

For example, when I needed WECB for first usage, I had completely at a deadlock how to use it.
I referred to RECB usage, but it was completely incorrect and broke me up for searching from your tutor to google and repos :)
For example, my first error was (completely as RECB usage):
Code:
// Correct RECB usage:
// Store (BDAT, Index (Local0, 0x02))
Store (RECB (0x1c, 256), Index (Local0, 0x02))
Code:
// Incorrect try:
Store (DerefOf (Index (Arg6, 0x01)), BDAT)
//  tried to add WECB here, but stopped with incomplete knowledge
Store (DerefOf (Index (Arg6, 0x01)), WECB (0x1C, 256, .?.))
and I was deadlocked here.

Your problem is lack of knowledge of ACPI/AML language. Teaching basic ACPI concepts (really programming concepts) is outside the scope of this topic.

Now are you understand me, why I asked you to complete your tutor?!

I have added a simple example to post #1.
 
RehabMan, I have a problem with battery information, because when left only 2% of the battery I see that AC-adapter is plugged in, but really it is not plugged and as a result the laptop turns off when the battery got 0%. Is it the driver problem or DSDT?
 
RehabMan, I have a problem with battery information, because when left only 2% of the battery I see that AC-adapter is plugged in, but really it is not plugged and as a result the laptop turns off when the battery got 0%. Is it the driver problem or DSDT?

Looks like "pilot error" to me. Make sure you fully seat the AC adapter next time.
 
Back
Top