Loading
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