Merge lp:~vanvugt/mir/remove-hybrid-outputs-logging into lp:mir
Status: | Work in progress |
---|---|
Proposed branch: | lp:~vanvugt/mir/remove-hybrid-outputs-logging |
Merge into: | lp:mir |
Diff against target: |
61 lines (+0/-45) 1 file modified
src/platforms/mesa/server/kms/display.cpp (+0/-45) |
To merge this branch: | bzr merge lp:~vanvugt/mir/remove-hybrid-outputs-logging |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Mir CI Bot | continuous-integration | Approve | |
Cemil Azizoglu (community) | Abstain | ||
Chris Halse Rogers | Abstain | ||
Review via email: mp+321943@code.launchpad.net |
Commit message
Remove redundant logging of outputs introduced with hybrid support
in mesa-kms recently.
The existing logging we already do for all platforms is more detailed
and more useful. The new logging being removed here is less than useful
because it's single-platform, confused by missing output IDs, missing most
of the output details we already log elsewhere, and simultaneously floods
the server log with all supported mode details which we don't need.
If we do want that last part, it should be added to the existing
mir::report:
instead, where it would apply to all graphics drivers.
Unmerged revisions
- 4143. By Daniel van Vugt
-
Try again
- 4142. By Daniel van Vugt
-
Merge latest trunk
- 4141. By Daniel van Vugt
-
Again?
- 4140. By Daniel van Vugt
-
Remove extraneous logging of outputs introduced with hybrid support
in mesa-kms recently.The existing logging we already do for all platforms is more detailed
and more useful. The new logging being removed here is less than useful
because it's single-platform, confused by missing output IDs, missing most
of the output details we already log elsewhere, and simultaneously floods
the server log with all supported mode details which we don't need.If we do want that last part, it should be added to the existing
mir::report::logging: :DisplayConfigu rationReport
instead, where it would apply to all graphics drivers.
Weak disapprove.
I agree that we log similar information elsewhere in startup (and at other times), but I think this information is valuable enough to log. It shows some of the raw hardware state at startup, and associates it with the relevant device node; this is inherently driver-specific.
On a meta level, I think we log roughly an order of magnitude too little information on startup, so I place a low cost on extra once-off startup logging.
Since we don't plan to provide fake modes in our DisplayConfigur ation I'd be happy enough for the supported modes information to be moved to the generic DisplayConfigur ationReport.