Support MacOS

[nekr0z]

People are running MacOS on Matebooks, and it looks like matebook-applet would be welcome there.

It should be relatively easy to add MacOS-specific endpoints and have them probed when running the applet on MacOS. All our dependencies support MacOS, so there shouldn't be a problem.

Two things prevent me from implementing this straight away:

1. Their current way of doing things doesn't allow to set arbitrary thresholds. Setting arbitrary thresholds is more versatile and is our preferred way of interacting with endpoints. It can be worked around, but I'd prefer not to if there's a way.
2. It's unclear how to get the currently set values on MacOS.

[profzei]

Here I am. As I said, I am very happy to collaborate with you. Thank you very much for your willingness!

Their current way of doing things doesn't allow to set arbitrary thresholds. Setting arbitrary thresholds is more versatile and is our preferred way of interacting with endpoints. It can be worked around, but I'd prefer not to if there's a way.

I have to do some tests on the script created by @ldan93 but, in my opinion, it should be possible to set arbitrary thresholds.

It's unclear how to get the currently set values on MacOS.

@ldan93 uses the following steps:

1. loading (i.e. injecting during boot phase) a sort of library/driver (created mainly for debugging purpouses) called kext on macOS i.e. ACPI_Debug.kext
2. loading a SSDT-RMDT.aml file during boot phase which is a file with user-defined methods in ACPI language for interacting with ACPI_Debug.kext
3. using ioio utility for calling those user-defined methods declared in SSDT-RMDT.aml file

I think it should be possible pass some arbitrary values to ioio utility -> user-defined methods in SSDT-RMDT.aml file

[nekr0z]

in my opinion, it should be possible to set arbitrary thresholds.

From what I have understood, there's no straightforward way (using that script) to set, for example, 35-75 or 56-71 (i.e. totally arbitrary values for both high and low as long as low<high). Having such a possibility would be ideal, and make the applet adaptation much less of a hassle.

it should be possible pass some arbitrary values to ioio utility -> user-defined methods in SSDT-RMDT.aml file

I need to read into all of this more, I'm totally unfamiliar with the whole ioio deal, or even with how MacOS talks to ACPI in the first place.

Basically, here's what I have in mind as an algorithm:

1. The applet issues a command that returns the current battery limit values. This can be basically a command you'd put into a terminal to read the results from the same terminal. It can be complicated, if needed, involve more than one step and such. This command is the first thing that needs to be figured out.
2. The applet parses what it got from that command, and either figures out the current settings (and can display it for the user) or decides that what it received doesn't make sense and maybe the user didn't install all the necessary utilities or hasn't loaded the necessary modules at boot-time. In the latter case the applet can throw a error message and advise the user to go read some manuals and install the required things.
3. At the user's command, the applet sets the required limits, and goes back to 1. to check that the limits have been set as asked.

Actually, this is how it currently works on Linux. Figuring out the command (set of commands) for 1. is the first step (and half the job, really).

[ldan93]

Hello @nekr0z and @profzei
Porting matebook-applet to MacOs would be very very nice, thank you for your implication !
The current implementation is very hacky but I'm sure there are some workarounds. Here are some thoughts :

1. About setting arbitrary thresholds : there is a way. We can write an ACPI method that takes the thresholds as an argument and then sets them. The only limitation is that you can only pass one argument to an ACPI method with ioio. The most convenient way would be to directly send the whole argument used by the \SBTT method (ie. XXYY0000 where XX is the max value and YY the min value coded in hexadecimal)
2. About getting the current values : it's quite tricky. Currently, what my basic script does is : request the values through an ACPI call, and then the values are written in the system logs of MacOS. Theoretically, we might be able to extract the values from the terminal by parsing the system log file, but this is not ideal.
   I'm sure there is a more conventional way of getting EC/ACPI values in MacOS, but I don't know how... We might ask for help in the ACPI-Debug's thread on Tonymacx86...

[nekr0z]

send the whole argument used by the \SBTT method (ie. XXYY0000 where XX is the max value and YY the min value coded in hexadecimal)

Perfect, we'll do that.

