Skip to content
This repository has been archived by the owner on Nov 4, 2023. It is now read-only.

The system is allowed to sleep before Lomiri locks #409

Open
UniversalSuperBox opened this issue Aug 7, 2021 · 0 comments
Open

The system is allowed to sleep before Lomiri locks #409

UniversalSuperBox opened this issue Aug 7, 2021 · 0 comments

Comments

@UniversalSuperBox
Copy link
Member

It is generally expected that when you turn the screen off on your device, the screen is locked when it turns back on. Absolutely nothing of your session should be shown when you turn it back on. An Ubuntu Touch system fails this. When you put a non-Android Ubuntu Touch device to sleep, when you wake it back up you'll see your unlocked session for a few seconds. You cannot interact with it, but you can see it. Then the device locks.

The exact technical problem here is that it is possible for the device to go to sleep before Lomiri has shown the lock screen. The Autosleep method used on mainline Linux devices is very aggressive at sleeping, it can take mere milliseconds from screen-off to deep sleep. We can use an Upstart script to keep the device awake for a little longer, which is what I'm developing right now. But we want to do it properly. If Lomiri had a way to tell the system "don't go to sleep yet, I'm busy" we'd be in a better state.

There are a couple of ways to make this possible.

The first possible solution is to make Lomiri decide when the system will go to sleep. This requires Lomiri to directly take suspend blockers (wakelocks) from repowerd. Right now, qtmir has a SharedWakelock implementation that would be really cool to have in Lomiri. But it's private in qtmir. Once we have a wakelock implementation in Lomiri, it will need to take a wakelock as soon as the screen turns on. When the screen turns off and is locked, the wakelock can be released. Taking the wakelock immediately on screen off prevents needing to target the wakelock-taking action into the millseconds between the screen-off notification from repowerd and the system actually going to sleep.

The second possible solution is to further integrate Lomiri, repowerd, and systemd-logind. logind has grown a lot of session state variables since it was first implemented in the stack. My idea looks something like this:

  1. lomiri-system-compositor tells repowerd that it's time to turn off the screen
  2. repowerd tells Lomiri that the screen is off
  3. Lomiri checks that all screens are off. If they are, it begins locking.
  4. Once locking is complete (there is no way the screen will show the previous session), Lomiri tells systemd-logind that the session is inactive and locked.
  5. systemd-logind tells repowerd that the session is inactive and locked
  6. repowerd allows suspend
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant