Add and use DisplayHotplugConnectModeDetectedAtomReporter, which logs
all valid modes of a hotplugged display.
Change-Id: Ie93487ad8e4936195e3d949ce46034c5ec4fda83
Add DisplayRefreshRatesChangedAtomReporter, which reports the changed
refresh rates of all the active displays managed by drm_hwcomposer.
Change-Id: I03a81c667c44160dc319a899a3bd9a8bc527a382
This change moves some non-trivial implementations out of header
files in drm/. This will enable some includes to be converted to
forward declarations in future changes.
Change-Id: I7b1248657e0fa27e3c0c0157abe4f6b918e13a29
* Android Automotive configurations rely on hardcoded port ids.
These are used on EVS camera configuration and configuring instrument
cluster on secondary display.
* On Pi 5 the reverted commit changed the port ids for HDMI-A-1 and HDMI-A-2
from 0 and 1 to 32 and 33, respectively.
* Doesn't produce stable ids between rpi4 and rpi5 where there are different
number of drm cards and in different order.
* Lets keep running number from 0 for now vs. what 3/5 bit split would
produce on rpi4 and rpi5.
rpi4:
card0 - HDMI-A-1, HDMI-A-2, DSI-0 & DSI-1
000 00000 -> 0
000 00001 -> 1
000 00010 -> 2
000 00011 -> 3
rpi5:
card1 - HDMI-A-1 & HDMI-A-2
001 00000 -> 32
001 00001 -> 33
card2 - DSI-0
010 00000 -> 64
card3 - DSI-1
011 00000 -> 96
* Only revert the relevant part to avoid merge conflicts.
This partially reverts commit 907a51ab1b.
* 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
With the legacy Backend class renamed to CompositionPlanner, rename the
PipelineCreator interface to Backend. This interface maps most closely
to the concept of the "Backend".
Add some documentation to various Backend related classes.
Change-Id: I5d6a7afcebb9d0015c3d7629bf8c10324c8f07df
Rather than global variables with static scope, make them private static
members of their respective classes.
Change-Id: I20f0ad1d63fe14001266058983b0d013058667dc
Backend/CompositionPlanner is now owned by DrmDisplayPipeline. This
class member should have been removed as a part of that refactoring but
was missed.
Change-Id: I9d0c58fff1bd9123ecdf602c846d5b224babbb0d
Allow classes to inherit from GenericPipelineCreator and use it for
creating the DrmDisplayPipeline, but override which CompositionPlanner
is used.
Extract the GetFlattenedComposition function into a static function that
can be called from any backend.
Change-Id: Id75705b969eb6d23fbc6147c496ac3f3e9956abf
Rename the generic CompositionPlanner implementation to
GenericCompositionPlanner, and abstract the CompositionPlanner
interface.
Change-Id: I39d6fd44956d77669271999dd83fc78eebec742a
With the Backend concept expanding to also include the initial display
configuration and creation of DrmDisplayPipeline, rename the Backend
class to more precisely reflect its purpose.
Change-Id: I8a9a0d49242771e5df6e80cd50f0b2b0670c2de2
Define a PipelineCreator interface which allows Backends to use
Backend-specific heuristics in creating the DrmDisplayPipeline.
Change-Id: I1f929213ce403267b539635ec9d5853cf1a7f18a
Additionally, move the creation of the Backend into BackendManager so
that it the Backend is created along with the DrmDisplayPipeline
Change-Id: I24dc19cadb324429f229fe7751b60b70ab512265
Make Backend a member of DrmDisplayPipeline and move the creation of the
Backend to where the DrmDisplayPipeline is created.
Change-Id: Ib7b799df5a2ba16015b7072b0e5ce89a174932c3
Create a Backend for the given DrmDisplayPipeline using the same logic
in CreateBackendForDisplay.
A subsequent change will use this function and deprecate
CreateBackendForDisplay.
Change-Id: I72365f5c689f6643e2f6da11f76dde1ac68f3e2d
Kernel sends Uevents when Content Protection changes its value
from Desired -> Enabled on HDCP enabling or when it changes
from Enabled->Desired on HDCP termination.
This patch updates the content protection property value
on Uevents to capture the change in its state by the kernel.
Change-Id: I7003f0e498f1d1ffa3cbe37406c0b44c5813a3d1
Signed-off-by: Manasi Navare <navaremanasi@google.com>
This change restores behavior where the DrmKmsPlan cached during
ValidateStagedComposition is reused during Present. That behavior
was disabled in a prior change due to a bug where the client
layer could become stale if it were updated between the validate
and present steps, which is now resolved by this change.
Change-Id: Ibca43dc028ece2f4480e5631078ad51320c10582
When all layers are client composited, the GPU may or may not apply the
color transform. If the GPU does apply the CTM, we should clear the HWC
CTM.
Remove duplicate line setting the color matrix.
Change-Id: Ib6a1a48742ee356626ea624b00be5b689323619a
Signed-off-by: Sasha McIntosh <sashamcintosh@google.com>
This adds HDCP state tracking through Client to HwcDisplay
When Client requests HDCP to be enabled for secure layers
Hdcpstate in the corresponding HwcDisplay is set up.
This is parsed to set the Content Protection and HDCP Content Type
properties for the connector in the next commit
Change-Id: I60dd4359ee2f87faba1df83c7faf286b34af43f6
Signed-off-by: Manasi Navare <navaremanasi@google.com>
This CL resolves visual artifacts caused when the DrmKmsPlan is
cached from ValidateDisplay and later used during PresentDisplay.
This change restores prior behavior where the plan is created and
cached during validate, but then recreated fresh during present.
Change-Id: Ifea65946d586c9020143a35455405c5e4c5479e1
The version is being updated downstream so ndk_shared points to v5 which
is not yet upstreamed and breaks the build. Pinning to v4 instead.
Change-Id: I68b26aad6a55bbf58d8c3786c6de1661a04d7484
This change adds fields for counting the total number of layers
and used planes accross compositions.
Change-Id: I7c2593f66f734a4f8ec8ddf7a2f6b5c0c8dc3cc3
This change adds a new CompositionAttributes struct which
tracks information about a given composition as it is
validated and subsequently presented.
Previously CompositionStats were tracked as totals for each
display. This change splits the stats according to the
CompositionAttributes for each presented composition.
This change only affects the reporting behavior of
CompositionStatsTracker. The stats logged by DumpState are
totaled so as to not be affected.
Change-Id: I050cce7f63891971cc807b9c5150d9b5d30f1f0b
Some fields of the CompositionStats struct were only being updated
during validation, meaning that they would not be updated if the
validation step is skipped. This change moves the relevant updates
into presentation to correct some values which were not counted.
Change-Id: Ie537c0b5f6c18eaa71ca1fb2318fca3786d6e097