we might be able to extract the values from the terminal by parsing the system log file, but this is not ideal.

Yep, I've already toyed with this idea. Doable, but too many moving parts, I'd prefer some other alternative.

[ldan93]

So, I've written a basic ACPI Method (DGB5) in SSDT-RMDT.aml

It takes the XXYY0000 argument as an input.
In terminal, you must type in :
./ioio -s org_rehabman_ACPIDebug dbg5 ARG
Where ARG is XXYY0000 converted to a decimal number (because ioio expects a decimal number)
Ex : if you want to set the thresholds to 60-80 (so 3C-50 in hex) --> the SBTT method needs to receive "0x503C0000" --> this is 1346109440 in decimal :
./ioio -s org_rehabman_ACPIDebug dbg5 1346109440

[nekr0z]

./ioio -s org_rehabman_ACPIDebug dbg5 ARG

Is there a reasonable expectation of where ioio is on the system? ./ requires cd to that directory, which is not straightforward to do for a GUI app ;-)

[ldan93]

Well, currently I put ioio in /Applications/Utilities. But I'm thinking it might be better to put it in the /usr/local/bin folder. So, this way the ioio command could be invoked system-wide no matter the current active directory. What do you think ?

[nekr0z]

I think if we can't really rely on ioio being accessible from some standard place (or PATH, or whatever), I'd better figure out how to talk to kext directly. ;-)

[ldan93]

Well, ioio is basically a binary that must be downloaded and manually copied somewhere by the user. It's not installed through a standardised package like in a Linux environment. But that's not really a problem, since we can tell users where to put the binary in @profzei documentation. Or maybe you could package ioio with matebook applet ?

About avoiding using ioio : well, after some research, I truly think this utility is the most convenient way of calling ACPI method from user-space, and more generally it is precisely designed to interact with kernel extensions. But if you find a better option, that's perfect !

[ldan93]

About getting the current thresholds, I've investigated the process of parsing system logs. Even if it's not the best path, this is achievable with this script I wrote :

#!/bin/sh
#  threshold.sh
log stream --predicate 'senderImagePath contains "ACPIDebug"' | sed -n 's/.*XXYYZZ", \(.*\), "ZZYYXX.*/\1/p' &
sleep 0.2
ioio -s org_rehabman_ACPIDebug dbg4 0
sleep 0.2
killall log

• We can monitor the log specifically related to the ACPIDebug kext with the log stream ... command
• I've modified the ACPI method reading the thresholds (dbg4), so that its output is printed in log between a "XXYYZZ" and "ZZYYXX" string
• The sed command then finds the XXYYZZ MIN MAX ZZYYXX pattern, cleans the log, and outputs the thresholds to shell when the log process is killed :

(In my example, the thresholds are 40-50%, so 28-32 in hexadecimal)

[nekr0z]

OK, I'm getting close to hacking up a crude prototype, but my lack of MacOS knowledge starts showing. Please enlighten me, because I'm kinda lost here.

1. They do have PATH in OS X, don't they? And I can reasonably expect ioio to be in PATH, right?
2. OS X is basically BSD and is supposed to have ioreg that knows everything about the current state of hardware-related variables. Could we get thresholds from ioreg?

[profzei]

They do have PATH in OS X, don't they? And I can reasonably expect ioio to be in PATH, right?

Positive answer! (we can put ioio into PATH)

Could we get thresholds from ioreg?

I tried to look at into my ioreg but I didn't find any useful info about battery thresholds maybe because I didn't look for the "right entry"

[nekr0z]

Positive answer! (we can put ioio into PATH)

That's good. Makes it actually feasible to use ioio, at least for a start. I've found a library that supposedly allows talking to KEXT directly, but since I know very little about KEXT and can't really debug things without running OS X on my Matebook (which I'm not planning to do), the debugging would be extremely hard.

I tried to look at into my ioreg but I didn't find any useful info about battery thresholds

Would you mind patching your ioreg output to a text file (i.e. ioreg > ioreg.txt) and letting me have a look? It will only give one of the planes by default, but the ACPI devices are likely to be shown...

