[Feature Request] Charging Profiles

[liketechnik]

First of all: This project is simply amazing!

Now, onto my feature request itself: more recent tuxedo control center versions allow to set so called 'charging profiles', which limit battery capacity used, in order to prolong battery life, for example in mostly stationary usage scenarios.

Is support for charging profiles something that would fit with this project?

(I haven't really looked at the code so far, but if there's agreement on how integration of this feature should look like, I would be totally open to take a stab at implementing it)

[AaronErhardt]

Is support for charging profiles something that would fit with this project?

Sure. The big question is how this is implemented on the TCC side. Unfortunately, TUXEDO has implemented multiple ways of communicating with their different drivers, so depending on whether your hardware actually comes from uniwill, clevo or schenker, the user space has to do different things to talk to the hardware. The newer drivers tend to use sysfs though, which is usually quite nice to work with.

If you want I can help you with reverse engineering TCC. Usually, looking at the commit history is a good starting point, especially for recently added features.

[liketechnik]

So, I've taken a look at the TCC source code. The first result of my research is, that 'charging profiles' is a little too broad, since there are actually 3 distinct charging related features supported by TCC (see also: https://www.tuxedocomputers.com/en/Battery-charging-profiles-inside-the-TUXEDO-Control-Center.tuxedo):

1. Charging Profiles: allows limiting the maximum charge of the battery (100%/90%/80%) in the firmware (i.e. battery is only charged up to 80% of it's real capacity, but this is presented as 100% in the system stats).
2. USB-C Charging Options: Allows prioritizing charging speed vs system performance when charging via USB-C.
3. Manually charge start/end thresholds: Essentially option 1, but instead of pre-defined profiles, allows manual selection of the start/end thresholds at which charging starts/ends.

The second result is: All of those options are accessible via sysfs, luckily. For reference, the following files where relevant:

• https://github.com/tuxedocomputers/tuxedo-control-center/blob/be9f8803ab8ff21d4bf0d66ce5a4418f7928320f/src/service-app/classes/ChargingWorker.ts - ties all three options together
• https://github.com/tuxedocomputers/tuxedo-control-center/blob/be9f8803ab8ff21d4bf0d66ce5a4418f7928320f/src/common/classes/ChargingProfileController.ts - feature 1
• https://github.com/tuxedocomputers/tuxedo-control-center/blob/be9f8803ab8ff21d4bf0d66ce5a4418f7928320f/src/common/classes/ChargingPriorityController.ts - feature 2
• https://github.com/tuxedocomputers/tuxedo-control-center/blob/be9f8803ab8ff21d4bf0d66ce5a4418f7928320f/src/common/classes/PowerSupplyController.ts - feature 3

Feature 1:

• /sys/devices/platform/tuxedo_keyboard/charging_profile/charging_profile & /sys/devices/platform/tuxedo_keyboard/charging_profile/charging_profiles_available

Feature 2:

• /sys/devices/platform/tuxedo_keyboard/charging_profile/charging_prio & /sys/devices/platform/tuxedo_keyboard/charging_profile/charging_prios_available

Feature 3:

• /sys/class/power_supply/*/type - for checking if battery or AC
• /sys/class/power_supply/*/charge_type - must be 'custom' to set custom thresholds
• /sys/class/power_supply/*/charge_control_start_threshold & /sys/class/power_supply/*/charge_control_end_threshold - set start/end thresholds
• /sys/class/power_supply/*/charge_control_start_available_thresholds & /sys/class/power_supply/*/charge_control_end_available_thresholds - query range of allowed values for start/end thresholds (marked as unofficial; might be unavailable even if the set start/end files are available)

Do you think there is further information required to implement this feature(s)? If no, how could/would/should I start implementing a prototype for the (first) feature(s)? Unfortunately, my hardware currently exposes only feature 1, so that's the only one I can test (possibly feature 3 is also available, but only with the new tuxedo-drivers kernel drivers, not the (now archived) tuxedo-keyboard drivers).

[AaronErhardt]

Thanks for looking into this!

Do you think there is further information required to implement this feature(s)?

Yes, that is already a very good starting point. Tuxedo-rs is very modular, so you can start implementing the first abstraction layer in tuxedo_sysfs and then add support to tailord later. You can look into the led module for inspiration. The code uses async Rust and tokio_uring to maximize performance (although it probably doesn't really matter), but the code will still look very similar to regular Rust code.