vagnum08 / cpupower-gui

cpupower-gui is a graphical program that is used to change the scaling frequency limits of the cpu, similar to cpupower.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

auto apply handling

Optiligence opened this issue · comments

Describe the issue

  • directly upon installation, automatically enabled included services unconditionally apply some profile at boot

  • to adjust the configuration that’s used at boot, one needs to know to either edit config in /etc or to manually start as root (it’s a GUI…)

    • any config in /etc basically gets invalidated silently once you used the GUI as root for the first time
    • it’s not obvious that you need to start as root, especially since it works just fine to change the settings live without root
    • a disabled apply-service gets re-enabled during a package update
  • the default Balanced profile may be undesired

    • in my case this resulted in powersave being applied at every boot, just by installing the package
    • that seems to be improved to schedutil in git

Expected behaviour

  • program doesn’t interfere with CPU governor at boot simply by installing or starting it
  • it is obvious in the GUI what’s applied at boot and how to configure it

suggested solution

  • »Apply at boot« toggle in the GUI that’s disabled by default.
  • show state of apply service
    • only the global service if that is the only one to be configured
    • the user or global service depending on if it’s run as root, or switchable if the distinction remains desired
  • when starting via non-root, user is directed to boot configuration by
    • direct adjustment in the GUI via the already running services
    • enable/disable service as user or global (via elevation/sudo prompt)
    • highlighted request to manually run as root

Setup (please complete the following information):

  • Distro: Arch
  • Package version: 1.0 as well as git
  • Installed via: aur

Additional stuff
It would also be nice to rename the apply service to something that includes »boot« or »apply« – it’s not immediately obvious that that’s what it does without checking its description.

Hi,

to adjust the configuration that’s used at boot, one needs to know to either edit config in /etc or to manually start as root (it’s a GUI…)

You shouldn't run the GUI as root. It uses policykit for that reason. If your user has administrative privileges (i.e. sudoer/admin) it will ask for elevated privileges before applying the settings.

program doesn’t interfere with CPU governor at boot simply by installing or starting it

That doesn't have to do with the program itself but rather the packaging of said software. The program doesn't enable any services it is the package that does, so that is distro specific.

The rest are valid points so I will change the issue from a bug to enhancement instead.

P.S. For the service that get re-enabled, it is better to mask the service that disable it. For example, a disabled service can still be run when another service depends on it. However a masked one never starts.

If your user has administrative privileges (i.e. sudoer/admin) it will ask for elevated privileges before applying the settings.

Apply seems to work without any prompt. And the preferences also don’t prompt.
When exactly is a prompt intended to appear?

packaging of said software

Since your name is listed as maintainer of the AUR package, i thought it’s enough to mention it here.

I hadn’t used mask before, so that’s interesting.

Polkit config for cpupower-gui is setup in such a way that it won't ask for a password if the user is member of system group and physically logged in. If you try to change settings over SSH it should fail.

If you are a simple user it will ask for admin's password to proceed.

As for packaging, if I am recalling correctly used the same pkgbuild as other packages in core/community. Also, this happens automatically for Debian, in fact the packager has to explicitly disable the behaviour of enabling the service after install, and I think it also happens in Fedora.

That being said, I believe the problem is more with setting the wrong governor by default than actually enabling the service.

I mean if the default was to keep the current settings during install and apply that at boot it wouldn't be that of a problem (omnipotence comes to mind) Right?

Is Polkit also used for anything related to the boot configuration?

I think on Arch packages usually don’t enable services automatically.
But, indeed, it would matter less if it had no noticeable effect without any user adjustments (by only reapplying the current settings).
I would still prefer if the system configuration wasn’t touched at all, initially, by default.