In other news: I've been able to compile matebook-applet on OS X and make it run. Cross-compiling graphical applications turns out to be unfeasible, so I requisitioned my wife's old MacBook Air. Unfortunately, it runs very ancient OS X (10.8 or something), which is probably why I'm getting compilation errors and applet mode crashes. The good thing is, windowed mode does run, so I can do some debugging (as much as possible without the actual hardware, that is).

If someone has Go installed, I'd appreciate if you tried to clone this repository, check out the darwin branch, go run build.go, and try to run ./matebook-applet -vv to confirm it indeed does run and puts the icon in the tray (it doesn't do much more on OS X yet) instead of crashing like on the machine I have. :) If, however, you don't have Go installed, don't bother: we'll have a working prototype soon, we'll test it in the windowed mode, and then merge it to master branch and have Travis build it on a decent enough OS X version…

[ldan93]

On my computer, with macOS 10.15, it builds but it doesn't run/put the icon in the tray... I have attached the build logs and the output of ./matebook-applet -vv : logs.txt.zip

[nekr0z]

On my computer, with macOS 10.15, it builds but it doesn't run/put the icon in the tray... I have attached the build logs and the output of ./matebook-applet -vv : logs.txt.zip

Thank you so very much! It's awesome that you have Go set up, your help in debugging is priceless.

Looks like we're hitting a known issue with the systray library. It only manifests on OS X. Since your behaviour is the same as mine, I can further debug this one by myself.

But first let's get at least something working. I've pushed some new code to the darwin branch. It would be awesome if you could build it (the build log will spit some warnings, don't mind), run ./matebook-applet -vv -w, and show me the output. It would be absolutely great if you used the SSDT-RMDT that you posted before and not the one you've customized for the script: it's the exact output that I'm interested in.

What's supposed to happen is for the applet to do all the steps from threshold.sh up to the point of getting the relevant log line, then clean up by killing the log process. The actual parsing is not yet coded, so the applet will assume battery protection is off and draw the window accordingly.

[ldan93]

You're welcome !
So I've built the new code and run it with my previous custom SSDT-RMDT (the one without the XXYYZZ stuff).
Here's the output : logs2.txt.zip
The window is drawn :

I've been thinking about something else : I used your applet in Linux before switching to MacOs. I've just remembered that there was an option to tweak Fn-Lock. I definitely think I could quite easily add relevant ACPI methods in the SSDT-RMDT to get and set Fn-Lock state, so we could also implement this later on.

[nekr0z]

@ldan93 thanks again! We're closing in.

I've been trying to nail that systray issue, but with no luck yet. I still have a couple of ideas to try, so not all is lost (yet). For now I've simply disabled the applet mode for OS X (i.e. it's always -w, even it you don't specify it).

I've pushed more code, and would appreciate a final test. If I got it right, it should parse the thresholds, paint a window and even allow setting the thresholds. If I made a mistake somewhere (which is totally possible and actually likely) and something doesn't work, I'd appreciate the -vv output. ;)

[nekr0z]

I definitely think I could quite easily add relevant ACPI methods in the SSDT-RMDT to get and set Fn-Lock state, so we could also implement this later on.

Totally. If battery thresholds work, implementing FnLock control will be a piece of cake. All I need is:

• the hook to read state (i.e. ioio -s org_rehabman_ACPIDebug WHATEVER),
• a sample of a log line I'm looking for (like kernel: (ACPIDebug) ACPIDebug: { "Reading (hexadecimal values):", 0x28, 0x3c, } you gave me for thresholds, and
• the hook to set state.

[nekr0z]

Ok, I was finally able to make the applet mode work. Unfortunately, with these libraries on OS X there seems to be no way to have a window drawn and the systray at the same time, so no custom threshold settings for the applet mode, sorry. Should work in the windowed mode, though.

[ldan93]

Thank you so much !! Seeing this project materialising at such a great pace is so cool !

So, the applet mode is drawn as expected and the applet is able to set the thresholds. Here are some observations :

• At the moment, matebook-applet is still reporting that Battery protection is OFF even though it's not the case

• From what I understand from reading the verbose mode : after clicking on a battery protection mode, matebook-applet sets the thresholds, and immediately reads the new thresholds by checking the logs. I think this check is done a bit too early : everytime a threshold is set, the log displayed in verbose is still reporting the previous state, even though the new threshold seems to be actually set. I don't know if I'm making myself clear, but you will see in my logs that every time I click on a mode, battery threshold reading seems to always be "one step behind". Is this the expected behaviour ?

logs3.txt.zip

[nekr0z]

* still reporting that Battery protection is OFF even though it's not the case

Oops, missed that one. Should be working with the latest code.

* Is this the expected behaviour ?

Not really. :)
I've put a 500 ms delay in the latest commit, hope it does the trick. We can always increase it if that's not enough.

