thermal_daemon VS EmbeddedController

You can make thermald ignore that protection by using the `--ignore-cpu-id` flag. See thread leading up to: https://github.com/intel/thermal_daemon/issues/268#issuecomm...

I don't use Windows but in Linux, using thermald you can also set your own temperature and power limits which would also effectively limit fan speeds. You can also control EPP/EPB manually...

If you're in the EU and looking for a thin and light with good battery life and need/want unsoldered/up-to 64GB of RAM, I believe that the Slimbook Executive 14/Tuxedo InfinityBook Pro 14 Gen7 might be the best options atm - 99Wh battery, 1.3kg for a 14" 16:10 version. Slimbook has a 16" version as well, although the battery is a bit smaller. These are Alder Lake H but using thermald and tlp I believe you can bring power usage in line w/ P or U chips.

thermald added support for both Alder Lake and Raptor Lake in version 2.5 two months ago, so you can build it for Linux Mint from the build instructions for Ubuntu here: https://github.com/intel/thermal_daemon

thermald settings can also affect battery life/performance a lot.

Similarly, on Intel laptops you can use https://github.com/intel/thermal_daemon to do the same (lower the TripPoint Max Temperature in thermal-conf.xml

For Intel, there's https://github.com/intel/thermal_daemon and actually a whole range of tools/strategies for using RAPL to control power usage that can be manipulated directly, like this: https://community.frame.work/t/thermal-management-on-linux-with-rapl-limits/17416

git clone --depth 1 https://github.com/FrameworkComputer/EmbeddedController cd EmbeddedController make utils sudo ./build/bds/util/ectool #USE AT YOUR OWN RISK - YOU CAN BRICK YOUR LAPTOP

When I was getting ready to flash again, I noticed an issue about the compiler version used to build the firmware binary. I followed the advice, but more importantly I noticed that the issue has been recently fixed, and in the resolution, the maintainer says "Next release (hx20 3.19, hx30 3.07) will include them". It reminded me of something crucial: the Framework EC firmware source code repo doesn't have any particular indication of its level of stability at any given commit. Which commits could be considered fully tested releases? What if the head of the branch introduces a bug that they're working on fixing?

The EC code on the normal Framework devices is already based on the Chrome EC code anyway. https://github.com/FrameworkComputer/EmbeddedController

EC firmware is open sourced by framework: https://github.com/FrameworkComputer/EmbeddedController

There the keyboard input is handled by the embedded controller: https://github.com/FrameworkComputer/EmbeddedController/blob...

On the 16 the keyboard is a USB keyboard that could even be used standalone, without the laptop.

I tried the pre-compiled `ectool` from the TamtamHero's repository as we and comiled the EmeddedController from Framework (from this repository). Both give the same error message.

Great reminder that (as of right now) we're far removed from hardware that is 100% free (as in freedom). The closest we've got is probably provided by Raptor Computing Systems. However not everyone in the world is privileged enough to own such devices unfortunately. And I haven't dabbled into other possible mishaps that come with using such devices. The lack of "free-hardware" is a major concern though. I'd argue that there aren't enough reasons to be optimistic about this as of right now. Therefore our best bet is to not let good be the enemy of perfect; light at the end of the tunnel...

As far as I'm aware the only way to manually change the fan speed is using `ectool` from https://github.com/FrameworkComputer/EmbeddedController/

We open sourced our Embedded Controller (EC) firmware and made it available on GitHub for you to modify if you wish.