Hi,
On 9/17/20 3:50 PM, Benjamin Berg wrote:
On Thu, 2020-09-17 at 14:51 +0200, Hans de Goede wrote:
Compared to the WIP lenovo-dytc "perfmode" driver, we're missing
something to advertise the unavailability of a profile, and the reason
for that unavailability.
UGh, do we really need to export this though. We have the lap_mode thing
already; and that is something which we will need for other reasons in
the future too. Any UI for selecting performance modes can display a
warning when lap_mode is true saying that: "The laptop has detected that it
is sitting on someone's lap and that performance may be limited
because of this." (feel free to improve the text).
Well, for dytc_perfmode there are actually always the three states
L/M/H. It just happens that the kernel will write "H*" (was "M*" until
yesterday) when the performance mode is degraded due to lap detection.
Think of dytc_perfmode as a profile that sets a number of things:
* Thermal Limits
* Fan Behaviour
* possibly more
While dytc_lapmode will only enforce a change to the thermal limit.
So "performance" (H) is technically a valid mode even when the lap is
detected.
I guess we could split the "value" attribute from my reply to Benjamin's
email into "configured_value" (rw) and "actual_value" (rw) attributes.
If we have the info we might as well export it I guess,.
I consider the "*" purely a curtsey to users that read the attribute
directly using e.g. cat to help with the interpretation. It probably is
not interesting to userspace applications/daemons.
So if there is a difference between M and H and H* then I think we should
just do the KISS thing and only have a single value attribute and in the
new interface handle the H* like H (p-p-d can still check the lap_mode
attribute to differentiate the 2 if it wants to).
Regards,
Hans