Try again?

[ldan93]

• The applet is no longer reporting Protection OFF 👍

• I think the 500ms delay is slightly not enough : the logs are now accurate... 2/3 of the time. Maybe we can try 1 sec ?

• Is there a way of running the applet without having a Terminal window opened ? (Launching the binary from the file explorer or putting it in the startup programs always open a Terminal in the background)

[nekr0z]

• delay is slightly not enough : the logs are now accurate... 2/3 of the time.

Actually, there used to be the same issue with the linux driver, and we even have code to mitigate it. That has long been obsolete, as the linux driver was fixed by Ayman, but the code is still there. I activated it for OS X, should to the trick.

• Is there a way of running the applet without having a Terminal window opened ? (Launching the binary from the file explorer or putting it in the startup programs always open a Terminal in the background)

I wouldn't really know, MacOS is not really my realm. ;) From what I gathered so far, I need to make something called an App Bundle, which should be relatively straightforward to do. I was planning on figuring this out as soon as we have the applet really working, so it looks like that's what I'll be doing next.

The plan is to have a build script option to generate that App Bundle thing when building for MacOS.

[ldan93]

There is a small issue that I forgot to report :

• Setting battery protection OFF works : the battery charges again
• BUT it is not reported by the applet : it displays "HOME", whatever what the previous mode was, and in the logs it seems the thresholds are read as x28/x46
  logs4.txt.zip

When I wrote my first hacky script, I actually noticed the same strange behaviour : setting thresholds to 0-100 and then reading them would report an unreliable output...

Apart from that, everything is working really nice, thanks again for your wonderful work 👍

[nekr0z]

@ldan93 The applet uses the log trick to report thresholds (as you might have already guessed). Since the log doesn't show the protection is off, the applet can't guess it.

On Linux the driver always reports the thresholds as 0-100 or 0-0 when battery protection is off, and that's how the applet figures it out. We either need to set the thresholds to those values as part of switching the protection off, or else we need some command or a log trick for the applet to probe whether the protection is off.

Currently for setting the thresholds the applet uses your DBG5 method, except for actually for switching it off, which is done by calling your DBG0 method. Looks like the DBG0 method, while turning the protection off, fails to change the thresholds that later get reported in the log. I noticed that it has \SBTT (0x64000000) inside, so it does try to set 0-100. I wonder if trying to set 0-0 instead would do the trick…

[ldan93]

Setting 0-0 doesn't do the trick...

About the DBG0 method : actually, we should not use this one, this was a very bad implementation I wrote... Because of the "Sleep" function in the ACPI code, it makes the Matebook freeze for one second. Just using the DBG5 method with 0 - 100 values (so the argument would be 1677721600) disables battery protection in a more acceptable way. Would you mind using this way ?

Then, I've done some reverse engineering on the EC registry. I think we've got a way of knowing whether battery protection is OFF or ON :

• We must read the 0x0343 field of the EC registry with the \_SB.PCI0.LPCB.EC0.RRAM method (the same way we read the thresholds in DBG4)
• From my understanding : 0x80 means battery protection if OFF, and 0xc0 means it's ON (I'm not 100% sure, but this has been consistent across many tries)
• ATM moment I've modified the DBG4 method so it sends on more line to log with battery protection state (after the line with the thresholds). Here's how it looks in the logs. But if you want me to implement Battery protection state reading in a dedicated method (DBGsomething), I can also do this.

