Got it
And again thank you for your work
аў, 24 лют 2026, 20:31 карыстальнік Kemal_Ozturk <notifications@framework3.discoursemail.com> напісаў:
1 Like
I’d love to see a feature on here that uses ectool to modify the input charge limit, allowing me to use the full PSU (with an appropriate safety warning next to the setting).
interesting thing is that windows version of this shows right resolution and almost correct RAM amount 63GB, while linux version shows 62GB and much higher resolution.
So i guess linux one needs some fixing so it shows correct info like windows version.
I don’t think the resolution one does anything special other than just asking the browser what it should be. Maybe minor browser differences between the OS’es
What do you mean? Increasing the charge speed or something? The framework-tool might not allow that.
Do you have an example command you’re running to achieve what you’re asking?
One random thing I did want to add is ryzenadj gets flagged in some games with anti cheat and terminate the program. I had to disable it so I didn’t get banned 
When the computer is powered off, the EC returned back to the UEFI setting because the EC can’t read the battery limit from RAM or SSD since they are both off, so I think it’s impossible for Framework Control or other userspace EC configurator to do that.
The charging speed of the battery is controlled by the BMS, not the EC. The “input charge limit” that allows them to “use the full PSU” is the chg_input_current value. Change this value according to the current after the 48V to 20V buck converter to fine tune the PD wattage as close to 240W as possible to maximize the utilization of the 240W power adapter
Not ryzenadj’s problem. It’s the game’s anti-cheat being too invasive, boycott the game to reclaim user’s rights
1 Like
Charlie did a decent job explaining it. A sample command (the one I use for 240W) is
sudo ectool chargestate param 2 12000
It can be calculated as such.
12000 is calculated as 240W / 20V = 12000mA
9000 is calculated as 180W / 20V = 9000mA
I plan on eventually writing a script that reads what PSU is connected, then automatically applies the correct ectool override.
I just wrote a simple script that looks at what charger is connected and then applies a 100% usage ectool override. By “I wrote” I mean I asked chatgpt to do it, and then tested it.
#!/bin/bash
#Get the current charge state output
output=$(sudo ectool chargestate param 2)
#Extract the first number (before the space)
current_value=$(echo “$output” | awk ‘{print $1}’)
#Check the value and run corresponding command
if [ “$current_value” -eq 10256 ]; then
# 240W PSU detected
sudo ectool chargestate param 2 12000
elif [ “$current_value” -eq 7680 ]; then
# Lower watt PSU detected
sudo ectool chargestate param 2 9000
else
# Do nothing for other values
exit 0
fi
I now have this script configured to auto-run when the laptop is plugged in. I guess I don’t need it added to framework control anymore, lol.
Note: In order to get this to run automatically, I had to do some tweaking to my suders file and the script above in order for the sudo commands to work.
1 Like
Just got this up and running in
I assume the benefit here is that when using the 240w it shouldnt discharge?
So, am I understanding this correctly? To be able to use 240W charger, you have to tell the EC to behave?
If that is the case, this seems like a firmware or EC problem. I feel like we shouldn’t have to tell the EC that
Regardless, good solution you got there nudging it with the script!
The buck converter that converts 36~48V to 20V doesn’t have 100% efficiency. Setting the calculated value may overload the power adapter. It’s better to use a USB-C meter, increase the chg input until the meter reads 5A.
It’s also possible that the output voltage is 17.8V instead of 20V, in this case the chg current can be higher, but buck converter energy loss must be considered. In conclusion the current limit maybe higher or lower than 12000 when using 240W input, further testing is needed to figure out the exact value.
@Kemal_Ozturk sort of. It’s not a “problem” in that it’s unintentional. Framework intentionally limits PSU connections to 90% of the rated limit for safety concerns related to measurement error. The script I run essentially overrides those safety limits, which I am comfortable doing because I’ve used external tools to monitor the actual power draw and behavior, and found that I’m well within safe limits. Framework cautions against recommending these changes en-masse as just because it works fine on my machine, doesn’t mean it will work fine on someone else’s. See here: [TRACKING] Battery flipping between charging and discharging / Draws from battery even on AC - #608 by Kieran_Levin
@Charlie_6 According to @James3, it is indeed 20V not 17.8V, and this matches my external power reading measurements perfectly, whereas assuming it’s 17.8V introduces a significant amount of error from the reading. As for my use case, it doesn’t seem like my laptop is readily capable of pulling much more than 215W sustained, as that’s the peak average I’ve been able to get it to draw. Therefore, I imagine there’s no practical difference between me ectooling a value of 11k instead of 12k. Perhaps I should do that in order to retain at least some of the intended safety margin, but as of yet, that is not what I have done.
Side note: I goy my fiance an Asus Tuf with practically the same specs as my FW 16 (it has a 7835HS instead of 7840HS) and it came with a 280W PSU. I found that interesting.
2 Likes
Hello there, I love this project! I’ve been using it to make the curves more gentle in the day to day and significantly more aggresive before it hits 100C on my 13 when doing the more high demand workloads. No more stop/start fan problems. chefs kiss. Still too scared to use ryzenadj though. Reading through this thread i see various people offering to support you, and I wouldn’t be opposed to send you a coffee either if you let us, you’ve genuinely made something of value, and it looks sleek and refined as well. 
Looking at your github, i see that you’re planning on adding LED controls already, but I’ll just ask it here as well; I would also really like backlight sliders. gnome fedora has those built in for the keyboard (and i believe there’s a fingerprint LED extension as well?) that allows % based control, but windows is lacking here. no fp LED control without command line usage of framework’s tool, and no keyboard backlight control beyond the 3 basic power states.
I have little programming experience, I wish i did, i do not have the perseverance to learn programming with the challenges it offers. if I did, i would totally want to try and add it myself. maybe after writing this I’ll make a short project out of making a python script (that’s the best i can do 
) and a local page with simple sliders or something. who knows! glad to see you’re still developing this tool though.
1 Like
I could be wrong, but I don’t think there’s a way for him to implement the keyboard change you’re asking for without modifying the keyboard’s firmware.
If that is a feature that @Kemal_Ozturk is interested though, I may be willing to help support the firmware changes needed to get that to work. I have already built a custom firmware for my RGB keyboard that allows me to see what my laptop’s utilizations and temperatures are at: RGB Keyboard Custom Firmware - PC Utilization Stats - Framework Laptop 16 - Framework Community
Without some pull/interest in that though from the community, I have no plans on doing that work. I’m relatively happy with where my keyboard is at right now for my own needs.
With some help, his framework control application could make the keyboard modifications relatively painless for an end-user.
1 Like
Kemal is using frameworks own EC tool (framework service, i believe) to figure out the values and to write values back to the EC. I say this, fully based on a(n educated) guess. Svelte ccalls GET power/health, would seem to match what FW tool has in terms of commands. i assume the curves are applied by checking and adjusting the fans based on temperatures based on what is stored in the config. if that is so, all he has to do is add the usage of the commands by the tool, the endpoints and svelte interface components to add the feature. And i have no clue how much effort that is to implement because I’m no software engineer, not even remotely.
1 Like
@echninacea Correct! I’m strictly only using the Framework provided “framework_tool” which is a part of the “framework-system” repo on GitHub. It’s their own CLI that allows communicating with the EC. I don’t directly input commands to the EC, that’s a more low level thing to do and could be dangerous if used improperly.
@TechPriestNhyk Thank you for the offer. I currently don’t plan on implementing my own handling for EC or keyboard communication. The good news is, there’s another CLI that the Framework team provides for interacting with the keyboard and the LED Matrix (I think). So I will likely explore that first to see if we can talk to the keyboard or the LEDs that way.
No, that’s not it. The EC default is to limit itself to 10% or 15% less than the adapter should be able to provide, so for a 240W adapter it would limit the draw to 204W (15% down). The reason I’ve seen given by FW staff is to give a margin of safety in case the laptop does not measure the current accurately. The few users who I’ve seen report testing the max power the laptop can draw, haven’t seen significant inaccuracy in the EC’s limit (using usb power meters and load tests), and forcing it up to 240W did draw that much power and did work better.
FWIW I don’t think it’s a huge risk to allow users to enable this, if the adapter’s capabilities are exceeded it’ll either shut-off or voltage-droop which the power input should handle (assuming not in stand-alone battery-less mode). But maybe users would misunderstand this function. Anyway, I’m pretty sure that’s only possible with ectool, not with framework_tool.
1 Like
Thank you for providing further details @pierce
I’m thinking I won’t be adding this to the app unless it’s something framework themselves adds to the tool or suggests doing. This app is more for folks who want a front-end for the framework_tool CLI. Heck, the main reason it existed was to control fans, but I’ve added more than I thought I’d do
@echninacea on learning programming. You can do it! With the help of AI, you can accelerate your learning. Just start from the basics and pick up an easy language like TS or Python. You won’t regret it.
Hey all!
I just released the 0.5.1 update, which gets Linux up to speed on power controls. I decided to not use RyzenAdj since it’s flaky on Linux. I added some power controls that are natively available in the Linux ecosystem like the epp and the cpufreq options. The update also comes with some bug fixes and improvements. More details can be found in the changelog here.
Now that we have Linux support and feature parity with Windows, I think I will take another break and just work on small improvements and bug fixes. This is a side project and I can only work on it in my free time, which is unfortunately limited 
@catastrophic
May I ask for another quick update to the title: Framework Control (Linux/Windows) - A tool for: Fan Control (Curve), Sensors, Power Control, Battery Information
And maybe we might want to move the topic to a different category. This app works on all of the Framework devices since it’s using the framework_tool CLI. It’d be nice if we could either add tags that communicate that or move it somewhere else so it’s not under the Laptop 16 section.
5 Likes