maniacx / Battery-Health-Charging

Gnome extension to Set battery charging threshold / charging limit / charging mode Battery Health Charging: An extension to maximize the battery life of laptops by setting their charging threshold or modes.
https://extensions.gnome.org/extension/5724/battery-health-charging/
GNU General Public License v3.0
218 stars 19 forks source link

Consider using framework_tool for Framework laptops? #100

Open paulvt opened 3 months ago

paulvt commented 3 months ago

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:

$ pkexec pkexec framework_tool --driver portio --charge-limit 80
Minimum 0%, Maximum 80%

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)?

maniacx commented 3 months ago

What is the default location of framework_tool when installed?

paulvt commented 3 months ago

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?

paulvt commented 3 months ago

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.

maniacx commented 3 months ago
  1. What happens if I add option --driver to kernel 6.10? Would it throw an error?

  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?

I initially did developed the extension with framework tool initially, but I deleted the branch and lost all code and information.

paulvt commented 3 months ago
  1. 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%
maniacx commented 3 months ago

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?

paulvt commented 3 months ago

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.

paulvt commented 3 months ago

I guess a generic test could be for to check the existence of /dev/cros_ec and fall back to the portio driver otherwise?

maniacx commented 3 months ago

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?

paulvt commented 3 months ago

Seems good! There are still cases when it won't work, but I guess this also holds for the other kmod approach.

JanaCoulomb commented 3 months ago

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

maniacx commented 3 months ago

@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.

  1. 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.

  2. You can remove match and use your logic it parseInt(this._stdout.split(" ")[3].slice(0,-1)); I will leave this upto you.

  3. 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.

  4. 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.

paulvt commented 3 months ago

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.

maniacx commented 3 months ago

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;

paulvt commented 3 months ago

Same error still, unfortunately. (I checked that it installed with the changes.)

maniacx commented 3 months ago

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
maniacx commented 3 months ago

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);
paulvt commented 3 months ago

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;
paulvt commented 3 months ago

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?

maniacx commented 3 months ago

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

paulvt commented 3 months ago

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.

paulvt commented 3 months ago

(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.)

JanaCoulomb commented 3 months ago

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

paulvt commented 3 months ago

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.

maniacx commented 3 months ago

(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
maniacx commented 3 months ago
source ~/.bashrc

May not work as user might be root, so path to bashrc may be a problem. need more testing.

paulvt commented 3 months ago
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.

maniacx commented 3 months ago

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.

paulvt commented 3 months ago

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%.

maniacx commented 3 months ago

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?

paulvt commented 3 months ago

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.

maniacx commented 3 months ago

Hey @paulvt Can you test the updated version on GNOME45 branch?

paulvt commented 3 months ago

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.

paulvt commented 3 months ago

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:

paulvt commented 3 months ago

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).

paulvt commented 3 months ago

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:

maniacx commented 3 months ago

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?

paulvt commented 3 months ago

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.

maniacx commented 3 months ago

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
paulvt commented 3 months ago

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.

maniacx commented 3 months ago

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.

paulvt commented 3 months ago

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 ----
maniacx commented 3 months ago

Ok. Now we are getting somewhere.

Seem like CHECKINSTALLATION is taking long time for some reason.



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
paulvt commented 3 months ago

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:

maniacx commented 3 months ago

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.

lmigfernandes commented 3 months ago

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?

maniacx commented 3 months ago

@lmigfernandes Yes. Please open a new issue Add some information.

  1. Exact command to read and write charging threshold and the output those command.

  2. Also explanation of normal in the command

  3. Output of

    cat /sys/devices/virtual/dmi/id/sys_vendor
  4. Location/path/directory of where ectool is installed.

maniacx commented 3 months ago

@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.

paulvt commented 3 months ago

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
maniacx commented 3 months ago

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