[nekr0z]

* From my understanding : `0x80` means battery protection if OFF, and `0xc0` means it's ON (I'm not 100% sure, but this has been consistent across many tries)

Nope. Well, maybe your model is an exemption, but on all MateBooks I've seen, including mine, that one is for "charging allowed/disallowed". If your protection is on, it will be 0xc0 when the required level is reached (so that the laptop doesn't charge the battery anymore), and turn into 0x80 as soon as the battery charge drops below the desired level.

[ldan93]

OK then, this was a bad guess, never mind...

[nekr0z]

Setting 0-0 doesn't do the trick...

You did it manually via DBG5, right? Not via the applet? Because the applet wouldn't really do that for now.

we should not use this one

OK, will change.

[ldan93]

You did it manually via DBG5, right? Not via the applet? Because the applet wouldn't really do that for now.

Yep ! Setting it to 0 strangely resets the thresholds to 40-70...

[nekr0z]

@profzei ioio gets called and gives no error (or we'd see complaints), but the log readings are empty, neither DBG4 nor DBG6 produce valid log output (or any ACPIDebug-marked log output, for that matter). @ldan93 any ideas on further investigation strategy?

[ldan93]

@profzei

Could you please open a Terminal and type-in the following command :
log stream --predicate 'senderImagePath contains "ACPIDebug"' > log.txt

Then, while keeping this process running, open another terminal instance (new window or tab), and type in one by one the following commands :

ioio -s org_rehabman_ACPIDebug dbg4 0
ioio -s org_rehabman_ACPIDebug dbg7 0
ioio -s org_rehabman_ACPIDebug dbg5 1677721600
ioio -s org_rehabman_ACPIDebug dbg4 0
ioio -s org_rehabman_ACPIDebug dbg1 0

After that, go back to the first terminal (with the log stream process). Kill the process with CTRL+C.

You should have a log.txt file in you home directory (or wherever you were when you launched the log stream command).
Please, upload this log.

[profzei]

@ldan93 Here is the requested log file
log.txt

Edit: it's almost empty...

[nekr0z]

@profzei the applet relies on the information in the log to read the battery values and the Fn-Lock state. Since you have everything properly loaded (or so I understood from the previous messages), my first (and only, actually) logical guess is something is switched off in the logging system itself, so that the messages ACPIDebug sends to the logging system don't end up in the log. @ldan93 may have more ideas, but I know too little about MacOS to be of any help in solving this particular mistery.

[profzei]

@nekr0z Yes I agree with you: it's completely clear.

But, as I said, my install should be standard so this "issue" could be relevant also for many other users interested in this applet...

[nekr0z]

@profzei Absolutely!

[nekr0z]

Sorry, misclicked.

[profzei]

@ldan93
Just to be sure... what are your settings in config.plist for Misc -> Debug variables? ...in particular for Target key?
Mine are those you could find in my releases which are based on non-debug OpenCore release! Did you changed something for ACPIDebug.kext in your config.plist?

[ldan93]

To check if it's just a problem of log tracing, can you tell us whether ioio -s org_rehabman_ACPIDebug dbg5 1677721600 does disable battery protection ?

Can you also try to :

• Open Console.app
• Type-in "ACPIDebug" (without the quotes) in the filter/search field, press Enter
• Open a Terminal without closing Console, and type in ioio -s org_rehabman_ACPIDebug dbg4 0
• Do you see something traced in Console.app ?

I don't remember changing something in config.plist other than adding ACPIDebug.kext in kext section and SSDT-RMDT.aml in the ACPI/Add section... Please find my : config.plist.zip (I've only removed my serial number data)

I must say that, from what I remember, I just followed Rehabman's readme

EDIT : I don't know what is you current kext loading order, but if that's not already the case, can you try to load ACPIDebug as the very last kext ?

[ldan93]

OK, so I've done some research. I think there's a problem with macOS Big Sur and ACPI_Debug.kext log feature. Here is what I've tried :

