Merge lp:~kdub/mir/power-control-to-display into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Daniel van Vugt on 2015-01-09 |
| Approved revision: | 2170 |
| Merged at revision: | 2210 |
| Proposed branch: | lp:~kdub/mir/power-control-to-display |
| Merge into: | lp:mir |
| Prerequisite: | lp:~kdub/mir/hwc-common-cleanups |
| Diff against target: |
1343 lines (+272/-268) 30 files modified
src/platforms/android/display.cpp (+34/-13) src/platforms/android/display.h (+3/-0) src/platforms/android/display_buffer.cpp (+3/-13) src/platforms/android/display_buffer_builder.h (+3/-0) src/platforms/android/display_device.h (+2/-2) src/platforms/android/fb_device.cpp (+30/-18) src/platforms/android/fb_device.h (+13/-1) src/platforms/android/framebuffers.cpp (+5/-4) src/platforms/android/framebuffers.h (+1/-0) src/platforms/android/hwc_blanking_control.cpp (+6/-2) src/platforms/android/hwc_common_device.cpp (+1/-37) src/platforms/android/hwc_common_device.h (+0/-7) src/platforms/android/hwc_configuration.h (+2/-1) src/platforms/android/hwc_device.cpp (+2/-3) src/platforms/android/hwc_device.h (+3/-4) src/platforms/android/hwc_fb_device.cpp (+5/-2) src/platforms/android/hwc_fb_device.h (+1/-2) src/platforms/android/output_builder.cpp (+13/-1) src/platforms/android/output_builder.h (+3/-2) src/platforms/android/resource_factory.cpp (+2/-5) tests/include/mir_test_doubles/mock_display_device.h (+1/-1) tests/include/mir_test_doubles/stub_display_builder.h (+23/-2) tests/unit-tests/graphics/android/test_display.cpp (+52/-6) tests/unit-tests/graphics/android/test_display_buffer.cpp (+16/-10) tests/unit-tests/graphics/android/test_fb_device.cpp (+12/-17) tests/unit-tests/graphics/android/test_fb_simple_swapper.cpp (+3/-3) tests/unit-tests/graphics/android/test_hwc_common_device.cpp (+2/-70) tests/unit-tests/graphics/android/test_hwc_configuration.cpp (+8/-3) tests/unit-tests/graphics/android/test_hwc_device.cpp (+20/-28) tests/unit-tests/graphics/android/test_hwc_fb_device.cpp (+3/-11) |
| To merge this branch: | bzr merge lp:~kdub/mir/power-control-to-display |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| PS Jenkins bot | continuous-integration | Approve on 2015-01-09 | |
| Cemil Azizoglu (community) | Approve on 2015-01-08 | ||
| Alan Griffiths | Approve on 2015-01-07 | ||
| Robert Carr (community) | Approve on 2015-01-06 | ||
| Daniel van Vugt | 2014-12-17 | Abstain on 2015-01-06 | |
|
Review via email:
|
|||
Commit Message
android: move the display control from mga::DisplayDevice implementations to mga::Display.
mga::Display is the object that's best positioned to see and configure all the displays.
Description of the Change
android: move the display control from mga::DisplayDevice implementations to mga::Display.
mga::Display is the object that's best positioned to see and configure all the displays.
note: This branch has mga::Display controlling the display, and mga::DisplayBuffer used as storage space for the DisplayConfigur
note: I have a hazy memory of us wanting to improve DisplayBufferBu
| Kevin DuBois (kdub) wrote : | # |
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2167
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Daniel van Vugt (vanvugt) wrote : | # |
Text conflict in src/platforms/
Text conflict in src/platforms/
Text conflict in src/platforms/
Text conflict in src/platforms/
Text conflict in tests/include/
Text conflict in tests/unit-
Text conflict in tests/unit-
Text conflict in tests/unit-
Text conflict in tests/unit-
Text conflict in tests/unit-
10 conflicts encountered.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2168
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Robert Carr (robertcarr) wrote : | # |
+} catch (...) {}
Can we log this?
+ off = false;
I think that the BlankingControl impl needs a mutex, or perhaps in Display:
+ config.
It's enough to take ownership of the configuration mutex.
| Robert Carr (robertcarr) wrote : | # |
Im not so sure the mutex is really an issue I guess as its only not held during config changes during the ctor and dtor...I doubt this could be particularly problematic. I think it's worth acquiring the mutex from the dtor though (it may be worth updating the signature: safe_power_
| Kevin DuBois (kdub) wrote : | # |
> +} catch (...) {}
>
> Can we log this?
Some drivers report incorrect failure error codes on startup, I'd rather not log anything to avoid having people think there's problems when the driver is operating as best as we can get it to.
> + off = false;
>
> I think that the BlankingControl impl needs a mutex, or perhaps in
> Display:
>
> + config.
>
> It's enough to take ownership of the configuration mutex.
Display now serializes the calls between the display posting functions and the blanking controls. The second mutex is not needed, nor could a mutex in BlankingControl protect against the display trying to post and turn on/off at the same time.
| Kevin DuBois (kdub) wrote : | # |
> +} catch (...) {}
>
> Can we log this?
Some drivers report incorrect failure error codes on startup, I'd rather not log anything to avoid having people think there's problems when the driver is operating as best as we can get it to.
> + off = false;
>
> I think that the BlankingControl impl needs a mutex, or perhaps in
> Display:
>
> + config.
>
> It's enough to take ownership of the configuration mutex.
Display now serializes the calls between the display posting functions and the blanking controls. The second mutex is not needed, nor could a mutex in BlankingControl protect against the display trying to post and turn on/off at the same time.
| Robert Carr (robertcarr) wrote : | # |
>> Some drivers report incorrect failure error codes on startup, I'd rather not log anything to >> avoid having people think there's problems when the driver is operating as best as we can get >> it to.
I would make the other call. Remember users aren't looking at logs. We are interpreting logs from users. The message could even warn of false positives.
>> Display now serializes the calls between the display posting functions and the blanking
>> controls. The second mutex is not needed, nor could a mutex in BlankingControl protect against >> the display trying to post and turn on/off at the same time.
Ah, sorry
| Alan Griffiths (alan-griffiths) wrote : | # |
Just nits
> > +} catch (...) {}
> >
> > Can we log this?
>
> Some drivers report incorrect failure error codes on startup, I'd rather not
> log anything to avoid having people think there's problems when the driver is
> operating as best as we can get it to.
Preexisting I guess, but I think that deserves a comment to explain the code.
~~~~
92 + ~Display();
Destructors ought to be noexcept
| Kevin DuBois (kdub) wrote : | # |
nits addressed
| Alan Griffiths (alan-griffiths) wrote : | # |
> nits addressed
Although I'd have put the comment at the "catch (...) {}" not at just one of the two call sites.
| Cemil Azizoglu (cemil-azizoglu) wrote : | # |
Just marking so I get a chance to review. I should be able to do it later today.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2169
http://
Executed test runs:
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2170
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Autolanding.
More details in the following jenkins job:
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
| Daniel van Vugt (vanvugt) wrote : | # |
Looks like a CI hiccup that's affecting other branches too. Trying to top approve...

conflicts a bit with unbury- display- config- query, will fix-up once one of them lands