Skip to content

daemon: Never run Core::loadProfile() while the session is inactive

Jakob Petsovits requested to merge work/jpetso/inactive-means-inactive into master

The handler for PolicyAgent::sessionActiveChanged explicitly removes any registered timeouts when the session becomes inactive, but these timeouts can return through the backdoor when loadProfile() is called through some other means. E.g. when changing power states or when refreshing the configuration.

When inactive, we don't want to reinstate any idle timeouts for actions. Things like autosuspend and screen dimming are now the other session's responsibility.

This avoids weird and outdated polkit authorization dialogs when the user switches back to the session, and also avoids actions from multiple Plasma sessions messing with each other.

Fixes #34.

Test plan

For autosuspend (instructions for laptop):

  1. Set sleep timeout to 1 minute on AC power.
  2. Switch to a different session, console or desktop, doesn't matter.
  3. Briefly plug your power cable out, then back in.
  4. Wait a minute.
  5. Return to your session.

Before the patch, after returning to your session, you would likely find an authorization dialog asking for your password to suspend. That's a good thing, because logind prevented your system from actually going to sleep when the inactive session asked for it. But also the dialog is confusing and shouldn't be shown, especially now that you're active again.

After the patch, no such dialog should show. It won't go to sleep while your Plasma (dev) session is inactive, but it will go to sleep after a minute as soon as you're back and idle.

For dimming:

Similar idea, except you'd want to test with ddcutil ideally because it doesn't require polkit/KAuth access. But laptops will dim the internal display instead if that's possible, so the dimming test should work only for a system with no internal display (meaning, a desktop PC). Instead of using the power plug to trigger loadProfile(), you can sudo -u <devuser> -s from your other session and then write to $HOME/.config/powerdevilrc to trigger a configuration reload.

I haven't tried this. I've only seen system logs of both sessions wanting to adjust my laptop's internal backlight, and that's not quite as bad but still.

Edited by Jakob Petsovits

Merge request reports

Loading