Provide dimming ratio instead of white point nits in composer
There are several reasons for limiting the notion of white point nits in
the composer interface:
1. Some KMS apis exposed by drivers only expose a notion of a per-plane
brightness. While these are non-mobile drivers, e.g., nouveau, this
does indicate that white point is not directly going to be understood
by typical hardware
2. Changing the brightness without requiring a frame update introduces
implicit state in composer. If the brightness and white point nits
for a set of SDR layers are 200 nits, and the brightness changes to
205 nits to respond to ambient conditions, then composer must not dim
the layers, and in fact DisplayManager will tell SurfaceFlinger that
the SDR white point will be 205 nits. But SurfaceFlinger will not
tell composer that the SDR white point changed as that would
otherwise introduce a re-composition cycle, meaning that
HW Composer must track somehow that the layer white point changed
without a corresponding change on the layer data structure, which is
confusing.
3. It's poorly defined what the dimming ratio should be if
SurfaceFlinger provides the following inputs: Layer A has a white
point of 200 nits, Layer B has a white point of 400 nits, and display
brightness is 300 nits. Current implementations may clamp the
brightness of Layer B to be 300 nits and dim layer A by 2/3s, but
there is an equally valid interpretation which is just dim Layer A to
be 50% of Layer B's brightness.
4. The problem indicated by (2) and (3) suggests that layer white point is
really an up-stack concept, that SurfaceFlinger can be aware of for
properly computing the dimming ratios it can send to composer, but
the composer hal shouldn't really be speaking in terms of nits.
Note that this patch does not yet change the interface for
ClientTargetWithNits, which may be done in a follow-up patch.
Bug: 217961164
Test: builds, boots
Change-Id: I4a1b4e8c300d22599a5683bd44b7b8afa9a29425
10 files changed