This is amazing! I randomly stumbled across it on Bazaar. As someone techie enough to run Fedora and run some basic terminal commands but not techie enough to do the other embedded controller tools, thank you for your work.
3 Likes
Hello,
Thanks for making this really cool program and sharing it with the community. I noticed a few small issues on my laptop which I though I could feedback here. I’m using a FW13 Intel 11th gen, BIOS v3.24, running Linux:
Thermals>Fan control>Speed Set Mode>Percent: Set percentage doesn’t work and results in a 100% fan speed when the Fan RPM Target value is 300 RPM and above. When the RPM target value is between 0-200 RPM it is working as expected.
LEDs>Advanced Options>Power LED: Blue option doesn’t emit any light.
Battery limiter>Override Charge Limit: It works to override the limit but I’m not seeing the limit reactivate. Maybe I’m not understanding or using this feature correctly, I’m not sure what the required conditions are for it to reactivate. Enable Charge Limiter switch and adjusting the Charge Limit percentage setting is working as expected.
Sensors>Ambient Light Sensor: Reports a zero value, have conformed the sensor is working via ‘’‘cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw’‘’
Sensors>Chassis Open Count: Always reports 1, I have opened it many more times 
Everything else seems to be working perfectly, I didn’t check on the advanced LEDs section much
Thank again I hope this is helpful.
Hi, no worries!
Does this happen with ectool or any other EC utilities? Because I feel like this is probably an EC issue.
Ahh okay, EC would be saying there’s a blue channel, but it doesn’t actually. This is pretty easy to patch around.
Edit: Fixed in this build - Disable blue power button colour · Steve-Tech/YAFI@90a994a · GitHub
My understanding is that button will charge to 100%, and reset to the previous limit after being unplugged.
Hmm, not sure why that is, probably also an EC issue. Linux reads the ALS off the chipset, maybe so it’s not actually connected to the EC even though it is on the schematic?
Again not too sure, it works for me haha!
1 Like
Yes the behavior is the same when the RPM target is set with the Framework EC tool, didn’t think to try that!
Mine too but that didn’t seem to work for me, does it work for you? I tried both charging till the UI reported 100% and charging to when the input current drops to zero after that I tried waiting till the charge was below the set charge limit. Not a big issue for me as I can use the enable limit switch or slider as a workaround.
As a layperson I don’t see a direct connection between the ALS and the MEC1521 on the 11th gen block diagram as there is with the 12th gen, I wish I could help but that is a bit beyond me
No ideas here 
Ahh cool, you might wanna open an issue either on the EC repo, or the general issue tracker.
Hmm actually, I don’t think it is working.
Oh woops, I must’ve had 12th gen on the mind haha! But that makes total sense.
I just remembered, this can reset if your battery has gone totally dead but I feel the CMOS battery should prevent that on the 11th gen. Also, just to double check, what does framework_tool --intrusion say?
1 Like
After seeing the intrusion command you asked me to try I realised I was actually using DHowett’s version of the ectool I got from here ages ago Exploring the Embedded Controller . Using the Framework ectool from GitHub - FrameworkComputer/framework-system: Rust libraries and tools to interact with the Framework Computer systems I can see this is again not an issue with YAFI (fansetrpm behavior is the same). That there is coin cell info (which is also wrong, should read at least 2) makes me think this info should be stored in a non volatile way normally. Maybe I will reset my EC and see what happens but I’m not all that fussed about this info.
Chassis status:
Coin cell ever removed: false
Chassis currently open: false
Chassis ever opened: true
Chassis opened: 1 times
Chassis opened while off: 2 times
Edit: I was mistaken the issue with the percentage setting not working properly only occurs when using YAFI to set the percentage independently of what was used to set the RPM previously. In other words when using the EC tool to set a percentage it works fine even if the previous command was to set an RPM of 300 or greater but YAFI will send the fan to full speed if the RPM was set to 300 or greater via EC tool or YAFI.
1 Like
I’ve released version 0.7, which adds support for modifying fan set points!
While they are only ‘on’ and ‘max’ set points, and not a proper fan curve, it is handled by the EC and does not require YAFI to run in the background. These set points also seem to survive a reboot.
You can download this release on GitHub.
For Flatpak users: at the time of writing, flathub hasn’t fully processed yet, but until that happens, you can download the test build with flatpak install --user https://dl.flathub.org/build-repo/239773/au.stevetech.yafi.flatpakref.
Oh and Merry Christmas everyone!
3 Likes
I’ve just released version 1.0, with Windows MEC support, which means that the Intel 11th, 12th, and 13th gen Laptops which were previously broken on Windows are now supported.
I believe every current Framework device is now supported on both Windows and Linux, and that achievement is the primary reason I’ve decided to bump it up to a major version this release.
There’s also few small fixes in this release, but mainly, there’s an amazing new icon and splash screen by oiimrosabel (Rosabel) · GitHub!
You can download this release on GitHub.
It should also eventually appear on Flathub, though the test build is here.
As I’ve now spent money on Intel hardware specifically for this project, I’m just gonna leave my GitHub sponsors link here too.
5 Likes
Hey a small thing I saw doing research on this for a bazzite install. A user actually requested a bazzite portal implementation of the YAFI install on framework devices but they seem to have a contributor to bazzite doubting what you have made.
A contributor to bazzites was issuing concerns over the security of YAFI last October in response for a request for a streamlined install process for YAFI on bazzite, and I figured this might be of interest to you simply because:
A: Their concerns weren’t ever an issue/have been addressed with future requests: In which case you should be able to prove that you’ve done the necessary work for it to be allowed to get a proper install script for the bazzite portal.
B: They can at least explain what their vague concerns are so if there is a serious issue with YAFI that other fan controllers/hardware management portals do not have, you can at least hear what the problem is and get it resolved. They didn’t state which specific issues made your software insecure in their view, but if there are real concerns we may want to get them addressed.
C: None of the bazzite portal supported fan controllers seem to support the framework desktop, all of the existing ones are specific to services that only support the framework laptops currently. Your tool could be the first there that has specific compatibility with the framework desktop.
AFAIK there isn’t an issue with the installation of your tool via flatpak/curl on bazzite but I haven’t tested it myself yet simply because with prices as they are now I really don’t want to be the first person to step in and test something like this with hardware that suddenly became very costly.
Still, given bazzite seems to ignore the BIOS settings for fan control in my experience, a tool like YAFI having a streamlined install there with support from developers on both sides seems like the best win case for end users, so whatever blame/git drama I am exposing you to I am sorry for, but getting this concern resolved would just be the best for people trying to experience framework hardware with low stress.
Ordinary users in general have a little to win by this being resolved.
Thanks for bringing this up, I haven’t seen this.
Yeah, their comment of “This is very insecure” is quite vague, but given the context I’m assuming this is to do with the udev rules.
I do have to agree that the added udev rules does reduce your security as you’re opening up /dev/cros_ec up to userspace so that YAFI can talk to it, and this would allow malicious software to also control and potentially reflash the EC.
However, the EC operates independently to the host system, with no access to its memory, or anything external, other than the sensors and fans; and additionally for the laptop: leds, charge controller, keyboard, and touchpad (you can check the schematics). The only worse case I can think of is someone might be able to reflash and brick the EC.
If I’ve missed anything please let me know though!
Most fan controllers would probably just use the HWMON interface, which is also available on Framework and allows for fan control, you just can’t set the setpoints. Also, I’m not sure if Bazzite installs a simplified version, but OpenRGB’s official udev rules seem to allow /dev/port access, which would allow an attacker to do exact same thing as above.
The Framework Desktop has the same EC, so if a tool can work with the Framework Laptop, it should work fine with the Desktop as long as there aren’t any explicit checks. I personally didn’t even know for sure that YAFI worked until someone brought it up.
Interesting, doesn’t look like open RGB is installed by default but interesting to know, but it is on the bazzite portal so I suppose you could argue its inconsistent that they are fine with access there that they aren’t fine with for YAFI.
You know, didn’t the framework-system actually give us a bash based setter endpoint recently for fan duties or am I hallucinating? Because it looks like there might be a way to do setter calls without necessarily needing direct EC access anymore as of a recent framework library commit (A commit from like 3 days ago seems to even have made the fans individually name indexed as well now, I’m backtracking to where they added EC fan controls to the API there and I keep finding updates for it from the last two-three weeks… But also they added a command to flash the EC as well via framework-system on march 25th so like… This is just something that you are able to do with framework API endpoints, it might not be a big deal.)
Honestly its been a binge catching up on all this simply because its been a while since I’ve dealt with this sort of in the weeds service/controller information binging. I’ll do my due diligence/research now that I’ve brought it up at least.
Well firstly, I’m pretty sure it would either need sudo, or the same udev rule; YAFI (or rather CrOS_EC_Python) talks to the EC in the exact same way that framework-system does (using cros_ec).
Secondly, I can’t find a setpoint/threshold arg to modify the behaviour of auto fan control (which was what I meant), it also hasn’t even got the EC command defined (0x0050) in framework_lib/src/chromium_ec/command.rs to do that. There’s only fansetduty and fansetrpm, which are also exposed by the kernel at (edit: nevermind, thought this patch would work)./sys/module/cros_ec_hwmon/drivers/platform\:cros-ec-hwmon/cros-ec-hwmon.*.auto/hwmon/hwmon*/fan1_input and fan1_target whether you have framework-system or not, and also how most Linux fan control software works
Haha yeah, it’s been a little while for me too!
I only knew about their endpoints because on fw_fancontrol (An adapter for converting generic fan controller calls to frameworks stuff, I only learned about it because of cooler control mentioning it as a driver service,) had an issue mentioning fw-system so I was mostly curious if that issue on their repo was a loose end or possibly something someone could lean on to create a lower setup service that manages this (Since if we could use the fw api to replace the service endpoint, that eliminates a curl from the setup.)
Looks like there are a few packages that might be able to do this currently since fw-fancontrol has pull requests trying to migrate it over to the framework library. Not sure if it needs sudo, but I doubt they would be trying to push on with it if it did need sudo.
ec-tool, their current method is exactly the same. systemd just runs it as root.
Also, funny thing about fw-fanctrl, I also have an open PR there haha (which would also eliminate a curl).