Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1914343003:
Reland: ash: reset color management when new screens are hotplugged (Closed)
|
Created:
4 years, 7 months ago by llandwerlin-old Modified:
4 years, 7 months ago CC:
chromium-reviews, kalyank, sadrul, piman+watch_chromium.org, ozone-reviews_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionReland: ash: reset color management when new screens are plugged
Reland with fix for platforms that don't support drmModeCrtcSetGamma.
With the DRM drivers on ChromeOS, the color management tables and matrices
are stored at the pipe level (part of the display hardware that is
configurable regardless of the actual connector it is attached to). This
allows display configuration to remain active while different processes are
using the driver (for example switching VT).
As a result, when an external screen is connected to a Chromebook, a given
color configuration might be applied to it and remain stored in the driver
after the screen is disconnected. If another external screen is now
connected the previously applied color management will remain if there is
not a profile for that display.
This change takes care of resetting the color management matrices/tables on
newly connected screen before we apply a new configuration.
BUG=495196, 609256
TEST=Manual testing with hotplugging of a display and identify correct
behavior.
Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c
Cr-Commit-Position: refs/heads/master@{#391491}
Committed: https://crrev.com/7af25197088e372b01dbb1ea7b7793e5c1e404d2
Cr-Commit-Position: refs/heads/master@{#391810}
Patch Set 1 #
Total comments: 3
Patch Set 2 : Rob's review #
Total comments: 7
Patch Set 3 : nits #Patch Set 4 : Add an error when trying to set a gamma table without driver support #
Messages
Total messages: 40 (21 generated)
Description was changed from ========== ash: display: chromeos: reset color management on when new screen are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remained stored in the driver after the screen is disconnected. If another external screen is now connected the applied color management might remain the one of the previous external screen, until the QuirksManager gets the new configuration for it. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG= ========== to ========== ash: display: chromeos: reset color management on when new screen are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remained stored in the driver after the screen is disconnected. If another external screen is now connected the applied color management might remain the one of the previous external screen, until the QuirksManager gets the new configuration for it. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG= ==========
lionel.g.landwerlin@intel.com changed reviewers: + robert.bradford@intel.com
This solution doesn't handle the VCGT based platforms that are in active use. Those would require setting a linear gamma ramp to reset. What about creating a ColorCorrectionData with linear tables and an identity matrix? (or just a linear gamma ramp for the VCGT only case) I guess the problem with doing that is that in ash is that we don't know how big to create the tables. So we'd end up resampling and thus possibly giving banding. Alternatively use the empty vectors like you originally proposed and then map that to a linear table in DrmDevice for the VCGT case. https://codereview.chromium.org/1914343003/diff/1/ash/display/display_color_m... File ash/display/display_color_manager_chromeos.cc (right): https://codereview.chromium.org/1914343003/diff/1/ash/display/display_color_m... ash/display/display_color_manager_chromeos.cc:171: state->display_id(), reset_calibration.degamma_lut, Don't use the ColorCalibrationData to just get three empty vectors. If you want to just have empty vectors just create 3 empty vectors. I need more convincing that using empty vectors is more than a hack here :-) You're also setting this even if the platform doesn't support display color management. https://codereview.chromium.org/1914343003/diff/1/ui/ozone/platform/drm/gpu/d... File ui/ozone/platform/drm/gpu/drm_device.cc (right): https://codereview.chromium.org/1914343003/diff/1/ui/ozone/platform/drm/gpu/d... ui/ozone/platform/drm/gpu/drm_device.cc:740: CreateLutBlob(ResampleLut(degamma_lut, degamma_lut_size)); Is there any way to put this into CreateLutBlob/CreateCTMBlob instead? https://codereview.chromium.org/1914343003/diff/1/ui/ozone/platform/drm/gpu/d... File ui/ozone/platform/drm/gpu/drm_display.cc (right): https://codereview.chromium.org/1914343003/diff/1/ui/ozone/platform/drm/gpu/d... ui/ozone/platform/drm/gpu/drm_display.cc:177: // Use the legacy gamma ramp only if we are given a gamma_lut. // Use the legacy gamma ramp if we are given only a gamma lut.
Thanks! Actually realized that SetGammaRamp can be made private as it's just a corner case of the Drm platform.
Description was changed from ========== ash: display: chromeos: reset color management on when new screen are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remained stored in the driver after the screen is disconnected. If another external screen is now connected the applied color management might remain the one of the previous external screen, until the QuirksManager gets the new configuration for it. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG= ========== to ========== ash: reset color management on when new screen are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196 TEST=Manual testing with hotplugg ==========
Description was changed from ========== ash: reset color management on when new screen are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196 TEST=Manual testing with hotplugg ========== to ========== ash: reset color management on when new screen are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196 TEST=Manual testing with hotplugg ==========
Description was changed from ========== ash: reset color management on when new screen are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196 TEST=Manual testing with hotplugg ========== to ========== ash: reset color management on when new screen are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196 TEST=Manual testing with hotplugging of a display and identify correct behavior. ==========
robert.bradford@intel.com changed reviewers: + oshima@chromium.org, spang@chromium.org
+oshima@ for ash changes +spang@ for ui/ozone changes https://codereview.chromium.org/1914343003/diff/20001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/drm_device.cc (right): https://codereview.chromium.org/1914343003/diff/20001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/drm_device.cc:699: gamma_size = lut.size(); Please change this to just return false if we have a gamma ramp mismatch. https://codereview.chromium.org/1914343003/diff/20001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/drm_device.cc:707: if (lut.empty()) { // Create a linear gamma ramp table to deactivate the feature.
https://codereview.chromium.org/1914343003/diff/20001/ash/display/display_col... File ash/display/display_color_manager_chromeos.cc (right): https://codereview.chromium.org/1914343003/diff/20001/ash/display/display_col... ash/display/display_color_manager_chromeos.cc:170: std::vector<ui::GammaRampRGBEntry>(), std::vector<float>()); Since DisplayConfigurator calls OndisplayModeChanged, isn't it better for DisplayConfigurator to reset this before calling this?
lgtm
Description was changed from ========== ash: reset color management on when new screen are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196 TEST=Manual testing with hotplugging of a display and identify correct behavior. ========== to ========== ash: reset color management when new screens are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196 TEST=Manual testing with hotplugging of a display and identify correct behavior. ==========
https://codereview.chromium.org/1914343003/diff/20001/ash/display/display_col... File ash/display/display_color_manager_chromeos.cc (right): https://codereview.chromium.org/1914343003/diff/20001/ash/display/display_col... ash/display/display_color_manager_chromeos.cc:170: std::vector<ui::GammaRampRGBEntry>(), std::vector<float>()); On 2016/04/27 19:37:44, oshima wrote: > Since DisplayConfigurator calls OndisplayModeChanged, isn't it better for > DisplayConfigurator to reset this before calling this? It seems DisplayConfigurator doesn't make any decision on the color correction, it just forwards requests from callers. Would you prefer this be in DisplayConfigurator? https://codereview.chromium.org/1914343003/diff/20001/ui/ozone/platform/drm/g... File ui/ozone/platform/drm/gpu/drm_device.cc (right): https://codereview.chromium.org/1914343003/diff/20001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/drm_device.cc:699: gamma_size = lut.size(); On 2016/04/27 18:58:42, robert.bradford wrote: > Please change this to just return false if we have a gamma ramp mismatch. Done. https://codereview.chromium.org/1914343003/diff/20001/ui/ozone/platform/drm/g... ui/ozone/platform/drm/gpu/drm_device.cc:707: if (lut.empty()) { On 2016/04/27 18:58:42, robert.bradford wrote: > // Create a linear gamma ramp table to deactivate the feature. Done.
https://codereview.chromium.org/1914343003/diff/20001/ash/display/display_col... File ash/display/display_color_manager_chromeos.cc (right): https://codereview.chromium.org/1914343003/diff/20001/ash/display/display_col... ash/display/display_color_manager_chromeos.cc:170: std::vector<ui::GammaRampRGBEntry>(), std::vector<float>()); On 2016/04/28 10:41:52, llandwerlin wrote: > On 2016/04/27 19:37:44, oshima wrote: > > Since DisplayConfigurator calls OndisplayModeChanged, isn't it better for > > DisplayConfigurator to reset this before calling this? > > It seems DisplayConfigurator doesn't make any decision on the color correction, > it just forwards requests from callers. > Would you prefer this be in DisplayConfigurator? Hm, that probably makes sense. lgtm
The CQ bit was checked by lionel.g.landwerlin@intel.com
The patchset sent to the CQ was uploaded after l-g-t-m from spang@chromium.org Link to the patchset: https://codereview.chromium.org/1914343003/#ps30009 (title: "nits")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1914343003/30009 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1914343003/30009
Message was sent while issue was closed.
Committed patchset #3 (id:30009)
Message was sent while issue was closed.
Description was changed from ========== ash: reset color management when new screens are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196 TEST=Manual testing with hotplugging of a display and identify correct behavior. ========== to ========== ash: reset color management when new screens are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} ==========
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491}
Message was sent while issue was closed.
A revert of this CL (patchset #3 id:30009) has been created in https://codereview.chromium.org/1945353004/ by lionel.g.landwerlin@intel.com. The reason for reverting is: This is causing issues on ARM/exynos5420-peach-pit Chromebook. Let's revert this for now as I don't have a device to investigate. BUG=609256.
Message was sent while issue was closed.
Description was changed from ========== ash: reset color management when new screens are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} ========== to ========== Reland: ash: reset color management when new screens are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196,609256 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} ==========
Message was sent while issue was closed.
Description was changed from ========== Reland: ash: reset color management when new screens are plugged With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196,609256 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} ========== to ========== Reland: ash: reset color management when new screens are plugged Reland with fix for platforms that don't support drmModeCrtcSetGamma. With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196,609256 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} ==========
Message was sent while issue was closed.
Description was changed from ========== Reland: ash: reset color management when new screens are plugged Reland with fix for platforms that don't support drmModeCrtcSetGamma. With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196,609256 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} ========== to ========== Reland: ash: reset color management when new screens are plugged Reland with fix for platforms that don't support drmModeCrtcSetGamma. With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196,609256 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} ==========
Patchset #4 (id:50001) has been deleted
reland lgtm.
The CQ bit was checked by lionel.g.landwerlin@intel.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1914343003/70001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1914343003/70001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Patchset #4 (id:70001) has been deleted
The CQ bit was checked by lionel.g.landwerlin@intel.com
The patchset sent to the CQ was uploaded after l-g-t-m from oshima@chromium.org, spang@chromium.org, robert.bradford@intel.com Link to the patchset: https://codereview.chromium.org/1914343003/#ps90001 (title: "Add an error when trying to set a gamma table without driver support")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1914343003/90001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1914343003/90001
Message was sent while issue was closed.
Description was changed from ========== Reland: ash: reset color management when new screens are plugged Reland with fix for platforms that don't support drmModeCrtcSetGamma. With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196,609256 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} ========== to ========== Reland: ash: reset color management when new screens are plugged Reland with fix for platforms that don't support drmModeCrtcSetGamma. With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196,609256 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} ==========
Message was sent while issue was closed.
Committed patchset #4 (id:90001)
Message was sent while issue was closed.
Description was changed from ========== Reland: ash: reset color management when new screens are plugged Reland with fix for platforms that don't support drmModeCrtcSetGamma. With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196,609256 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} ========== to ========== Reland: ash: reset color management when new screens are plugged Reland with fix for platforms that don't support drmModeCrtcSetGamma. With the DRM drivers on ChromeOS, the color management tables and matrices are stored at the pipe level (part of the display hardware that is configurable regardless of the actual connector it is attached to). This allows display configuration to remain active while different processes are using the driver (for example switching VT). As a result, when an external screen is connected to a Chromebook, a given color configuration might be applied to it and remain stored in the driver after the screen is disconnected. If another external screen is now connected the previously applied color management will remain if there is not a profile for that display. This change takes care of resetting the color management matrices/tables on newly connected screen before we apply a new configuration. BUG=495196,609256 TEST=Manual testing with hotplugging of a display and identify correct behavior. Committed: https://crrev.com/5932a0131851f35b74be5d2fc86a3834defd4d8c Cr-Commit-Position: refs/heads/master@{#391491} Committed: https://crrev.com/7af25197088e372b01dbb1ea7b7793e5c1e404d2 Cr-Commit-Position: refs/heads/master@{#391810} ==========
Message was sent while issue was closed.
Patchset 4 (id:??) landed as https://crrev.com/7af25197088e372b01dbb1ea7b7793e5c1e404d2 Cr-Commit-Position: refs/heads/master@{#391810} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