• I wrote a custom method, DBG9, that triggers the led on the F7 key (mic mute button), so I can visually check if this ACPI call is actually made. ioio -s org_rehabman_ACPIDebug dbg9 65536 lights up the F7 key, ioio -s org_rehabman_ACPIDebug dbg9 0 switches the light off. It works as expected on Catalina, and we get some text in system logs with log stream or Console.app .

• Then, I tested these commands on macOS Big Sur 11.1, by booting the USB installation key and using Terminal.app from there (so this is not the typical Big Sur environment, it's more of a rescue mode). I can confirm DBG9 works from there, because the mic light can be switched on/off with ioio. HOWEVER, I cannot get any kind of related logs with log stream.

@profzei Can you perform the same DBG9 test on your real Big Sur environment please ? Here the new SSDT with DBG9 method : SSDT-RMDT.aml.zip

There is at least another GitHub issue where someone wasn't able to get logs from ACPI Debug with Big Sur.

The kext hasn't been updated since 2015, but it worked with all macOS versions since then, we are very unlucky... But its developer is still very active in the hackintosh community, so we can get in touch with him to report the issue. Well, actually not, he kind of retired from the hackintosh community. So we have to figure this out on our own, or find another way of reporting values without the log trick in macOS Big Sur...

[profzei]

@ldan93
If I run command ioio -s org_rehabman_ACPIDebug dbg5 1677721600 then nothing changed in the matebook-applet but battery stops to charging as if you had set the current battery value as the charge limit.

I followed your steps for Console, but nothing is traced in Console.app with ACPIDebug as filter...

[profzei]

@ldan93 I'll do it probably this night...

Do you think DebugEnhancer or YogaSMC are viable solutions?

[profzei]

I don't remember changing something in config.plist other than adding ACPIDebug.kext in kext section and SSDT-RMDT.aml in the ACPI/Add section... Please find my : config.plist.zip (I've only removed my serial number data)

There is one difference: you are loading YogaSMC.kext, me not. I tried loading it but nothing changed... (as expected)

I just followed Rehabman's readme

Me too...

I don't know what is you current kext loading order, but if that's not already the case, can you try to load ACPIDebug as the very last kext ?

Done: nothing changed...

Good news about DBG9

• Loaded new SSDT-RMDT.aml in my real Big Sur environment
• ioio -s org_rehabman_ACPIDebug dbg9 65536 lights up the F7 key: OK
• ioio -s org_rehabman_ACPIDebug dbg9 0 switches the light off: OK

[nekr0z]

I already asked, but looks like it got lost:

Would you mind patching your ioreg output to a text file (i.e. ioreg > ioreg.txt) and letting me have a look? It will only give one of the planes by default, but the ACPI devices are likely to be shown...

Maybe there is a less hacky way to read the values than messing up with the logs after all. Long shot, I know...

[ldan93]

@profzei Thanks for your debugging. It looks like ACPI calls made by ioio are still effective but the log feature is broken in Big Sur. So we have to find another way...
About YogaSMC : yeah I tried to use this kext because it implements EC field reading, but couldn't get it to the work so far. It's designed for Lenovo laptops in the first place.
@nekr0z Please find the output of ioreg : ioreg.txt.zip

[nekr0z]

@ldan93 the objects named EC0, EC, and AppleACPIEC look the most promising. Could you please take look inside them, i.e. ioreg -n EC0 -r, and also for the other two?

[profzei]

@nekr0z @ldan93
I don't know if this could be useful, but I made some tests...

