* Display resolution and refresh rate can be forced using a property.
Other modes reported as supported by the display are ignored when forcing
a specific mode.
* Force resolution and refresh rate for headless mode as well.
This is based on following 4 commits with further updates.
Author: Chih-Wei Huang <cwhuang@linux.org.tw>
Date: Wed Sep 19 22:57:32 2018 +0800
drm_hwcomposer: allow to force mode by a property
The desired resolution could be set by property debug.drm.mode.force.
The other modes are ignored.
Author: Konsta <konsta09@gmail.com>
Date: Sun Dec 5 15:40:40 2021 +0200
drm_hwcomposer: use first refresh rate reported by the display
* Android can switch between different refresh rates which
can lead to display changing modes in some cases.
* Use the first refresh rate reported by the display when
forcing the resolution unless specified otherwise.
Author: Konsta <konsta09@gmail.com>
Date: Tue Jan 25 17:46:33 2022 +0200
drm_hwcomposer: Default to 1920x1080 resolution for headless mode
Author: Konsta <konsta09@gmail.com>
Date: Tue Feb 1 17:40:43 2022 +0200
drm_hwcomposer: Allow setting resolution for headless mode
GetDisplayConfigurations_hasHdrType fails for headless displays since
the hdrOutputType is not initialized for fake modes. Set fake modes to
kSystem instead of kInvalid.
Change-Id: I051dc742b4786bbb0bf8a9384a6d3cde536eebce
Configuration groups for the Multiple Refresh Rate (MRR) feature support
is currently disabled in DRM HWComposer. This is because it is
insufficient to group modes solely based on their active region size.
The primary reasons for this insufficiency are:
1. drm-hwc clients may assume they can seamlessly switch between
configurations within the same group to support variable refresh
rates.
2. Not all System-on-a-Chip (SoC) architectures support seamless mode
transitions.
3. For SoCs that do support seamless switching, transitions often depend
on other hardware-specific properties like matching blanking periods.
4. A fallback to a non-seamless (blocking) modeset is unacceptable for
internal displays if a seamless transition fails, as this causes
flickering. The current framework does not handle such failures
gracefully.
To Resolve these challenges and re-enable seamless Multiple Refresh-Rate
transitions on internal panels, we add logic to validate all configs
against the preferred initial active config. This validation preforms a
seamless modeset test on each available config against the config that
was set during the display initialization. Configs that fail the
screening are assigned new group IDs.
Caveats:
1. Currently, this is only implemented for internal panels. External
display seamless transition between variable refresh rates is not
support. However this work can be extended to support seamless
transitions on external displays as well.
2. Grouping is only preformed for the preffered/active config at the
time of display init, and is valid only for the duration of the
current full modeset commit. No other groups are not created (since
they cannot be validated), and any new full commits will not honor
the guarantee provided by the check. This work can be extended to
refresh and validate all configs within the same group ID of any
incoming full modeset commit.
Change-Id: Ie2661e74bd3ff704b40c8c7ef50c56e604e5e8df
Signed-off-by: Gil Dekel <gildekel@google.com>
