Merge lp:~vanvugt/unity-mir/fix-1255045 into lp:unity-mir

Proposed by Daniel van Vugt
Status: Merged
Approved by: Michał Sawicz
Approved revision: 154
Merged at revision: 154
Proposed branch: lp:~vanvugt/unity-mir/fix-1255045
Merge into: lp:unity-mir
Diff against target: 33 lines (+9/-0)
1 file modified
src/unity-mir/dbusscreen.cpp (+9/-0)
To merge this branch: bzr merge lp:~vanvugt/unity-mir/fix-1255045
Reviewer Review Type Date Requested Status
PS Jenkins bot (community) continuous-integration Approve
Gerry Boland (community) Approve
Alan Griffiths Approve
Alexandros Frantzis (community) Approve
Michał Sawicz Approve
Review via email: mp+197016@code.launchpad.net

Commit message

Force the screen to redraw after turning the display back on (LP: #1255045).
Also stop the compositor when the screen is off. Otherwise it will spin in
the background, eating battery.

Description of the change

UNTESTED PROOF OF CONCEPT

Someone please try this out and let me know how it goes.

To post a comment you must log in.
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Also, I will now be away until Monday. If this doesn't quite suit your needs, please copy it, modify, and resubmit as you wish.

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Michał Sawicz (saviq) wrote :

Yup, this seems to be working!

review: Approve
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

Land this to fix bug by all means, but is it only the compositor that needs to be paused/resumed? Not the input and connector services too (via display->pause()/resume())?

review: Needs Information
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

> Land this to fix bug by all means, but is it only the compositor that needs to
> be paused/resumed? Not the input and connector services too (via
> display->pause()/resume())?

OK can we clarify the intent?

Are we intentionally pausing and resuming the compositing service or are we only doing that as a way to run:

    for (auto& f : thread_functors)
        f->schedule_compositing();

If, as I suspect, the latter then Compositor probably ought to publish a schedule_compositing() function (ideally with a parameter specifying what area(s) need drawing).

In any case this notification (or the pause/resume cycle if that's really needed) probably ought to come from the Display::configure() implementation, not from unity-mir.

Revision history for this message
Alexandros Frantzis (afrantzis) wrote :

The MediatingDisplayChanger class holds the logic for properly reconfiguring the display (pausing/resuming), so that's what we should expose (probably through a new interface). The Display::configure() method can't pause/resume internally
because 1. it has no knowledge of the compositor 2. in certain circumstances we don't want to pause/resume the compositor when reconfiguring (e.g. see resume() in display_server.cpp).

About using schedule_compositing(): when we reconfigure the display, we currently always create new display buffers (for gbm, at least, which supports multiple displays), and *have* to restart the compositor to use them. Also, it seems that our display classes don't deal very well with posting buffers when the display is off. So, even if we decide to pursue the schedule_compositing() direction in the future, we are not there yet.

I am OK with this fix until we expose the proper interfaces to unity-mir.

review: Approve
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

> The MediatingDisplayChanger class holds the logic for properly reconfiguring
> the display (pausing/resuming), so that's what we should expose (probably
> through a new interface). The Display::configure() method can't pause/resume
> internally
...
> I am OK with this fix until we expose the proper interfaces to unity-mir.

+1

review: Approve
Revision history for this message
Gerry Boland (gerboland) wrote :

Had expected Display::configure() to control the compositor, so yeah I see the need for this fix. I do think however that Mir should handle it in future, am looking forward to the new interfaces.

review: Approve
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) :
review: Approve (continuous-integration)

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/unity-mir/dbusscreen.cpp'
2--- src/unity-mir/dbusscreen.cpp 2013-09-25 09:30:08 +0000
3+++ src/unity-mir/dbusscreen.cpp 2013-11-28 07:50:58 +0000
4@@ -17,6 +17,7 @@
5 // mir
6 #include <mir/graphics/display.h>
7 #include <mir/graphics/display_configuration.h>
8+#include <mir/compositor/compositor.h>
9 #include <mir_toolkit/common.h>
10
11 // qt
12@@ -62,6 +63,7 @@
13
14 std::shared_ptr<mg::Display> display = m_serverConfig->the_display();
15 std::shared_ptr<mg::DisplayConfiguration> displayConfig = display->configuration();
16+ std::shared_ptr<mc::Compositor> compositor = m_serverConfig->the_compositor();
17
18 displayConfig->for_each_output([&](const mg::DisplayConfigurationOutput displayConfigOutput) {
19 if (displayConfigOutput.power_mode != newPowerMode) {
20@@ -75,6 +77,13 @@
21 }
22 });
23
24+ if (newPowerMode != MirPowerMode::mir_power_mode_on)
25+ compositor->stop();
26+
27 display->configure(*displayConfig.get());
28+
29+ if (newPowerMode == MirPowerMode::mir_power_mode_on)
30+ compositor->start();
31+
32 return true;
33 }

Subscribers

People subscribed via source and target branches