I’m willing to give it a shot although I don’t have that much experience with bash & linux, I’m guessing by binding and rebinding you mean this?
1 Like
Exactly! And don’t worry about experience, if you open a git repo somewhere i’m sure people (including me) will be happy to contribute where needed and possible.
update:
here’s what a quick search yielded for executing a script on screen lock/unlock (since we obviously can’t receive insertion signals with the drivers unbound) :
Both questions are a tad old but i think the answers are largely still helpful. I admittedly don’t know that much about Linux evil maid mitigations, but I think by binding the function of the expansion cards to the lock state of the screen, we might actually increase security a bit as well.
EDIT:
forgot to mention: since there seems to be no abstract, linux-universal interface for this, one would probably have to write a bit more code to make the daemon linux-universally applicable.
1 Like
[quote=“D.H, post:79, topic:6665”]
I would prefer to see more longevity playing video though. VLC playing 1080p h.264 from a samba share, YouTube 720p, playing a local 1080p copy of Sintel, etc all bring the estimated battery life under 4 hours. That’s a little odd to me after having run 5Y70 and 6Y30 class processors that get 5-7 hours of local or streamed video playback time from even smaller batteries…
[/quote]‘’
Catching up on this thread, hence this super late reply – just a note, I noticed when testing during this that mpv used considerably less power than VLC (~-2W iirc). Both using hardware decoding / VA-API (which uses significantly less power). That was a while ago, so VLC might’ve gotten more efficient, but
From those findings, 5-7 hours is definitely achievable for 720/1080P video playback. In fact, it should be closer to 8 hours provided no other process is consuming much power.
I…spent a while trying to see if the specific USB ports could be disabled or power cut in Linux a while back so I could keep the HDMI Expansion card plugged in. Unfortunately I couldn’t get it to work 
If anyone has any specific things for me to try, please lmk, though I’ve tried a fair number of options already.
I read this today though, pretty insightful (if correct):
Has anyone noticed a significant increase in power consumption with kernel 5.15.12.arch1-1? I got an increase of 1-2W in idle. I’m using kde with arch.
I wanted to edit the wiki. But I couldn’t due to “403 …” message. I wanted to add the following comments. Here is my working log on commands level.
Tuning idle power usage
Here are the upstream project URLs.
- powertop: https://github.com/fenrus75/powertop
- tlp: TLP - Optimize Linux Laptop Battery Life — TLP 1.5 documentation
Panel self-refresh
Note: On kernel >= 5.14 (such as Fedora 35), the PSR disablement is no longer necessary.
Happened to me as well some days ago. I guess updating a post with links is prohibited or broken. Without adding links, everything works.
EDIT:
test https://www.reddit.com/
OK. But I tried to add a comment without any link now, and I still see the “403 …” message.
Well, that’s weird. I just updated my comment above successfully. I’ll now try updating it with a link
UPDATE:
Even that worked. Maybe try again?
Doesn’t appear to be affecting me. I’m on gnome wayland with PSR enabled. Using cpupower-gui (‘powersave’ governor, ‘power’ energy preference) and powertop.
Now I tried to edit, and it doesn’t work. I saw you edited your comment area with adding a link. But what I am seeing the 403 message is on the wiki area on the top of this thread. Could you try to edit the wiki area, not comment area?
Here is the actual message.
Interestingly, seeing the history of the edits on this wiki, the latest change is by “me”. But the change is actually not by me. Maybe a table data in the database related to wiki in Discourse is broken.
Edit: My guess for this issue is maybe the wiki table data is unintentionally locked by my user account “junaruga”, as a past update for this table might be failed in the process of the transaction.
1 Like
@junaruga i get the same error there, but just earned the badge ‘Wiki editor’, so i second your guess about the database.
1 Like
OK! Let’s wait Framework team to fix this issue.
By the way, I think in the process of tuning the battery life, measuring numbers in a reliable way and easily. So, I investigated the possible ways. Here is my article about it. I checked it on Fedora Linux 35. I see the PowerTop (powertop), UPower (upower) and PowerStat (powerstat) could be useful. I see the powertop is often mentioned on this forum.
I thought the “discharge rate” or “energy-rate” is the numbers to measure how good the battery life tuning is, and I find the following commands are convenient to get the numbers. But I am not sure why the following number is different between in the powertop and upower. Do you know why? Do you have a recommendation for the command and numbers to measure the battery life tuning?
powertop
$ sudo powertop --csv
$ grep 'discharge rate' powertop.csv
The battery reports a discharge rate of: 5.72 W;
upower
$ upower -i $(upower -e | grep BAT) | grep energy-rate
energy-rate: 7.4074 W
1 Like
I wouldn’t call it a significant increase, but I am noticing stronger “pulses of activity” when watching current_now. If you leave the system alone to get to C10 idle, it settles down into a sawtooth pattern of increased use every 8 to 10 seconds, that tapers off across 8 to 10 seconds, and repeat. The spikes in current usage are a little bit higher, but do settle down a bit deeper. Wonder if whatever tool you are using to display W used is catching more of the usage wave crests vs troughs.
Coincidentally, my best lowest record current_now value (137000, converts to maybe ~2.1W) has been on 5.15.12.
A quick update for Fedora/KDE users, As of Fedora 35, Udev is no longer needed to switch between power profiles. Switching profiles on battery/AC is now an option in KDE’s power management settings.
For those looking to make other changes when on battery/AC you can run scripts on profile change as well. I currently have scripts that change the power settings of Linux’s scaling governor. The scripts for AC and Battery run these two commands respectively:
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
echo power-saver | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
This changes the cpu frequencies based on power profiles that are built into the cpufreq governor. These changes mean that I can run at full horsepower while connected via AC and be more conservative about power usage when I’m relying on the battery. Typically when I am on battery I am sing a more basic workflow with a few applications and a web browser open, and I have not noticed any dip in overall performance when running the power-save profiles for both powerprofilesctl and my cpu governor.
Between these changes and others I have mentioned on this thread, I have been able to pretty consistently achieve around 10 hours of battery on a full charge.
4 Likes
How did you measure around 10 hours? Did you just run KDE without anything from battery 100% to 0%, right? Or did you do something during the 10 hours?
This is an estimate compiled from both powertop’s and the OS’s estimates on battery life and what I have personally observed using this as my daily driver for around 5 months now. If you have some other benchmark utility you want me to give a whirl I would be more than happy to run it and tell you what I get.
1 Like
Alright I was able to get it around 10 hours as well. Just today I finally jumped ship and got myself arch, with the setup I need, which is quite minimal and some HW acceleration and TLP under gnome I was able to get something like that. Didn’t test it throughly tho
Quick question, does hw-decoding for FFox & Chromium work for anybody? I have tried everything that I could find and still could not get it to work. I’m assuming that having hw acceleration on would greatly help battery life? Maybe extend it by an hour and a half? If not then I won’t bother with it then.
I could edit the wiki on this thread now. Maybe it was fixed at the following timing.