liketechnik
commented
3 months ago No worries regarding and delays, that's just how it is :) (and you're not alone with that, it unfortunately took me quite some time to get back to this too)
I've finally gotten around to implement the aforementioned split between charging profile & priority. Additionally, I've added simple writers for all writable properties.
I believe that should be it for the sysfs abstraction part. Would you prefer the integration into the rest of the application to happen in a different PR or to keep this PR as a draft until the options are available in the UI?
This is my first draft for implementing the sysfs abstraction for the charging profiles discussed in #80.
The TODO notes in the diff mark stuff where I'm unsure which model fits best. Please make a suggestion on the approach you prefer.
Note that so far this implements only the read-part of the abstraction. For the write-part: How 'thick/thin' is the sysfs abstraction supposed to be? E.g., when writing the charging thresholds, should the method itself check that constraints are met (i.e. charge_type == "Custom", value between either 0-100 or in the available_start_threholds list).
I have tested that this works with the tailor_hwcaps binary, although my hardware (/ drivers) only supports the charging profile (i.e. both the charge thresholds and the charging priority are correctly reported as "not available").