Open paulvt opened 3 months ago
What is the default location of framework_tool when installed?
I myself build it manually because it is not packages for Debian, so I put it in /usr/local/bin
. If distributed, it is probably just in /usr/bin
. I think we can assume it is somewhere in the $PATH
?
Note that from kernel 6.10 on the --driver portio
parameter is also not necessary on the Framework 11 AMD laptop, because the cros_ec
driver from the kernel works properly.
What happens if I add option --driver to kernel 6.10? Would it throw an error?
Can you run the tool in command line and post the exact command and the output returned by the tool.
Post the output of all commands related to charging threshold. Is there a read threshold command? Or only write threshold command?
I initially did developed the extension with framework tool initially, but I deleted the branch and lost all code and information.
- What happens if I add option --driver to kernel 6.10? Would it throw an error?
No it's using the portable I/O driver in that case, which also/still works.
2. Can you run the tool in command line and post the exact command and the output returned by the tool.
Post the output of all commands related to charging threshold. Is there a read threshold command? Or only write threshold command?
It has both. When not passing an argument it is read:
Reading the charge limit:
$ pkexec framework_tool --driver portio --charge-limit
Minimum 0%, Maximum 80%
Writing 80% as charge limit:
$ pkexec framework_tool --driver portio --charge-limit 80
Minimum 0%, Maximum 80%
Apologize I got too many questions.
Does everyone use portio driver or would there be users using cross_ec as driver on Linux?
is portio or cross_ec installed separately or does it get automatically installed when installing framework _tool?
No problem at all.
It uses the cros_ec driver by default, but this requires Linux 6.10. This requirement only holds for the AMD version of the Framework laptops, the Intel ones already have cros_ec present. I believe there may be issues if the kernel is locked down when using portio, but I have Secure Boot disabled at the moment so I cannot test.
I guess a generic test could be for to check the existence of /dev/cros_ec
and fall back to the portio driver otherwise?
Ok. So my plan was to do this.
if
kernel is >= 6.10
use pkexec framework_tool --charge-limit 80
else
use pkexec framework_tool --driver portio --charge-limit 80
But I think the below would be a better way as you suggested.
if
file /dev/cros_ec
exist
use pkexec framework_tool --driver cros_ec --charge-limit 80
else
use pkexec framework_tool --driver portio --charge-limit 80
I wont do a kernel check as it would apply across all kernel versions. What do you think about this?
Seems good! There are still cases when it won't work, but I guess this also holds for the other kmod approach.
Actually had the same Idea of using framework_tool. Went down the rabbit hole of learning how gnome extensions work for implementing that myself 😅 when i saw this thread i decided to clean my code a tiny bit and make this pull request: https://github.com/maniacx/Battery-Health-Charging/pull/101
@JanaCoulomb @paulvt I have push a new branch just for reference
https://github.com/maniacx/Battery-Health-Charging/tree/framework_tool
Little explaination.
If only Kmod or framework_tool is installed, it will use the it. If both Kmod or framework_tool and installed, it will provide the option in extensions preference > device allowing user to choose sysfs node or framework tool.
JanaCoulomb Will like your help , kindly submit some pathes.
For checking /dev/ec_tool
, I have done it only once, during extension initialization.
But I think it is better to do like you have done in your patch, as I have seen in you added checks, at every threshold update, instead of just once during extension initiliazation. This will help incase user decides to remove ec_tool at runtime, falling back to portio.
You can remove match
and use your logic it parseInt(this._stdout.split(" ")[3].slice(0,-1));
I will leave this upto you.
Also add your code readFile('/sys/devices/virtual/dmi/id/sys_vendor').includes("Framework"))
to check if laptop is frameworks. If you add this there is no need to for if (!fileExists(VENDOR_FRAMEWORK))
so we can remove that.
keep threshold function sysfs and framework_tool seperate (I have already done it here in this patch). Helps during debugging (framework_tool or sysfs) , I can concetrate on that function without worry about breaking the other and retestinng everything.
I think it is better to give user a prefs to choose sysfs and framework_tool, helps during debugging, and will help incase framework_tool doesn't work But I will leave final decision upto @JanaCoulomb and @paulvt.
Apologize, I will very busy, following weeks so expect delayed response from me.
JanaCoulomb. Thanks for learning and submitting those patches. Keep them coming. Let me know when it is finalized. I will merge all of it together.
I tried the extension by running install.sh
from that branch. However, I get the notification:
Battery Health Charging Error Missing dependencies
When I click on "Show details" in the notification, I do not get the details, but I see in the journal:
Aug 16 20:27:56 frame gnome-shell[92743]: JS WARNING: [file:///home/paul/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/lib/notifier.js 169]: Too many arguments to function Gio.app_info_launch_default_for_uri: expected 2, got 4
I am using GNOME Shell 46.4.
Need to replace
if (!fileExists(VENDOR_FRAMEWORK))
with
if(!readFile('/sys/devices/virtual/dmi/id/sys_vendor').includes("Framework")))
and add readFile
const {fileExists, readFileInt, readFile, runCommandCtl} = Helper;
Same error still, unfortunately. (I checked that it installed with the changes.)
Aug 16 20:27:56 frame gnome-shell[92743]: JS WARNING: [file:///home/paul/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/lib/notifier.js 169]: Too many arguments to function Gio.app_info_launch_default_for_uri: expected 2, got 4
Thanks for bringing this up. I will have to check later what changed with this.
Need to replace
if (!fileExists(VENDOR_FRAMEWORK))
with
if(!readFile('/sys/devices/virtual/dmi/id/sys_vendor').includes("Framework")))
I accidently added another close round bracket which would cause syntax error Make sure your text is exactly like this.
isAvailable() {
if(!readFile('/sys/devices/virtual/dmi/id/sys_vendor').includes("Framework"))
return false;
this._hasSysfsNode = fileExists(BAT1_END_PATH);
After installation need to restart you gnome-shell. That is logout and relogin (wayland) or ALT+F2 and r for xorg.
Verify you dmi by running cat command
cat /sys/devices/virtual/dmi/id/sys_vendor
Also line 125 in Framework.js Replace
output = await runCommandCtl(this._ctlPath, 'FRAMEWORK_TOOL_THRESHOLD_WRITE', this._frameworkToolDriver, this._endValue, null);
with
output = await runCommandCtl(this._ctlPath, 'FRAMEWORK_TOOL_THRESHOLD_WRITE', this._frameworkToolDriver, `${this._endValue}`, null);
Yes, now it loads without complaints. It asked me to install the extension with root permissions, did so. Logged in anew again and now the extension is loaded, but there is no system indicator, no item in the quick settings panel. It is as if it isn't loaded.
$ cat /sys/devices/virtual/dmi/id/sys_vendor
Framework
Current diff:
diff --git i/devices/Framework.js w/devices/Framework.js
index c6de76f..ec25e46 100644
--- i/devices/Framework.js
+++ w/devices/Framework.js
@@ -4,7 +4,7 @@ import GLib from 'gi://GLib';
import GObject from 'gi://GObject';
import * as Helper from '../lib/helper.js';
-const {fileExists, readFileInt, runCommandCtl} = Helper;
+const {fileExists, readFileInt, readFile, runCommandCtl} = Helper;
const VENDOR_FRAMEWORK = '/sys/devices/platform/framework_laptop';
const BAT1_END_PATH = '/sys/class/power_supply/BAT1/charge_control_end_threshold';
@@ -42,7 +42,7 @@ export const FrameworkSingleBatteryBAT1 = GObject.registerClass({
}
isAvailable() {
- if (!fileExists(VENDOR_FRAMEWORK))
+ if (!readFile('/sys/devices/virtual/dmi/id/sys_vendor').includes('Framework'))
return false;
this._hasSysfsNode = fileExists(BAT1_END_PATH);
@@ -122,7 +122,7 @@ export const FrameworkSingleBatteryBAT1 = GObject.registerClass({
if (this._verifyFrameworkToolThreshold(output))
return 0;
- output = await runCommandCtl(this._ctlPath, 'FRAMEWORK_TOOL_THRESHOLD_WRITE', this._frameworkToolDriver, this._endValue, null);
+ output = await runCommandCtl(this._ctlPath, 'FRAMEWORK_TOOL_THRESHOLD_WRITE', this._frameworkToolDriver, `${this._endValue}`, null);
if (this._verifyFrameworkToolThreshold(output))
return 0;
Oh, after a few minutes, even though there is no UI, the GNOME Shell threw an error that things are wrong. The journal reveals:
Aug 17 08:06:27 frame pkexec[119352]: pam_unix(polkit-1:session): session opened for user root(uid=0) by paul(uid=1000)
Aug 17 08:06:27 frame pkexec[119352]: paul: Executing command [USER=root] [TTY=unknown] [CWD=/home/paul] [COMMAND=/usr/local/bin/batteryhealthchargingctl-paul FRAMEWORK_TOOL_THRESHOLD_WRITE cros_ec 100]
For the framework_tool
, the Cros EC parameter is cros-ec
(dash, not underscore), so I updated it. Diff:
@@ -54,7 +54,7 @@ export const FrameworkSingleBatteryBAT1 = GObject.registerClass({
this._settings.set_boolean('detected-framework-tool', this._hasFrameworkTool);
if (this._hasFrameworkTool)
- this._frameworkToolDriver = fileExists(CROS_EC_PATH) ? 'cros_ec' : 'portio';
+ this._frameworkToolDriver = fileExists(CROS_EC_PATH) ? 'cros-ec' : 'portio';
return true;
}
But then, if I run the script manually:
$ pkexec /usr/local/bin/batteryhealthchargingctl-paul FRAMEWORK_TOOL_THRESHOLD_WRITE cros-ec 100
/usr/local/bin/batteryhealthchargingctl-paul: line 264: framework_tool: command not found
It cleans the $PATH
, or maybe running it from the terminal is different?
Does the framework_tool work in terminal?
framework_tool --driver portio --charge-limit 80 Minimum 0%, Maximum 80%
Try cross-ec too
framework_tool --driver cros-ec --charge-limit 80 Minimum 0%, Maximum 100%
Then try running batteryhealthchargingctl-paul with both portio as well as cross-ec ?
Does seem like something with path?
Batteryhealthchargingctl is using ,#!/usr/bin/env bash
but I don't think that should matter
It does, it does not contain /usr/local
. I put echo $PATH
at the start of batteryhealthchargingctl-paul
and it outputs:
/usr/sbin:/usr/bin:/sbin:/bin:/root/bin
It seems to even skip /etc/profile
which sets the path correctly....
If I call the script with sudo
, it shows the correct paths, so I'm guessing that pkexec
does something different.
(I see by the way that the Dell SMBIOS tool also has it's path hardcoded to /usr/sbin/smbios-battery-ctl
which also could be in another location.)
Just tested the framework_tool branch. Turns out "/sys/devices/platform/framework_laptop" doesn't exist on all distros on frameworks. The result: The isAvailable returns false and the extension creates an error telling me that there are missing dependencies.
For me I found the workaround to just check if the vendor is "Framework" using
readFile('/sys/devices/virtual/dmi/id/sys_vendor').includes("Framework")
in the Framework.js file
Just tested the framework_tool branch. Turns out "/sys/devices/platform/framework_laptop" doesn't exist on all distros For me I found the workaround to just check if the vendor is "Framework" using
readFile('/sys/devices/virtual/dmi/id/sys_vendor').includes("Framework")
in the Framework.js file
But this is already suggested above as a change, see the diff in this comment (amongst other changes).
The remaining problem is that pkexec
invokes the command in such a way that the $PATH
is very basic, i.e. not with /etc/profile
and such files loaded.
(I see by the way that the Dell SMBIOS tool also has it's path hardcoded to /usr/sbin/smbios-battery-ctl which also could be in another location.)
Yes. My initial method for dell was using hardcoded path. But that didnt work for system like NixOS. So I had to switch to program in Path and use hardcoded path as fallback.
if > GLib.find_program_in_path('smbios-battery-ctl')
then smbios-battery-ctl'" --set-charging-mode='adaptive'
else if > fileExist(/usr/sbin/smbios-battery-ctl')
then /usr/sbin/smbios-battery-ctl'" --set-charging-mode='adaptive'
But by default, when framework tool is packaged as aur for Arch Linux it is in /usr/bin/ https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=framework-system-git
If I call the script with sudo, it shows the correct paths, so I'm guessing that pkexec does something different.
I am curious about this though?
May be add this to batteryhealthchargingctl?
source /etc/profile
and also
source ~/.bashrc
source ~/.bashrc
May not work as user might be root, so path to bashrc may be a problem. need more testing.
source ~/.bashrc
May not work as user might be root, so path to bashrc may be a problem. need more testing.
My root user has /root/.profile
which reads /root/.bashrc
. But sourcing /etc/profile
already fixes the issue for me.
Ok. I already managed to push my commit to main branch GNOME45 ( no laptop, using phone browser). May be one of you can push all the fixes for framework tools as discussed above.
Ok. I already managed to push my commit to main branch GNOME45 ( no laptop, using phone browser). May be one of you can push all the fixes for framework tools as discussed above.
I just created PR #103 based on the GNOME45
branch that includes the suggested changes.
I have tested it using install.sh
and it works. The only issue is the one that I mentioned earlier, I see no UI changes whatsoever, so no the extension is constantly putting the charge limit to 100% and I want it set to 80%.
Oh. I assumed everything was working... My misunderstanding..
If GUI it is not changing seems like it is reading but not writing. check logs
journalctl -f -o cat /usr/bin/gnome-shell
Check if you can read or write directly using batteryhealthchargingctl command.
pkexec /usr/local/bin/batteryhealthchargingctl-paul FRAMEWORK_TOOL_THRESHOLD_WRITE cros-ec 100
There must be something that I have missed. EDIT: Are you seeing any nofifcations when you try to change threshold using quick settings?
Yes, I see the plugin executing commands in the journal:
Aug 18 12:12:06 frame pkexec[209706]: pam_unix(polkit-1:session): session opened for user root(uid=0) by paul(uid=1000)
Aug 18 12:12:06 frame pkexec[209706]: paul: Executing command [USER=root] [TTY=unknown] [CWD=/home/paul] [COMMAND=/usr/local/bin/batteryhealthchargingctl-paul FRAMEWORK_TOOL_THRESHOLD_WRITE cros-ec 100]
Aug 18 12:14:22 frame pkexec[210465]: pam_unix(polkit-1:session): session opened for user root(uid=0) by paul(uid=1000)
Aug 18 12:14:22 frame pkexec[210465]: paul: Executing command [USER=root] [TTY=unknown] [CWD=/home/paul] [COMMAND=/usr/local/bin/batteryhealthchargingctl-paul CHECKINSTALLATION /home/paul/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/resources paul]
I can execute this commands successfully also in the terminal. (I have to because I have to set it back to 80.)
There is nothing in the quick settings panel, nor notifications, nor a preference button, nor a system indicator. I had a system indicator before when the command was still failing, but that's gone now that everything is OK.
Hey @paulvt Can you test the updated version on GNOME45 branch?
I removed the extension, updated the branch, ran ./install.sh
, logged out. Used the Extensions tool to enable the extension, logged in again. I see it run the CHECKINSTALLTION
and FRAMEWORK_TOOL_THRESHOLD_READ
commands successfully via the helper, but no UI.
Let's revise that, it runs CHECKINSTALLATION
successfully, but the FRAMWORK_TOOL_THRESHOLD_READ
produces errors:
$ pkexec /usr/local/bin/batteryhealthchargingctl-paul FRAMEWORK_TOOL_THRESHOLD_READ /usr/local/bin/framework_tool cros-ec
error: '/usr/local/bin/framework_tool' isn't a valid value for '--driver <DRIVER>'
[possible values: portio, cros-ec, windows]
For more information try '--help'
with bash -x
:
+ case "$TOOLCMD" in
+ framework_tool --driver /usr/local/bin/framework_tool --charge-limit
error: '/usr/local/bin/framework_tool' isn't a valid value for '--driver <DRIVER>'
[possible values: portio, cros-ec, windows]
For more information try '--help'
+ exit 0
That does not seem right! :grin:
It is passing the tool as ARG1
, this should be the driver...
It seems that devices/Framework.js
tries to find out there the tool is and pass that, while the script does things with the path to find out where it is (again).
Disregard the above two comments. Even though I removed the extension, that didn't remove the /usr/local/bin/batteryhealthchargingctl-paul
helper which apparently still contained the old code. Sorry for the confusion.
The UI seems working now (it takes a while!) :tada:
Yes honestly. There was only one mistake in first commit that I pushed. I accidently deleted the case terminator ;;
before FRAMWORK_TOOL_THRESHOLD_READ . That cause all the problem.
I still have to do some changes/improvement, with batteryhealthchargingctl as currently, it is unsafe if we think security wise.
The UI seems working now (it takes a while!)
How long does it take? Do you think delay is from the framework_tool or the extension?
It is the extension, it takes about 4-6 minutes. When I open and the resume the laptop at 7:46, at 7:50 it does CHECKINSTALLATION
and then at 7:52 it does the READ
and show the UI (and the notification that I have set it it the setting I've set it at previously already). Otherwise it works fine.
Also when I select a setting from the quick panel, it is not written (or I am to inpatient). If I run the WRITE
command with the helper, it picks it up and updates the UI (and shows the notification).
So this seems a separate issue and not related to framework_tool
as the helper commands run immediately.
You are not impatient lol. Max expected delay would be 1 sec not 4 minutes.
I just pushed a branch with logs added. https://github.com/maniacx/Battery-Health-Charging/tree/debug-framework
Let see what is going on. Lets reset and uninstall everything.
uninstall this extension. Download the branch
Reset all gsettings related to this extension
gsettings --schemadir /home/$USER/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/schemas reset-recursively org.gnome.shell.extensions.Battery-Health-Charging
In tool folder there is and installer.sh script. Run using root privileges to remove polkit rules
./installer.sh --tool-user paul uninstall
Install the debug-framework branch
Restart gnome-shell
open new terminal/console Run below command that print more details including time stamps. I have piped it with awk to remove unneed stuff, you may have to play around with this command a bit
journalctl -f -o short-precise /usr/bin/gnome-shell --priority=debug | awk '{$4=""; $5=""; print $0}'
Leave this terminal window open.
Disable the extension and enable it. And see if you find something and/or post it here. You should see something like
Aug 20 09:43:07.672903 Battery Health Charging: StdErr: Error accessing /usr/local/bin/batteryhealthchargingctl-maniacx: No such file or directory
Ok. I've done that and enabled the extension (this time using the right branch :sweat_smile:). I get the notification that I should install the polkit stuff via the settings and see the indicator icon with a red marker in the top right corner.
The logs say:
Aug 20 21:34:27.776492 Battery Health Charging: ---- Extension Enabled ----
Aug 20 21:34:27.785611 Battery Health Charging: ---- _getCurrentDevice ----
Aug 20 21:34:27.786098 Battery Health Charging: ---- pre find_program_in_path ----
Aug 20 21:34:27.786146 Battery Health Charging: ---- post find_program_in_path ----
Aug 20 21:34:27.786226 Battery Health Charging: ---- Pre _checkInstallation ----
and that's unfortunately it! (I waited until 21:45.)
With the GNOME45
branch I do see that "error accessing" error, but not with this branch.
Lets use only the debug-framework branch currently for debugging. GNOME45 branch wont sshow any logs unless there is a syntax error in js files, or the batterychargingctl report an error.
After installing extension from debug-framework branch, did you install polkit rules using extension settings?
If you install it using extension settings, it will run check_compability function again, and proceed with checkInstallation. If you install the polkit rules using installer.sh , you will have to enable and disable the extension once.
I installed the pollkit rules (and helper) from the settings, because nothing happened I disabled and enabled the setting, logs:
Aug 21 07:45:24.650701 Battery Health Charging: ---- _getCurrentDevice ----
Aug 21 07:45:24.651191 Battery Health Charging: ---- pre find_program_in_path ----
Aug 21 07:45:24.651254 Battery Health Charging: ---- post find_program_in_path ----
Aug 21 07:45:24.651346 Battery Health Charging: ---- Pre _checkInstallation ----
Aug 21 07:45:24.651537 Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-paul,CHECKINSTALLATION,/home/paul/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/resources,paul ----
Aug 21 07:46:04.474160 Battery Health Charging: ---- Extension Disable ----
Aug 21 07:46:07.457506 Battery Health Charging: ---- Extension Enabled ----
Aug 21 07:46:07.465453 Battery Health Charging: ---- _getCurrentDevice ----
Aug 21 07:46:07.465887 Battery Health Charging: ---- pre find_program_in_path ----
Aug 21 07:46:07.465975 Battery Health Charging: ---- post find_program_in_path ----
Aug 21 07:46:07.466045 Battery Health Charging: ---- Pre _checkInstallation ----
Aug 21 07:46:07.466150 Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-paul,CHECKINSTALLATION,/home/paul/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/resources,paul ----
Then it took some time and then:
Aug 21 07:52:12.602851 Battery Health Charging: ---- status = 0 ----
Aug 21 07:52:12.602900 Battery Health Charging: ---- stdout = Minimum 0%, Maximum 100%
----
Aug 21 07:52:12.602930 Battery Health Charging: ---- stderr = ----
Aug 21 07:52:12.603313 Battery Health Charging: ---- Start threshold panel ----
Ok. Now we are getting somewhere.
Seem like CHECKINSTALLATION is taking long time for some reason.
pkexec /usr/local/bin/batteryhealthchargingctl-paul CHECKINSTALLATION /home/paul/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/resources paul && echo $?
Next lets check the exit status as well by combining echo $?
Run the command.
pkexec /usr/local/bin/batteryhealthchargingctl-paul CHECKINSTALLATION /home/paul/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/resources paul && echo $?
Also note the time here. For me I get the recieve results instantly. Expected results.
Battery Health Charging: checking rules !
Battery Health Charging: checking ctl !
Battery Health Charging: installation is up to date
0
What is your kernel, debian version, and polkit version.
echo "-- Kernel --"
uname -r
echo "-- Distro --"
lsb_release -a
echo "-- polkit --"
pkexec --version
So, yes, the command, when run manually, returns instantly and does not ask for a password.
I had already established this because for #102 I have been running commands with pkexec
a lot.
Battery Health Charging: checking rules !
Battery Health Charging: checking ctl !
Battery Health Charging: installation is up to date
0
The system information:
-- Kernel --
6.10.3-amd64
-- Distro --
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux trixie/sid
Release: n/a
Codename: trixie
-- polkit --
pkexec version 125
Note that the delay is exactly 120s, so curious :thinking:
Oh didn't realize polkitt 125 was released. I wonder if they have changed something.
I will install fedora rawhide today and test. This will give me an opportunity to also test the gnome 47 as well. Hopefully fedora rawhide use polkitt 125.
Off-topic. I use Linux on Chromebooks. We flash Coreboot to run Linux. I use the "ectool for the Framework laptop" on Arch Linux. Seems the same, in my case "sudo ectool chargecontrol normal 75 80". Can we cover this or open a new issue?
@lmigfernandes Yes. Please open a new issue Add some information.
Exact command to read and write charging threshold and the output those command.
Also explanation of normal
in the command
Output of
cat /sys/devices/virtual/dmi/id/sys_vendor
Location/path/directory of where ectool is installed.
@paulvt
I did run Fedora rawhide. The extension runs well. No delays. It is using Gnome47 and polkit 125
I use a batch script to mimic the output of framework tool. There is no delay
Battery Health Charging: ---- Extension Enabled ----
Battery Health Charging: ---- _getCurrentDevice ----
Battery Health Charging: ---- pre find_program_in_path ----
Battery Health Charging: ---- post find_program_in_path ----
Battery Health Charging: ---- Pre _checkInstallation ----
Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,CHECKINSTALLATION,/home/maniacx/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/resources,maniacx ----
Battery Health Charging: ---- status = 0 ----
Battery Health Charging: ---- stdout = Battery Health Charging: checking rules !
Battery Health Charging: checking ctl !
Battery Health Charging: installation is up to date
----
Battery Health Charging: ---- stderr = ----
Battery Health Charging: ---- Post _checkInstallation ----
Battery Health Charging: ---- setThresholdLimit ----
Battery Health Charging: ---- _setThresholdFrameworkTool ----
Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,FRAMEWORK_TOOL_THRESHOLD_READ,/usr/bin/framework_tool,portio ----
Battery Health Charging: ---- status = 0 ----
Battery Health Charging: ---- stdout = Minimum 0%, Maximum 100%
----
Battery Health Charging: ---- stderr = ----
Battery Health Charging: ---- Start threshold panel ----
Battery Health Charging: ---- setThresholdLimit ----
Battery Health Charging: ---- _setThresholdFrameworkTool ----
Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,FRAMEWORK_TOOL_THRESHOLD_READ,/usr/bin/framework_tool,portio ----
Battery Health Charging: ---- status = 0 ----
Battery Health Charging: ---- stdout = Minimum 0%, Maximum 100%
----
Battery Health Charging: ---- stderr = ----
Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,FRAMEWORK_TOOL_THRESHOLD_WRITE,/usr/bin/framework_tool,portio,80 ----
Battery Health Charging: ---- status = 0 ----
Battery Health Charging: ---- stdout = Minimum 0%, Maximum 80%
----
Battery Health Charging: ---- stderr = ----
Makes me wonder what is the issue.
Let try yo run this in gjs-console and see what happens. test.zip
I have add a test.zip. exttract and run gjs-console test.js
See if you get any output or if there is any delay.
I still am on GNOME Shell 46.4.
The test program runs fine and instantaneous:
Gjs-Message: 21:56:24.702: JS LOG: arg = pkexec,/usr/local/bin/batteryhealthchargingctl-paul,CHECKINSTALLATION,/home/paul/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/resources,paul
Gjs-Message: 21:56:24.704: JS LOG: proc.init successful
Gjs-Message: 21:56:24.730: JS LOG: pre communicate_utf8_finish
Gjs-Message: 21:56:24.730: JS LOG: post communicate_utf8_finish
Gjs-Message: 21:56:24.730: JS LOG: post get_exit_status
Gjs-Message: 21:56:24.730: JS LOG: Promise stdout = Battery Health Charging: checking rules !
Battery Health Charging: checking ctl !
Battery Health Charging: installation is up to date
Gjs-Message: 21:56:24.730: JS LOG: Promise stderr =
Gjs-Message: 21:56:24.730: JS LOG: Promise status = 0
Gjs-Message: 21:56:24.730: JS LOG: return output
Gjs-Message: 21:56:24.730: JS LOG: status = 0
Gjs-Message: 21:56:24.730: JS LOG: stdout = Battery Health Charging: checking rules !
Battery Health Charging: checking ctl !
Battery Health Charging: installation is up to date
Gjs-Message: 21:56:24.730: JS LOG: Main function completed
So, I fired up debian in Gnome-Boxes. use my dummy framework_tool. Installed extension by modifying DMI vendor from Framework to QEMU. Enabled the extension and I worked without any delay.
23 15:27:51.830898 debian gnome-shell[3691]: Battery Health Charging: ---- Extension Enabled ----
Aug 23 15:27:51.833059 debian gnome-shell[3691]: Battery Health Charging: ---- _getCurrentDevice ----
Aug 23 15:27:51.833603 debian gnome-shell[3691]: Battery Health Charging: ---- pre find_program_in_path ----
Aug 23 15:27:51.833682 debian gnome-shell[3691]: Battery Health Charging: ---- post find_program_in_path ----
Aug 23 15:27:51.833912 debian gnome-shell[3691]: Battery Health Charging: ---- Pre _checkInstallation ----
Aug 23 15:27:51.834074 debian gnome-shell[3691]: Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,CHECKINSTALLATION,/home/maniacx/.local/share/gnome-shell/extensions/Battery-Health-Charging@maniacx.github.com/resources,maniacx ----
Aug 23 15:27:51.874431 debian gnome-shell[3691]: Battery Health Charging: ---- status = 0 ----
Aug 23 15:27:51.874514 debian gnome-shell[3691]: Battery Health Charging: ---- stdout = Battery Health Charging: checking rules !
Battery Health Charging: checking ctl !
Battery Health Charging: installation is up to date
----
Aug 23 15:27:51.874573 debian gnome-shell[3691]: Battery Health Charging: ---- stderr = ----
Aug 23 15:27:51.874894 debian gnome-shell[3691]: Battery Health Charging: ---- Post _checkInstallation ----
Aug 23 15:27:51.875042 debian gnome-shell[3691]: Battery Health Charging: ---- setThresholdLimit ----
Aug 23 15:27:51.875177 debian gnome-shell[3691]: Battery Health Charging: ---- _setThresholdFrameworkTool ----
Aug 23 15:27:51.875496 debian gnome-shell[3691]: Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,FRAMEWORK_TOOL_THRESHOLD_READ,/usr/bin/framework_tool,portio ----
Aug 23 15:27:51.909776 debian gnome-shell[3691]: Battery Health Charging: ---- status = 0 ----
Aug 23 15:27:51.909904 debian gnome-shell[3691]: Battery Health Charging: ---- stdout = Minimum 0%, Maximum 80%
----
Aug 23 15:27:51.910002 debian gnome-shell[3691]: Battery Health Charging: ---- stderr = ----
Aug 23 15:27:51.910892 debian gnome-shell[3691]: Battery Health Charging: ---- Start threshold panel ----
Aug 23 15:27:55.947495 debian gnome-shell[3691]: Battery Health Charging: ---- setThresholdLimit ----
Aug 23 15:27:55.947648 debian gnome-shell[3691]: Battery Health Charging: ---- _setThresholdFrameworkTool ----
Aug 23 15:27:55.947828 debian gnome-shell[3691]: Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,FRAMEWORK_TOOL_THRESHOLD_READ,/usr/bin/framework_tool,portio ----
Aug 23 15:27:55.976733 debian gnome-shell[3691]: Battery Health Charging: ---- status = 0 ----
Aug 23 15:27:55.976816 debian gnome-shell[3691]: Battery Health Charging: ---- stdout = Minimum 0%, Maximum 80%
----
Aug 23 15:27:55.976882 debian gnome-shell[3691]: Battery Health Charging: ---- stderr = ----
Aug 23 15:27:55.977455 debian gnome-shell[3691]: Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,FRAMEWORK_TOOL_THRESHOLD_WRITE,/usr/bin/framework_tool,portio,60 ----
Aug 23 15:27:56.003116 debian gnome-shell[3691]: Battery Health Charging: ---- status = 0 ----
Aug 23 15:27:56.003239 debian gnome-shell[3691]: Battery Health Charging: ---- stdout = Minimum 0%, Maximum 60%
----
Aug 23 15:27:56.003372 debian gnome-shell[3691]: Battery Health Charging: ---- stderr = ----
Aug 23 15:27:57.407149 debian gnome-shell[3691]: Battery Health Charging: ---- setThresholdLimit ----
Aug 23 15:27:57.407255 debian gnome-shell[3691]: Battery Health Charging: ---- _setThresholdFrameworkTool ----
Aug 23 15:27:57.407521 debian gnome-shell[3691]: Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,FRAMEWORK_TOOL_THRESHOLD_READ,/usr/bin/framework_tool,portio ----
Aug 23 15:27:57.438319 debian gnome-shell[3691]: Battery Health Charging: ---- status = 0 ----
Aug 23 15:27:57.438403 debian gnome-shell[3691]: Battery Health Charging: ---- stdout = Minimum 0%, Maximum 60%
----
Aug 23 15:27:57.438452 debian gnome-shell[3691]: Battery Health Charging: ---- stderr = ----
Aug 23 15:27:57.438657 debian gnome-shell[3691]: Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,FRAMEWORK_TOOL_THRESHOLD_WRITE,/usr/bin/framework_tool,portio,100 ----
Aug 23 15:27:57.464352 debian gnome-shell[3691]: Battery Health Charging: ---- status = 0 ----
Aug 23 15:27:57.464423 debian gnome-shell[3691]: Battery Health Charging: ---- stdout = Minimum 0%, Maximum 100%
----
Aug 23 15:27:57.464475 debian gnome-shell[3691]: Battery Health Charging: ---- stderr = ----
Aug 23 15:27:58.860774 debian gnome-shell[3691]: Battery Health Charging: ---- setThresholdLimit ----
Aug 23 15:27:58.860878 debian gnome-shell[3691]: Battery Health Charging: ---- _setThresholdFrameworkTool ----
Aug 23 15:27:58.861065 debian gnome-shell[3691]: Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,FRAMEWORK_TOOL_THRESHOLD_READ,/usr/bin/framework_tool,portio ----
Aug 23 15:27:58.892992 debian gnome-shell[3691]: Battery Health Charging: ---- status = 0 ----
Aug 23 15:27:58.893055 debian gnome-shell[3691]: Battery Health Charging: ---- stdout = Minimum 0%, Maximum 100%
----
Aug 23 15:27:58.893098 debian gnome-shell[3691]: Battery Health Charging: ---- stderr = ----
Aug 23 15:27:58.893289 debian gnome-shell[3691]: Battery Health Charging: ---- argv = pkexec,/usr/local/bin/batteryhealthchargingctl-maniacx,FRAMEWORK_TOOL_THRESHOLD_WRITE,/usr/bin/framework_tool,portio,80 ----
Aug 23 15:27:58.919031 debian gnome-shell[3691]: Battery Health Charging: ---- status = 0 ----
Aug 23 15:27:58.919093 debian gnome-shell[3691]: Battery Health Charging: ---- stdout = Minimum 0%, Maximum 80%
----
Aug 23 15:27:58.919158 debian gnome-shell[3691]: Battery Health Charging: ---- stderr = ----
You may have to check, if you have done any modifications, that could be creating a delay. any thing related to dbus, polkit auth, nested gnome-shell etc. Is you Debian install customized?
Here are some details of Debian I am running, You can compare with your setup. I cannot think of anything else, that could go wrong.
maniacx@debian:~$ uname -r
6.10.4-amd64
maniacx@debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux trixie/sid
Release: n/a
Codename: trixie
maniacx@debian:~$ pkexec --version
pkexec version 125
maniacx@debian:~$ gnome-shell --version
GNOME Shell 46.4
maniacx@debian:~$ dbus-daemon --version
D-Bus Message Bus Daemon 1.14.10
Copyright (C) 2002, 2003 Red Hat, Inc., CodeFactory AB, and others
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
root@debian:/home/maniacx# dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep "PolicyKit"
string "org.freedesktop.PolicyKit1"
root@debian:/home/maniacx# cat /proc/$(pgrep -f /usr/bin/gnome-shell)/environ | tr '\0' '\n'
HOME=/home/maniacx
LANG=C.UTF-8
LOGNAME=maniacx
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
SHELL=/bin/bash
USER=maniacx
XDG_RUNTIME_DIR=/run/user/1000
GTK_MODULES=gail:atk-bridge
QT_ACCESSIBILITY=1
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DESKTOP_SESSION=gnome-xorg
DISPLAY=:0
GDMSESSION=gnome-xorg
GDM_LANG=C.UTF-8
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
PWD=/home/maniacx
QT_IM_MODULE=ibus
SESSION_MANAGER=local/debian:@/tmp/.ICE-unix/1539,unix/debian:/tmp/.ICE-unix/1539
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
USERNAME=maniacx
WINDOWPATH=2
XAUTHORITY=/run/user/1000/gdm/Xauthority
XDG_CURRENT_DESKTOP=GNOME
XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/
XDG_MENU_PREFIX=gnome-
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=gnome-xorg
XDG_SESSION_TYPE=x11
XMODIFIERS=@im=ibus
MANAGERPID=1310
INVOCATION_ID=e4de5c9246be4bd6a68f42b4e39959f0
JOURNAL_STREAM=9:3980
SYSTEMD_EXEC_PID=1583
MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@x11.service/memory.pressure
MEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA=
GJS_DEBUG_OUTPUT=stderr
GJS_DEBUG_TOPICS=JS ERROR;JS LOG
Framework has a repository for the official tool for configuring the embedded controller: https://github.com/FrameworkComputer/framework-system. Would you consider using the official
framework_tool
as an alternative for the currently supported unofficial kernel module? Kernel modules are also always kind of an hassle, especially with signed kernels.Viewing/changing the threshold is done like this:
Maybe it is possible support two back-ends, depending on the presence of
framework_tool
in the path or the presence of/sys/class/power_supply/BAT1/charge_control_end_threshold
(i.e. the kernel module is loaded)?