tree cb25cc6537424661b03473469608760abc3e82a5
parent 0ee8f58b93a037c5a54bb0a05c12228845a70a76
author Roman Stratiienko <roman.o.stratiienko@globallogic.com> 1637079798 +0200
committer Roman Stratiienko <roman.o.stratiienko@globallogic.com> 1638448508 +0200

drm_hwcomposer: Rework display modes handling

Android likes to adapt display output frequency to match window context
frequency. Unfortunately platform code has some limitations, therefore
hwcomposer HAL should be careful with reporting supported display modes.

Known platform limitations:
1: Framework doesn't distinguish between interlaced/progressive modes.
2. Framework will not switch display frequency in case margin in FPS rate
   is very small (<1FPS or so). Not a big issue, but that is causing
   some CTS tests to fail.

In addition to that VRR technology (or seamless mode switching) require
hwcomposer to group modes which tells the framework that seamless mode
configuration change is supported within a group of display modes.

By this commit do the following:
1. Group modes by the resolution:
   E.g.

    Group 1:
    1024x768i@60
    1024x768i@90
    1024x768@50
    1024x768@50.1

    Group 2:
    1920x1080@60
    1920x1080@24.3
    1920x1080i@60
    1920x1080i@120

2. Disable modes in a way that each group keeps only interlaced or proressive
   modes enabled. In case KMS reported preferred mode is interlaced - prefer
   interlaced for the whole group, otherwise prefer progressive.

3. Disable mode in case different mode in the same group has similar frequency
   with delta less than 1FPS.

4. Report only modes which remain enabled to the framework.

Test: atest CtsGraphicsTestCases

Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>