Mir

[enhancement] permit clients to perform prep logic while screen is blanked

Bug #1279422 reported by kevin gunn on 2014-02-12
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Invalid
High
Unassigned
mir (Ubuntu)
Undecided
Unassigned

Bug Description

With a split greeter (I can give instructions on how to make this happen):
1) Turn off screen
2) Turn on screen

Watch the greeter slowly open after a few seconds of looking at the session as it was left when you turned off the screen.

I believe what is happening here is that Mir/Qt will freeze an executable if Mir isn't accepting its buffers. So the greeter is stuck early in its startup code.

Ideally the greeter would be able to continue loading until right up to its first frame of actual content.

== Original Description ==

Currently its understood that mir prevents clients from performing any startup logic. Greeter needs to be able to prepare for the presentation of the lock screen prior to the screen coming on.

kevin gunn (kgunn72) on 2014-02-12
Changed in mir:
status: New → Triaged
importance: Undecided → High
tags: added: nested
Michael Terry (mterry) on 2014-02-12
description: updated
tags: added: enhancement
summary: - permit clients to perform prep logic while screen is blanked
+ [enhancement] permit clients to perform prep logic while screen is
+ blanked
Daniel van Vugt (vanvugt) wrote :

This sounds very similar to bug 1280842

Michael Terry (mterry) wrote :

Maybe? If Mir is freezing itself out by not accepting its own startup buffers, maybe that's the root cause of this bug?

How exactly does Mir "freeze" apps? Does Qt have internal logic that stops its mainloop if the Mir backend isn't accepting buffers? Or does Mir stop its own mainloop?

Alan Griffiths (alan-griffiths) wrote :

Mir "freezes" apps by not returning a buffer to the client.

I've not been following the details, but it seems that on the Mesa stack there's a bug (arguably in the Mesa Mir support) that causes the client post the first buffer without writing to it (Daniel mentions it in bug 1280842). Could this be something similar?

kevin gunn (kgunn72) wrote :

i think this is actually more about interacting with unity-mir
from irc: a message is sent by unity-mir via mir, there's a lifecycle message type in Mir itself. Client's listen for it and can save their state if they want. After 3 seconds, unity-mir sends a SIGSTOP to pause the app. on reusme it sends SIGCONT

Michael Terry (mterry) wrote :

@Alan, all my testing is on mako. So no mesa backend involved.

@Kevin, that comment about lifecycle message isn't quite what I think I'm seeing. Because my use case is loading a new greeter session (not an app client of unity-mir, but a whole new unity-mir instance).

I need to do a combination of further investigation into what's happening under the covers in my use case and grokking the multiple ways I'm hearing that Mir freezes apps (via buffers and via messages).

Alan Griffiths (alan-griffiths) wrote :

I think a significant part of the problem experienced is bug 1284739

Michael Terry (mterry) wrote :

This may not happen anymore. Recent testing hasn't been able to reproduce this problem... Will keep this open for now, but don't work on it.

kevin gunn (kgunn72) wrote :

marking incomplete for the moment...let's keep an eye out

Changed in mir:
status: Triaged → Opinion
status: Opinion → Incomplete
Changed in mir (Ubuntu):
status: New → Incomplete
Michael Terry (mterry) wrote :

Latest Mir works fine for this. Will close.

Changed in mir (Ubuntu):
status: Incomplete → Invalid
Changed in mir:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers