1. Simply treat this as 6 different profiles, maybe with documenting
-ac/-battery postfixes for the profile-names and let userspace
sort it out.
Pro: -Simple from the kernel side
Contra: -Does not work with existing userspace code
-This is quite ugly IMHO / does not feel right
2. Only export three profiles to userspace, while going "all in" on this
concept and change drivers/acpi/platform_profile.c to add new:
/sys/firmware/acpi/platform_profile_ac
/sys/firmware/acpi/platform_profile_battery
files which can contain different desired settings for the ac/battery
case and have the kernel automatically switch between the two and
also have it pass the ac/battery state to
platform_profile_handler.profile_set so that for hw which has
different ac/battery flavors of the profile the driver knows which
one to select (without needing to detect this itself)
Pro: -This matches well with the behavior which we want for the user
(which is for the system to save the profile as 2 separate settings
for ac/battery and switch the profile to the last selected setting
for ac/battery when the state changes)
-Solve the ac/battery state listening/notification only once
instead of having all platform_profile drivers DIY
Contra: -This means deprecating /sys/firmware/acpi/platform_profile and
defining how it maps to the 2 new files, e.g. if it is written
does that only set the current active profile, or both ?
-Userspace needs to be adjusted to use the new uapi and once it
has been adjusted it also still needs to work on the older
kernels which will be tricky/nasty to implement and also is
a problem from CI / testing pov.
3. Only export three profiles to userspace and have the
drivers/acpi/platform_profile.c "core" code pass the ac/battery state
to platform_profile_handler.profile_set so that for hw which has
different ac/battery flavors of the profile the driver knows which
one to select (without needing to detect this itself)
Pro: -Solve the ac/battery state listening/notification only once
instead of having all platform_profile drivers DIY
-Leaves the existing userspace API 100% unchanged and leaves
existing userspace code working without it requiring any
changes
Contra: -As part of the discussion on this the RFE to "have separate
"last selected" ac/battery profile settings and automatically
switch when the state changes" has surfaced; and that is
not solved
Writing it down like this, to me 3. is the clear winner. The only
downside of 3. I can come up with arguably is better solved in
userspace (2), esp. since this will likely also require some UI design
work to somehow make it clear to the user that there are two different
settings (3).
Also even if no UI changes are deemed necessary this will still require
userspace changes to save+restore the two separate "last selected"
profile settings over reboots.
Please let me know what you think of this, and of course another
completely different approach is welcome too.
Regards,
Hans
1) Although AMD based ThinkPads are the trigger for this discussion,
this applies to more new AMD based laptops, so this is not ThinkPad
specific
2) IMHO it would be good to file a RFE issue for this against p-p-d:
https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/new
3) AFAICT Windows does the 2 separate "last selected" ac/battery profile
settings thing while just showing a single slider in its UI, but that
really is a whole other discussion which the userspace/UI folks can have.
