Describe implications of turning the screen off/locking the display

Feature: use-cases#47 and use-cases#78

This should cover the behavior of the use cases to explain common questions that developers (and users) might have about how applications respond to screen locking, such as: What happens when locking the screen or suspending the phone?

• Are applications paused, or do they always run in the background?
• Are they reprioritized?
• https://forums.puri.sm/t/locking-and-app-lifecycle/4380/15
• Is the session's contents/state stored? (In the case of suspending rather than just locking.)
• What can apps do to minimize power usage, especially when in the background?

changed the description

changed the description

changed the description

Also, we need to answer:

• How to switch the phone on and off?
• Does holding down the power button turn it on/off or just wake/suspend it?
• Will there be a menu that appears when turning it off?

What follows requires working wakeups like https://source.puri.sm/Librem5/linux-next/issues/21 and cellular data which we don't have yet (or even verified that technically possible?).

But if we have that, my suggestion would be to behave similar to a laptop, which is quite similar to Android too I guess:

• suspend is S3-suspend
• WHEN to suspend is up to userspace:
  • I think what people really expect is suspend on power-button (short) press. Many people are used to that.
    • Detail that might be clever: I would turn off the screen on power-button press, and really suspend after X seconds (giving a few seconds in case people turn it off and on again quickly; heuristics, but IMO that makes sense, and there's no visual difference).
  • I would make a soft-button for suspend (gnome has the "pause" icon I think) next to the settings menu button in the top menu, just to avoid HW-button wear-out
  • People lay down their fully turned-on phone and go away. That should not drain the battery! So have one policy for auto-suspend "after inactivity". just like on a laptop, configurable in Gnome (with a good default).
• In suspend, applications stop running. what do you mean by "Are they reprioritized?"?
• the session's state is stored, just like on a laptop
• Resume on: message/call or short power-button press.
• After resume, Apps resume running and the Lockscreen (login) is shown. Again, just like on any Gnome Laptop. (What Apps can do to minimize power usage is app-specific, but during suspend it doesn't matter.)

That's just what I would expect and, if we get it right, would result in good battery times, while still being able to watch a video until the battery dies.

Until now in my suggestion there is no mode in which the screen is off and system is running anyways. On Laptops, we have the "Lock" button in the top-menu. That feels a little dangerous and tricky. I would just leave that out at first. Draining the battery by a running system or the display is both draining the battery.

IMO long power-button press should display the "shutdown / reboot" menu (and also having that in the top-menu as a button).

That's all just my whishes or initial thoughts.

Sorry for the delay in replying to your comment.

When I asked about apps being reprioritized, I was thinking of apps running in the "background" whose windows are not at the top of the stack. I wondered if there would be some mechanism to renice them, or something similar.

do you have a link to what we currently do to "prioritize" apps? apply nice values? Should be easy enough to come up with a policy that works independently of suspend/resume I think.

I don't have an overview of the current situation. Issues like #30 imply that the documentation should describe how to interact with the power management system but don't say who the target audience is: OS developers or application developers. I created this issue in a batch of issues to try and get some answers to infrastructure-related questions.

mentioned in issue #119