commit ee431246ff4c6b7afec4728a2cecad6bf1ce7a2f
author Gil Dekel <gildekel@chromium.org> Tue Jun 07 02:33:38 2022
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Jun 07 02:33:38 2022
tree 74c96313749948086338c8de56b18a8ed1a47bb2
parent e5f6694a1f9beef19686b5595881eabf94564e60

ozone: Display configuration events filtering

[Why]
b/232845611 brought forth an HDMI-to-HDMI HDCP-specifc issue in which,
due to the successive disable/enable of external displays during retry
[1][2], a CHANGE event is generated upon display disablement [3], which
spirals CrOS into an vicious modeset loop.

In essence, what happens is:
1) HDCP Type1 is enabled
2) A 4k@59.98Hz is detected and display configuration begins
3) The preferred mode fails, so retry logic begins
4) The internal display is modeset with the external disabled
5) This causes HDCP to issues a CHANGE event
6) Retry logic finds a working mode and succeeds modeset
7) CrOS receives the HDCP CHANGE event and triggers a display
   configuration
8) GOTO (3)

The resulting behavior is flashing internal + external displays, which
renders the system inoperable.

While this case in itself might be a bit niche due to the fact that it
requires an HDMI-to-HDMI connection while HDCP type 1 is enabled and
have the external display trigger retry logic, there could be a risk of
a more general issue in which other properties will issue CHANGE events
upon property change, or upon display disablement.

[How]
Direct Rendering Manager (DRM) device events include the ID of the
triggering property, if one exists. It is therefore possible to avoid
display configuration events if specific events can be rejected by the
triggering property's name.

This CL introduces a display CHANGE event filtering system that queries
DRM (via a roundtrip to the GPU process) whether or not an event should
be allowed to trigger a full display configuration task using the
devices' list of properties (which includes its path and the triggering
property's ID).

In this case, by blocking CHANGE events triggered by the "Content
Protection" property, we avoid the vicious modeset loop described above.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/3579646
[2] https://chromium-review.googlesource.com/c/chromium/src/+/3635865
[3] http://cs/chromeos_public/src/third_party/kernel/v5.4/drivers/gpu/drm/drm_hdcp.c?l=454

(cherry picked from commit 90fcfc789ce41447ce4e2c6bb2149978e892e0cf)

Bug: b:232845611, b:208756849, b:231627795
Test: ozone_unittest && display_unittest && manual testing on delbin
Change-Id: Ie08ff9f7c5805f4c8b458e9ff449f57f73eaf5bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3675423
Reviewed-by: Daniel Nicoara <dnicoara@chromium.org>
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: Kevin Schoedel <kpschoedel@chromium.org>
Commit-Queue: Gil Dekel <gildekel@chromium.org>
Cr-Original-Commit-Position: refs/heads/main@{#1010374}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3691001
Cr-Commit-Position: refs/branch-heads/5060@{#624}
Cr-Branched-From: b83393d0f4038aeaf67f970a024d8101df7348d1-refs/heads/main@{#1002911}