Merge lp:~raof/mir/plumb-through-edid into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Alan Griffiths on 2016-11-30 |
| Approved revision: | 3860 |
| Merged at revision: | 3855 |
| Proposed branch: | lp:~raof/mir/plumb-through-edid |
| Merge into: | lp:mir |
| Diff against target: |
958 lines (+380/-55) 29 files modified
include/client/mir_toolkit/mir_display_configuration.h (+16/-0) include/platform/mir/graphics/display_configuration.h (+4/-0) src/client/display_configuration_api.cpp (+9/-0) src/client/symbols.map (+1/-0) src/platform/graphics/display_configuration.cpp (+2/-1) src/platforms/android/server/display_configuration.cpp (+2/-1) src/platforms/android/server/fb_device.cpp (+2/-1) src/platforms/android/server/hwc_blanking_control.cpp (+2/-1) src/platforms/common/server/kms-utils/drm_mode_resources.cpp (+5/-0) src/platforms/common/server/kms-utils/drm_mode_resources.h (+1/-0) src/platforms/mesa/server/kms/real_kms_display_configuration.cpp (+90/-1) src/platforms/mesa/server/x11/graphics/display_configuration.cpp (+2/-1) src/protobuf/mir_protobuf.proto (+1/-0) src/server/frontend/protobuf_buffer_packer.cpp (+10/-0) src/server/graphics/nested/nested_display_configuration.cpp (+4/-2) src/utils/out.c (+16/-0) tests/acceptance-tests/test_new_display_configuration.cpp (+157/-22) tests/include/mir/test/doubles/mock_drm.h (+3/-0) tests/mir_test/display_config_matchers.cpp (+6/-3) tests/mir_test_doubles/mock_drm.cpp (+5/-0) tests/mir_test_doubles/stub_display_configuration.cpp (+8/-4) tests/unit-tests/graphics/test_default_display_configuration_policy.cpp (+2/-1) tests/unit-tests/graphics/test_display_configuration.cpp (+2/-1) tests/unit-tests/graphics/test_overlapping_output_grouping.cpp (+2/-1) tests/unit-tests/input/android/test_android_input_lexicon.cpp (+1/-1) tests/unit-tests/input/test_input_event.cpp (+1/-1) tests/unit-tests/platforms/mesa/kms/test_cursor.cpp (+6/-3) tests/unit-tests/platforms/mesa/kms/test_display_configuration.cpp (+18/-9) tests/unit-tests/scene/test_mediating_display_changer.cpp (+2/-1) |
| To merge this branch: | bzr merge lp:~raof/mir/plumb-through-edid |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Alan Griffiths | 2016-11-29 | Approve on 2016-11-30 | |
| Daniel van Vugt | Approve on 2016-11-30 | ||
| Mir CI Bot | continuous-integration | Approve on 2016-11-30 | |
| Gerry Boland | Needs Information on 2016-11-29 | ||
|
Review via email:
|
|||
Commit Message
Add an EDID accessor to client and server display configuration.
This will likely want to be augmented with some structured data extracted
from the EDID, so that clients and servers don't have to include an EDID
parser to get output display name, unique IDs, and so on, and we can
provide some sensible values in cases where the output doesn't have an
EDID.
There are potentially interesting things in the EDID that we don't need
to provide a separate facility for, so providing the EDID is still useful
even once we have structured data available for those users that want it.
- 3859. By Chris Halse Rogers on 2016-11-29
-
Don't leak the MirDisplayConfig in the tests
| Mir CI Bot (mir-ci-bot) wrote : | # |
FAILED: Continuous integration, rev:3859
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
FAILURE: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
| Alan Griffiths (alan-griffiths) wrote : | # |
06:38:42 /<<BUILDDIR>
06:38:42 expectations.
06:38:42 ^
06:38:42 /<<BUILDDIR>
I guess this belongs.
Otherwise mostly looks OK
| Alan Griffiths (alan-griffiths) wrote : | # |
+ size_t const min_edid_size = 128;
could be static constexpr
| Gerry Boland (gerboland) wrote : | # |
+uint8_t const* mir_output_
+ * \returns A pointer to the start of the raw EDID data.
Stupid question, but how do I as an api user know where the end of the raw EDIT output is?
| Gerry Boland (gerboland) wrote : | # |
> +uint8_t const* mir_output_
> + * \returns A pointer to the start of the raw EDID data.
> Stupid question, but how do I as an api user know where the end of the raw
> EDIT output is?
I safe assume it is 128 bytes long, and then a parser can read more if it knows about extensions?
| Alan Griffiths (alan-griffiths) wrote : | # |
> > +uint8_t const* mir_output_
> > + * \returns A pointer to the start of the raw EDID data.
> > Stupid question, but how do I as an api user know where the end of the raw
> > EDIT output is?
> I safe assume it is 128 bytes long, and then a parser can read more if it
> knows about extensions?
That's my reading.
| Chris Halse Rogers (raof) wrote : | # |
On Tue, Nov 29, 2016 at 10:16 PM, Gerry Boland
<email address hidden> wrote:
>> +uint8_t const* mir_output_
>> + * \returns A pointer to the start of the raw EDID data.
>> Stupid question, but how do I as an api user know where the end of
>> the raw
>> EDIT output is?
> I safe assume it is 128 bytes long, and then a parser can read more
> if it knows about extensions?
Yes. Byte 127 of the EDID is the number of subsequent extensions.
It is safe to assume the EDID is 128 bytes. Do you have any suggestions
for how the comment could be made clearer?
- 3860. By Chris Halse Rogers on 2016-11-30
-
Hand-hold Vivid-era compilers
| Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3860
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
| Daniel van Vugt (vanvugt) wrote : | # |
Cool.
Week needs fixing:
* Platform ABI break needs bumping due to include/
* mir_output_get_edid should in future be accompanied by some nice string helper functions like mir_output_
| Daniel van Vugt (vanvugt) wrote : | # |
*Weak needs fixing*
| Gerry Boland (gerboland) wrote : | # |
> Yes. Byte 127 of the EDID is the number of subsequent extensions.
>
> It is safe to assume the EDID is 128 bytes. Do you have any suggestions
> for how the comment could be made clearer?
No it's ok.

FAILED: Continuous integration, rev:3858 /mir-jenkins. ubuntu. com/job/ mir-ci/ 2278/ /mir-jenkins. ubuntu. com/job/ build-mir/ 2956/console /mir-jenkins. ubuntu. com/job/ build-0- fetch/3021 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= vivid+overlay/ 3013 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= xenial+ overlay/ 3013 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= yakkety/ 3013 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= clang,platform= mesa,release= yakkety/ 2985/console /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= xenial+ overlay/ 2985/console /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= yakkety/ 2985/console /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= cross-armhf, compiler= gcc,platform= android, release= vivid+overlay/ 2985/console /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= android, release= vivid+overlay/ 2985/console /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= mesa,release= xenial+ overlay/ 2985/console
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
Click here to trigger a rebuild: /mir-jenkins. ubuntu. com/job/ mir-ci/ 2278/rebuild
https:/