* It has been reported that HDR is not working properly on Raspberry Pi
with HDMI displays that support it.
Change-Id: I31f9d7bb5a3f81eeca1f98a72c26786d97edc28d
* 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
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>
Move the implementations for properties related functions on non-Android
platforms into properties.cpp
Change-Id: I91fce6a618445ea3021ef1013228285c99d819bd
Add Properties::GetBackendOverride to query the sysprop, and handle the
default in BackendManager.
Change-Id: Ifc01a23d64a5406ba5c9f065b7d5967b42b1b5d5
We add build property vendor.hwc.drm.internal_display_names to contain
displays we want to make INTERNAL, while check the property in
GetDisplayConnectionType.
If the property is set, we decide INTERNAL/EXTERNAL based on the
included displays.
Currently it's specific for CF/desktop usage.
Change-Id: I3d607b6646ac47497b9770966d4e880f5e5c0ca6
Signed-off-by: Linjiao Zhao <ruki@google.com>
When config groups are enabled, the framework uses the Multiple Refresh
Rate feature, which causes blank screen issues on some devices, making
them unusable.
This is a temporary solution until we find a reliable way to query the
driver if a seamless mode change is supported.
Discussion can be found [here][1]
[1]: https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/merge_requests/295#note_2770300
Change-Id: If17c29de9f2cd853887ece5fe050e4ceee5ddb65
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
To clean things up and unify the usage of properties.
Change-Id: I0e034ed309f5f8a0d4fc9be7a4a3edcb39050e7f
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Android framework will change between configs in the same config group
dynamically, to support the Multiple refresh rate [1] feature. If the
display driver does not support changing modes seamlessly, there will be
visible artifacts (blank screen) when changing refresh rates.
Add a property to disable config grouping on devices that do not support
seamless mode changes. Set the default value to enable config grouping.
[1] https://source.android.com/docs/core/graphics/multiple-refresh-rate
Change-Id: Iec5927ea3af063669f6f7b7aa430e541c1c35428
Signed-off-by: Drew Davenport <ddavenport@google.com>
Check the "Present Not Reliable" property to determine if the capability
PRESENT_FENCE_IS_NOT_RELIABLE should be enabled or not.
The virtio gpu module sends frames to the host as fast as possible and
does not emulate "real display timing". Devices using the virtio gpu
module (for example, the virtual Android device Cuttlefish) should set
the following property to "true" to enable the capability:
ro.vendor.hwc.drm.present_not_reliable.enabled
For example, in an Android BoardConfig.mk:
PRODUCT_VENDOR_PROPERTIES += \
vendor.hwc.drm.present_not_reliable.enabled=true
Signed-off-by: Tim Van Patten <timvp@google.com>