With sudo dmesg command we are accessing the kernel-log. This is a so called ringbuffer of (by default) 4kb size (which can be patched to a larger size by DebugEnhancer.kext [I don't know how...] or via msgbuf-bootarg) and will only show, by default, the last 4kb of the kernel-log. If you get many log-entries, its perfectly possible you are missing many entries. The actual size of msgbuf is checked with sysctl -a kern.msgbuf.

Therefore I put in my config.plist in boot-args the parameter msgbuf=1048576.

I opened a Terminal and typed-in one by one the following commands checking every time what I got with sudo dmesg:

ioio -s org_rehabman_ACPIDebug dbg4 0
ioio -s org_rehabman_ACPIDebug dbg7 0
ioio -s org_rehabman_ACPIDebug dbg5 1677721600
ioio -s org_rehabman_ACPIDebug dbg4 0
ioio -s org_rehabman_ACPIDebug dbg1 0

This is what I got respectively:
ioio -s org_rehabman_ACPIDebug dbg4 0

[ 2011.770322]: ACPIDebug: "View Thresholds"
[ 2011.783462]: ACPIDebug: { "Reading (hexadecimal values):", 0x0, 0x0, }

ioio -s org_rehabman_ACPIDebug dbg7 0

[ 2153.481542]: ACPIDebug: { "Value : ", 0x0, }
[ 2153.481824]: ACPIDebug: "Fn-Lock state set"

ioio -s org_rehabman_ACPIDebug dbg5 1677721600

[ 2193.872452]: ACPIDebug: { "Value : ", 0x64000000, }
[ 2193.872606]: ACPIDebug: "Manually setting thresholds to 0-100"
[ 2193.875455]: ACPIDebug: "Set"

ioio -s org_rehabman_ACPIDebug dbg4 0

[ 2243.377869]: ACPIDebug: "View Thresholds"
[ 2243.383784]: ACPIDebug: { "Reading (hexadecimal values):", 0x0, 0x64, }

ioio -s org_rehabman_ACPIDebug dbg1 0

[ 2286.778231]: ACPIDebug evaluateObject("DBG1") failed (e00002bc)

@ldan93 With the last command battery stopped charging... is it normal?
What command I need to type now to unset this limit?

[ldan93]

@nekr0z Please find the requested ioreg results : ioreg_logs.zip

@profzei Oh, great findings ! Does this bootarg enable you to get these log messages in Console.app (with ACPIDebug search filter) or with the log stream command in another terminal ?

The logs you get with dmesg are totally expected.
But the last command is supposed to do nothing : as the error message indicates, DGB1 method does not even exist, I just wanted to check if calling an undefined method printed something on Big Sur...
The command ioio -s org_rehabman_ACPIDebug dbg5 1677721600 is supposed to disable battery protection, it should already be charging...
You can also try ioio -s org_rehabman_ACPIDebug dbg5 6553600

Tell me if you battery is now charging with these commands...

[profzei]

@ldan93

Does this bootarg enable you to get these log messages in Console.app (with ACPIDebug search filter) or with the log stream command in another terminal ?

...Nope! I cannot see any ACPIDebug related content nor in Console.app nor with the log stream command in another terminal...

The command ioio -s org_rehabman_ACPIDebug dbg5 1677721600 is supposed to disable battery protection, it should already be charging...
You can also try ioio -s org_rehabman_ACPIDebug dbg5 6553600

Yes! Battery is charging fine...

@ldan93
It seems like ACPIDebug.kext cannot write on log stream on Big Sur...
ACPIDebug.kext is an old/unmaintained kext and maybe it needs some changes to work with Big Sur: same situation happened, for example some months ago, to VoltageShift.kext which required upgrade for functioning with Big Sur by implementing what developer called DriverKit layer...
Do you think we could ask some hint to @zhen-zen? He's the YogaSMC's developer so maybe he already faced such difficulties...
If you agree with this, could you try to open a request of help in its YogaSMC repo? (as you see my English skills are very poor in explaining all our situation)

[profzei]

@ldan93 @nekr0z
I found a way for writing on Big Sur system log: I can see messages both on Console.app and using on Terminal the command log stream
...but it needs more tweaking: I'm not able (from the programming point of view) to get one string output with Debug command if more than one argument is passed to a function (I don't know how to concatenate output...)

@ldan93
Reference is https://pikeralpha.wordpress.com/2013/12/23/enabling-acpi-debugging/
Instructions:

• add in boot-args -v keepsyms=1 debug=0x12a acpi_layer=0x8 acpi_level=0x2 (I think -v keepsyms=1 should be not relevant but not tested...)

• add DebugEnhancer.kext both in Kexts folder and in config.plist just below ACPIDebug.kext

• add the following SSDT-DBG.aml in ACPI folder and in config.plist ACPI section
  SSDT-DBG.aml.zip

• add modified SSDT-RMDT.aml
  SSDT-RMDT.aml.zip

• add in config.plist ACPI section the following rename (redirecting ACPI's native ADGB()-helper to syslog):

<dict>
	<key>Comment</key>
	<string>DBG: MBGS to XDBG</string>
	<key>Count</key>
	<integer>0</integer>
	<key>Enabled</key>
	<true/>
	<key>Find</key>
	<data>TUJHUw==</data>
	<key>Limit</key>
	<integer>0</integer>
	<key>Mask</key>
	<data></data>
	<key>OemTableId</key>
	<data></data>
	<key>Replace</key>
	<data>WERCRw==</data>
	<key>ReplaceMask</key>
	<data></data>
	<key>Skip</key>
	<integer>2</integer>
	<key>TableLength</key>
	<integer>0</integer>
	<key>TableSignature</key>
	<data>RFNEVA==</data>
</dict>

Now outputs from commands ioio -s org_rehabman_ACPIDebug dbg* seem to be working...
Matebook-applet is not working yet since output strings need to be properly formatted...

[ldan93]

Thank you very much for these new elements. So, we know there is still a way ! It involves some heavy tweaking though...

Let's see if we get some feedback from @zhen-zen about other options. Maybe there is a more straightforward / cleaner way to do this. But at least we now have a backup plan.

[profzei]

@ldan93 Sure!😊👍🏻

[ldan93]

Hi,
Sorry for coming back so late, I had to wait before upgrading my system to Big Sur and investigate the issue further.

Here are some news :

• I tried to investigate the issue with zhen-zen. He was kind enough to try to help us, but honestly I didn't understand what I was supposed to do to get YogaSMC working and reading our EC values. I totally agree this is a much cleaner and sustainable approach, but I'm afraid this path is getting beyond my abilities...

• On a brighter note : I can report that matebook-applet is perfectly working with Big Sur... If ACPIDebug.kext is manually loaded after boot (and not in OpenCore) : sudo kextload ACPIDebug.kext. This is a bit mysterious, I don't understand why, but it works !

@profzei : do you know what are the differences between loading a kext at boot stage with OpenCore and manually loading the kext ? Could the kext be loaded the same way with OpenCore ? Maybe this is a matter of timing, I don't know...

[profzei]

do you know what are the differences between loading a kext at boot stage with OpenCore and manually loading the kext ? Could the kext be loaded the same way with OpenCore ? Maybe this is a matter of timing, I don't know...

@ldan93 Honestly I don't know... but I guess the issue could be due not to a matter of timing (i.e. if a kext is loaded... it is loaded and that's all...) but maybe which path (i.e. local path or EFI path... since I guess that when you load manually ACPIDebug.kext then ACPIDebug.kext is not placed in EFI folder) kext is loaded from

[nekr0z]

@ldan93 @profzei gentlemen, what you are talking about is waaay beyond my OS X expertise.

Considering the current state of code (and documentation) in the darwin branch, is it a good idea to give it a little brush-up and finally release, or are we still in the woods?

[ldan93]

Well, I think we have to make a decision about the way forward. Here are the possibilities that I see :

1. Implementing a clean way of reading EC values (with YogaSMC) : definitely the ideal way, but I don't feel up to the task. If you feel up to it, you can reach zhen-zhen on the GitHub issue that I mentioned
2. Manually loading the kext after boot in Big Sur : doesn't seem reasonable (the kext is unsigned so it would require disabling MacOS securities)
3. Investigate profzei's lead : promising but requires some more work. And I don't know if it's OK to constantly run the OS with debug boot parameters (security, performances, ...)
4. Since we can still invoke ACPI commands but can't get logs : let matebook applet run in a "write only" mode in Big Sur = we can set battery thresholds but we won't have any feedback / reading of current values. Easiest path in my opinion, but it would be quite a loss of functionality...

@profzei and @nekr0z : what do you think ?

[nekr0z]

I skimmed through your discussion with zhen-zhen, and as much as I'd love to take option 1, debugging it (with zhen-zhen's help) requires running OS X on the hardware, and I don't have a spare Matebook to do that. :(