Jakob Petsovits commented on merge request !290 at Plasma / PowerDevil

Okay, so in the meantime, GNOME and UPower are introducing their own concept of charge limit enablement. Read more in the linked blog post and corresponding UPower MR, but the down-low is this:

• UPower will expose a single new writable D-Bus property named ChargeThresholdEnabled, which will be presented to the user in GNOME Control Center as a single checkbox. There's also a method called EnableChargeLimit which I'll need to comment on because that's confusing vs. already having a similar property. The actual charge threshold percentages are read-only properties.
• If a user wants to change their actual threshold values, they will have to add hwdb configuration that matches their battery and overrides the setting. Quote UPower MR:

# To add local overrides, create a new file# /etc/udev/hwdb.d/61-battery-local.hwdb# and add your rules there. To load the new rules execute (as root):# systemd-hwdb  update# udevadm trigger -v -p /sys/class/power_supply/BAT# where BAT is the battery in question.battery:*:*:dmi:* CHARGE_LIMIT=60,80

• Also, they don't seem to have talked about a threshold-less "battery conservation mode" as in !248, but I'll bet anyone that when they do, it will use the same existing checkbox rather than provide a different UI for it.

This puts us a little bit in a bind. We could continue with this MR or !253, but either way we'll have to rework both UI and backend if we want to make use of UPower's status as privileged, cross-platform system daemon to reapply this automatically at startup and enable it without KAuth requirements. We also want to avoid ending up with a system that standardizes the GNOME/UPower approach while leaving us the odd one out.

So here's what I'm thinking we should do instead.

• Change our existing KAuth helper to also write a hwdb config file with the aforementioned CHARGE_LIMIT snippet. We can name it /etc/udev/hwdb.d/62-battery-plasma-powerdevil.hwdb and hardcode that filename for all I care, to make our lives easier.
• Change our existing KAuth helper to check whether this particular file exists, and if it does, parse the values for getthreshold from the hwdb config as opposed to reading the battery device files themselves. Similar to what this MR is doing, just with different storage.
• Change our existing KAuth helper to introduce a restorechargelimit command, also as drafted in this patch. So far, so similar.
• Plan to introduce a checkbox to KCM global settings which mirrors the one that GNOME is getting.
  • Charge thresholds, if supported, will be applied if the checkbox is checked.
  • Battery conservation mode, if supported instead of thresholds, will be enabled if the checkbox is checked.
  • Charge threshold percentage fields, if supported, will be enabled if the checkbox is checked and disabled otherwise.
• Plan to replace our KAuth helper with UPower D-Bus API at a later point, with a transition period that supports both.
  • Design the config storage for the "enabled" checkbox such that we can:
    • Upgrade from "just having thresholds set", with the checkbox checked if thresholds are any other than 100% & enabled.
    • Determine whether we've upgraded from our own storage to UPower storing the checkbox value for us instead. Some kind of flag that we'll set once we've successfully called the corresponding UPower setter.
  • So to me this looks like an enum ChargeLimitsEnabledStatus with possible values Unset, Enabled, Disabled, StoredByUPower. Perhaps we can do without Unset if we can rely on a KConfig update script to set it according to existing threshold values & without auth dialog.
  • On PowerDevil daemon load, call KAuth restorechargelimits if our status value is Enabled.
    • Edit: Should restorechargelimits also run when the status is Unset, and populate the hwdb config with current hardware battery threshold values? Or wait until the user next opens the KCM and then ask for manual authorization?
  • On both PowerDevil daemon load and KCM load, query UPower's new charge limits API to see if it exists. If it does and charge limit status is Enabled, set it enabled in UPower and change the config entry to StoredByUPower.
    • Migrate from status == Unset if we didn't have a KConfig update script take care of it.
  • On KCM load:
    • If StoredByUPower, populate settings fields with values queried from UPower.
      • Query failed because UPower was downgraded or uninstalled? Bad luck, we don't support migrating back from it. Mark as unsupported.
      • Store the checkbox value via UPower D-Bus.
      • Store charge thresholds via KAuth helper, only if changed, to prevent the authorization dialog from popping up. (We already do it this way, no changes required.)
    • It Enabled or Disabled, populate with values queried from the KAuth helper.
      • Store both checkbox value and charge thresholds via KAuth helper.
      • Hope for a newer UPower to appear later.
  • Keep the KAuth helper indefinitely for setting the actual threshold values, unless UPower eventually makes them read/write as well. In which case we'd have to migrate our stuff, but right now it doesn't look like that'll happen.
    • Eventually, remove restorechargelimits from the KAuth helper, have it focus exclusively on setting hwdb configs with threshold values.

So in summary, I think the idea of this MR is about right, but the implementation needs a full overhaul. I'll set it back into Draft status. Please provide feedback if I haven't already lost you after the wall of bullet points above.