| Age | Commit message (Collapse) | Author |
|---|
|
performance"
This reverts commit bac7071aa3b1ae72f90b904b9af61b5c74ba9265.
Reason for revert: Droidmonitor created revert due to Jank regression b/404073995.
Change-Id: Id57f5cda7a34f4598a82d86d7290d5b1c57f1315
|
|
* This CL explicitly sets synthetic VSYNC state based on the new power state. Before, the synthetic VSYNC state was assumed based on the previous power state and in some cases was not set explicitly.
* The previous behaviour of enabling synthetic VSYNC if the only display is DOZE_SUSPEND is preserved.
* This also fixes a hypothetical gap where it would not optimise for performance if there were a display that needed it, while the primary display was DOZE_SUSPEND.
Bug: 342681202
Bug: 241285876
Flag: android.companion.virtualdevice.flags.correct_virtual_display_power_state
Test: manually tested with flag on/off using Android Auto Projected
Change-Id: I181aefad586ad7b1732c837b67a01d61939d1d3e
|
|
Work towards DisplayId opaqueness by eliminating call-sites to APIs that
parse the display ID values directly.
This CL removes *DisplayId::tryCast from the DislayId interface entirely
and replaces it with SF APIs that check for the existence of the
displays before casting. This removes direct dependency on ID value
bits. It also removes DisplayId::isVirtual().
Flag: com.android.graphics.surfaceflinger.flags.stable_edid_ids
Bug: 390690584
Bug: 390689313
Test: libsurfaceflinger_unittest
Change-Id: I918a6b361784e41165837234b82eed027dc46673
|
|
If the state changes while there's no surface, the new power state is lost. Even though there's no DisplayDevice, there's a proper DisplayDeviceState for that virtual display. Storing the power state there and respecting it when creating the display will work.
This is tied to android::companion::virtualdevice::flags::correct_virtual_display_power_state since that flag controls whether or not to set the power mode of the SurfaceControl for the virtual display (which ultimately feeds into SurfaceFlinger::setPowerMode).
With this change, virtual displays whose PowerMode is OFF will no longer be composited since the correct power mode is now set in SurfaceFlinger (instead of assuming all virtual displays are ON).
Bug: 342681202
Flag: android.companion.virtualdevice.flags.correct_virtual_display_power_state
Test: manually tested with flag on/off with Android Auto Projected
Change-Id: Ib10514da05e277a8ed574c92ff71d2a4d52975b2
|
|
DisplayManager's never-blank concept is translated in VirtualDisplayAdapter to be a power-optimised display (instead of a performance optimised display) in the downstream components. This concept indicates that these displays typically depend on another display's presence and activeness to be continually rendered and shown. The display they depend on instead optimises for performance when it is on, meaning that all the related displays have good performance.
For cases where power optimisation information is not available (calls to DisplayControl#createVirtualDisplay(String, boolean) and SurfaceComposerClient::createVirtualDisplay), the power optimisation state is defaulted to optimise for power since these are system calls and this preserves the previous behaviour.
Bug: 342681202
Flag: EXEMPT refactor
Test: Flashed build on test device, ran Android Auto Projected
Change-Id: I6a9fdf7c4be080e2f4df6734def8a4fbefde5742
|
|
The goal of this change is to synchronize resolution switching across SF
and DM. The lack of synchronization causes glitches, which are currently
papered over in HWC by dropping frames whose size don't match the active
resolution.
A mode set involving a resolution switch was finalized by destroying the
DisplayDevice and thus its HWC layers. Remove this special case in favor
of letting DM call SurfaceControl.setDisplaySize right after requesting
the mode set via setDesiredDisplayModeSpecs.
Emit a mode change event to DM as soon as the DisplayModeRequest becomes
the desired mode. In response, DM sends the transaction that resizes the
display via setDisplaySize, so wait until that commit before modesetting
to the new resolution, and resize the framebuffer in that same frame.
Display projection depends on display size, so update the latter first
when committing DisplayDeviceState.
Fixes: 355427258
Flag: com.android.graphics.surfaceflinger.flags.synced_resolution_switch
Test: Internal (caiman) and external displays, with different rotations.
Test: Inner display (comet) with install orientation.
Change-Id: Ifaf300f3b5f907f7cd10b8db2aa6165ad2106530
|
|
This CL is submitted behind a flag and in still in development.
The flag should not be enabled just yet.
Test: manual
Bug: 331636736
Flag: com.android.graphics.surfaceflinger.flags.no_vsyncs_on_screen_off
Change-Id: Iec9cde3bafb9c112c9ce9beebe6dded4727fc99c
|
|
Inline the use in Layer::onCompositionPresented and rewire dumpsys uses.
Bug: 355424160
Flag: EXEMPT refactor
Test: adb shell dumpsys SurfaceFlinger --scheduler
Change-Id: I32f61d16a8bb3045d756a612f7c20ecb3c628771
|
|
When idle timer times out on VRR, change the refresh rate
indicator to show "- -". The render rate doesn't cange as a result
of idleness.
Bug: 333443503
Test: manual
Flag: EXEMPT bugfix
Change-Id: Ie4f51a2a9da1a5e229b3504881117b12f1fd1b6a
|
|
Create a SF specific macro to call into atrace. This will make the
switch to perfetto for capturing atrace tags easier.
Flag: EXEMPT refactor
Bug: 349905670
Test: perfetto
Change-Id: I4d046d837f52ef78b08e3c97556f2eddb06232dd
|
|
Move the per-display state machine for modesetting from DisplayDevice to
DMC. In lieu of mStateLock, protect display lookup from multiple threads
using a mutex internal to DMC, which fixes the following deadlock:
OneShotTimer::loop
SF::requestDisplayModes
mStateLock
SF::commit
mStateLock
SF::processDisplayChangesLocked (hotplug or resolution change)
Scheduler::demotePacesetterDisplay
OneShotTimer::stop
A notable change is that {initiate,finalize}DisplayModeChange(s) are no
longer called under mStateLock, thanks to DMC's granular, internal lock.
finalizeDisplayModeChange still locks mStateLock for resolution changes.
Add an ActiveModeListener to DMC and register a callback in SF to update
the refresh rate overlay, which still lives in DisplayDevice for now.
Fixes: 329450361
Bug: 241285876
Test: DisplayModeControllerTest
Test: libsurfaceflinger_unittest
Change-Id: I30ec756f134d2d67a70ac8797008dc792eac035e
|
|
When VRR device does not support refresh rate debug indicator callback
Use the render rate as the refresh rate on the indicator.
Test: Manually tested refresh rate indicator on device that supports the
callback and device that doesn't
BUG: 326137213
Change-Id: Ifd0d34909b831991d4525f2b5138e71e4a76c4d6
|
|
With MRR devices, vsyncRate and refreshRate are the same thing, but
this is not true for dVRR devices.
Test: manually test refresh rate indicator
Change-Id: I0946ad4164257b1919035a0db1080ec06ba1ed53
|
|
Currently, we use int32_t for displayId, which is not a safe type, and
it may also lead to misdefinition of types. Here, we introduce
LogicalDisplayId as a strong type for displayId and move all contents
of constants.h into LogicalDisplayId.h.
Bug: 339106983
Test: atest inputflinger_tests
Test: atest InputTests
Test: m checkinput
Test: m libsurfaceflinger_unittest
Test: presubmit
Change-Id: If44e56f69553d095af5adb59b595e4a852ab32ce
Signed-off-by: Linnan Li <lilinnan@xiaomi.corp-partner.google.com>
|
|
When we change display mode we schedule the next frame
at a new peakRefresh rate
Test: verify render rate is not switched to 240 in the trace
BUG: 308858993
Change-Id: I1bfb97d5d4eac6f51a306c108d03a5bc4410baae
|
|
Trace/log the display ID, and print the DisplayModeRequest.
Remove a superfluous run-time assertion about display ID mismatch, as it
cannot happen, which I5a74d58b3feb3a71fc3d85393a509af86f1b0274 will make
clearer.
Fixes: 318533819
Test: Perfetto and logcat
Change-Id: I77defbcf9b1e3c4332838586f60c125a13e2978c
|
|
Rebased and modified from Iec154c488ef7af9b8e1d6386509e97c9ce85103b,
patch set 3. Does not include
I688b0c922747a80e881965a1dc243d11ba2c7438, which was reverted.
DM currently always picks 1080p@60 for an external display. More work
(tracked in b/318534874) needs to be done in SF in order to use that
mode initially. In the meantime, have SF pick the same mode on hotplug
so that it avoids extra mode switches.
Move "force" into DisplayModeRequest. If a request is already pending
this allows forcing the final request if a pending request forced it,
even if the new request does not. This matches how emitEvent is handled.
If a DisplayModeRequest is forced, don't early exit in
initiateDisplayModeChanges, which does not honor "force".
When loading display modes for an external display, look for 1080p@60
and treat it as the active mode. If the display does not have 1080p@60,
pick the mode closest to (but not exceeding) 1080p@60. DM will pick an
appropriate mode later. When adding that display, apply that active mode
so it will be used by SF.
Fixes: 305813445
Test: libsurfaceflinger_unittest
Test: YouTube is not frozen or choppy on external display hotplug.
Test: Remove the option of 1080p@60 and connect.
Change-Id: Ibb15df1c2c0ab162c11895219d8f4bb749c474a1
|
|
This reverts commit f091fe5a29ee55a1c53f2f09b8cca0306e7cfd91.
Reason for revert: b/323907059
Fixes: 323907059
Test: presubmit
Change-Id: Ic857349d7c3dbe2cfda8bfd5f6a695eb845c1d93
|
|
Rebased and modified from Iec154c488ef7af9b8e1d6386509e97c9ce85103b,
patch set 3. Does not include
I688b0c922747a80e881965a1dc243d11ba2c7438, which was reverted.
DM currently always picks 1080p@60 for an external display. More work
(tracked in b/318534874) needs to be done in SF in order to use that
mode initially. In the meantime, have SF pick the same mode on hotplug
so that it avoids extra mode switches.
Move "force" into DisplayModeRequest. If a request is already pending
this allows forcing the final request if a pending request forced it,
even if the new request does not. This matches how emitEvent is handled.
If a DisplayModeRequest is forced, don't early exit in
initiateDisplayModeChanges, which does not honor "force".
When loading display modes for an external display, look for 1080p@60
and treat it as the active mode. If the display does not have 1080p@60,
pick the mode closest to (but not exceeding) 1080p@60. DM will pick an
appropriate mode later. When adding that display, apply that active mode
so it will be used by SF.
Fixes: 305813445
Test: libsurfaceflinger_unittest
Test: YouTube is not frozen or choppy on external display hotplug.
Test: Remove the option of 1080p@60 and connect.
Change-Id: I6864d88b327e0f207947b44ce14b97f323170714
|
|
HWC errors were being converted to a status_t of NO_ERROR.
Bug: 241285876
Test: presubmit
Change-Id: I0fcfa426c795adf55a920729bc613a0cd140e87c
|
|
|
|
Generalize SF::initializeDisplays (called on boot and restart) to:
- Apply the transaction that clears DisplayState to all displays.
- Power on all displays.
The first change removes a special case for the primary display, setting
the stage for multi-display boot animation. Each display is assigned its
own LayerStack, and set up with a projection to its active resolution.
The second change fixes a bug where DisplayCapability::BRIGHTNESS was
not detected for secondary displays present during boot. SF queries
capabilities when a display is first powered on, but DM asks SF about
brightness when the display is hotplugged, regardless of power mode.
The general fix (covering external displays) is for DM to defer its
query, but this stopgap covers internal displays.
Revert I3a2eae4efc4a5c6113700a9ca9e9b261e364a878, which let the initial
power mode be std::nullopt. This effectively forced DM's first request
to setPowerMode(<rear display>, OFF), which would otherwise be ignored
because OFF had been the default power mode on DisplayDevice creation.
However, that special case confusingly took the same branch as the OFF
to ON transition, and is no longer needed now that all displays are ON
(from SF's perspective, not just HWC's) until the boot animation ends.
Fixes: 267633741
Fixes: 150889228
Bug: 269510347
Test: Boot unfolded and folded.
Test: Induce system_server crash.
Test: InitializeDisplaysTest.initializesDisplays
Change-Id: I5277a629f39b3b285452aa84d49ff84e3dc957ca
|
|
This reverts commit fb078ab329818c116104f61e7c67c3b2ae9a8152.
Reason for revert: b/320901698
Bug: 320901698
Change-Id: Ia714380dade4f2eeb5d369713405f33d548b6e40
|
|
Rebased and modified from Iec154c488ef7af9b8e1d6386509e97c9ce85103b,
patch set 3. Does not include
I688b0c922747a80e881965a1dc243d11ba2c7438, which was reverted.
DM currently always picks 1080p@60 for an external display. More work
(tracked in b/318534874) needs to be done in SF in order to use that
mode initially. In the meantime, have SF pick the same mode on hotplug
so that it avoids extra mode switches.
Move "force" into DisplayModeRequest. If a request is already pending
this allows forcing the final request if a pending request forced it,
even if the new request does not. This matches how emitEvent is handled.
If a DisplayModeRequest is forced, don't early exit in
initiateDisplayModeChanges, which does not honor "force".
When loading display modes for an external display, look for 1080p@60
and treat it as the active mode. If the display does not have 1080p@60,
pick a 60hz mode (if available) closest to 1080p. DM will pick an
appropriate mode later. When adding that display, apply that active mode
so it will be used by SF.
Fixes: 305813445
Test: libsurfaceflinger_unittest
Test: YouTube is not frozen or choppy on external display hotplug.
Test: Remove the option of 1080p@60 and connect.
Change-Id: Idd48fbb0aab1b500a1a074ce0984c0a253a865c0
|
|
|
|
This reverts commit aaab4c3b4f012f48bca428b9db1cd954a6fbc8e9.
Reason for revert: b/317378302
Change-Id: I516f52c41d27d9ea3eca969a3f786d2115521dac
|
|
|
|
The motivation is to:
- Avoid redundant state that can cause data races if stale.
- Consolidate control flow for resolution and refresh rate changes.
- Clarify the desired/pending/active states of the per-display FSM.
The notable changes are:
Consume the desired DisplayModeRequestOpt via either SF::dropModeRequest
or DisplayDevice::initiateModeChange.
Pull the details of SF::finalizeDisplayModeChange into DisplayDevice::
finalizeModeChange, which now returns whether there was NoModeChange,
a ResolutionChange, or a RefreshRateChange. Consume the pending request.
Now that DisplayDevice does not retain the desired DisplayModeRequest,
applyActiveMode as soon as finalizeDisplayModeChange ends, rather than
at a later point in the commit, when initiateDisplayModeChanges checks
whether the active and desired modes are the same.
Now that applyActiveMode happens in finalizeDisplayModeChange, remove
the special case when there is a displayToUpdateImmediately.
Bug: 305813445
Bug: 255635711
Bug: 241285876
Test: ALOGV of mode setting for inner/outer displays
Test: InitiateModeChangeTest, DisplayModeSwitchingTest
Change-Id: I688b0c922747a80e881965a1dc243d11ba2c7438
|
|
So the secure flag of Display object in Display Manager (DM) can
be set correctly. HWC calls the onSync method as a workaround,
to notify SurfaceFlinger (SF) about hdcp changes, SF in turn sends
an event to DM, DM will then fetch and update display info.
Bug: 280818362
Test: manual
Change-Id: I29ce0337865b51c0fc7bf7c2d7fdd4cd6d66ef46
|
|
Allow outputs to decide if they want to render protected content, not
just if they support it. The current code checks if the Output is secure
when deciding whether to render protected content. By adding a new flag,
it will allow displays to decide if they want to render secure,
protected, or both.
This code doesn't have a way to create displays with only protected and
will still rely on the isSecure flag to ensure backwards compatibility.
Test: presubmit
Fixes: 285553970
Fixes: 300492271
Change-Id: If5e65388825d37f4ddaea5190259a136cfa89264
|
|
This type is redundant with DisplayModeRequest, so store the desired and
pending modes as DisplayModeRequestOpt. This is a step toward flowing
the request through one of desired/pending/active states.
Use the std::nullopt state of the desired mode instead of relying on the
implicitly associated TracedOrdinal<bool>.
Bug: 241285876
Test: presubmit
Change-Id: Ie12a5ad420745761c73b1ce2c536862f79a50665
|
|
Trace the pending mode after successfully setting it on HWC.
Remove unused status_t return value, and redundant warning log. Disallow
nullptr for out parameter.
Bug: 255635711
Test: presubmit
Change-Id: I381e5528d6336c300a80abcebccdd76369126c04
|
|
Rename {Desired,Upcoming}ActiveMode to {Desired,Pending}Mode for clarity
that the FSM is in one of desired/pending/active states.
Rename clearDesiredActiveModeState to dropModeRequest, as its purpose is
to undo the effect of a DisplayModeRequest, regardless of FSM state.
Rename desiredActiveModeChangeDone to applyActiveMode, as it pertains to
applying the DisplayModeRequest that has become active to the Scheduler.
This function will later be moved from SF to Scheduler.
Bug: 255635711
Test: presubmit
Change-Id: Ie7fd9a353e38325d7b8dfd1d1143c7d52e5ad58e
|
|
Bug: 241285876
Test: Perfetto
Change-Id: Ibe39de0f144066be8c6111915d9c1394565ec541
|
|
Bug: 302312658
Test: presubmit + manual
Change-Id: I3a69e4520be7f52779e1f92e5621a6138de08797
|
|
refresh rate indicator
Test: manual
BUG: 284845445
Change-Id: I30c34f1363bd7b3a21741c6b3ee70b67b1938fc0
|
|
Update to incorporate display refresh rate on
DisplayMode
With the addition of VRR, vsync period
does not necessarily represent the
refresh rate of the display, having a
peakRefreshRate that represents the
display peak refresh rate helps with
separating the concern of vsync period
being different from the peak refresh rate
supported by the device.
Test: atest libsurfaceflinger_unittest
BUG: 286048920
BUG: 284845445
Change-Id: I9d90e4def4cf3efcd5a696a4ec43fbf7698abfe4
|
|
setActiveMode updates the refresh rate on the overlay
when changes the refresh rate not caused by the HWC callback,
updating overlay directly created the race condition for the updates.
Updates the order to enable the overlay first and
then making the call to HWC to enableRefreshRateCallbackDebugEnabled
BUG: 279544150
Test: manual test
Change-Id: I42eed19242944479e5f9e6edf10565417f358a73
|
|
Desired modes were only propagated to HWC for the "active" display, i.e.
generally the primary display and specially the rear display when in the
folded state. In other words, mode setting did not happen for external
displays, and the rear display when driving both displays concurrently.
Store per-display state for whether a mode set is pending. Propagate the
desired mode for both internal and external displays as long as they are
powered on.
Fixes: 277776378
Fixes: 289182528
Bug: 255635711
Bug: 255635821
Test: The 60 Hz constraint applies to both displays in concurrent mode.
Test: ADB `set-user-preferred-display-mode` applies to external display.
Test: DisplayModeSwitchingTest#inner{Xor,And}OuterDisplay
Test: DisplayModeSwitchingTest#powerOffDuringModeSet
Change-Id: I9da3a0be07f9fbb08f11485aa6ab9400259a4e09
|
|
- follow how RefreshRateOverlay did in general.
- 1043 as new opcode to enable hdr/sdr ratio overlay.
- decouple SevenSegmentDrawer and SurfaceControlHandle helper classes
from RefreshRateOverlay.
- add corresponding SF backdoor test for validation.
- for non-HDR-supported device, we don't reject them to use SF backdoor
but 1.00 will be always shown on the screen if enabling.
Test: adb shell call service call SurfaceFlinger 1043 1; atest
SurfaceFlinger_test
Bug: 277957056
Change-Id: Ifce2d435f127b53ab9d01aba4e24ffd4fdb010a7
|
|
Revert submission 23423266-SF-Config
Reason for revert: UIBench Jank Regression reported in b/288665387
Reverted changes: /q/submissionid:23423266-SF-Config
Change-Id: I0942f99fec1f211e607e3ff44da2dfa0e30d34c2
|
|
This pulls out all the individual configuration constants read by
SurfaceFlinger in its constructor, and moves them to a new
surfaceflinger::Config structure which is passed to the constructor.
All the initialization is the functionally the same, a few values turned
out to not be used, so were removed (mMaxGraphicBufferProducerListSize,
mGraphicBufferProducerListSizeLogThreshold). Otherwise all properties
read for the new structure consistently use android-base/properties.h to
read them.
To keep the argument count down, the SurfaceFlinger factory argument to
the constructor was moved to be stored in the new Config structure.
As a result of the change, SurfaceFlinger now only has one constructor.
The tests were using the other constructor (passing
SurfaceFlinger::skipInitiailization) to skip over the property reads to
help ensure a hermetic configuration of SurfaceFlinger. The tests can
now instead create create a minimally configured Config structure, and
pass that the structure.
The other changes were then to switch over to using the values in the
Config structure, both internally to SurfaceFlinger, as well as in other
files including Layer.cpp and DisplayDevice.cpp. In some cases, those
changes required altering the arguments to the function being called to
obtain the values, since originally some of the values where static
member data in SurfaceFlinger.
There were similar changes required for the tests and the fuzzers, to switch over,
including how some tests mutated the configuration values so that they
overall coverage was the same.
No new tests/fuzzing was added, though it should now be easier to extend
coverage.
Test: atest libsurfaceflinger_unittest
Bug: None
Change-Id: I8dc3c2317a92b256e58ec45190e24463032c2f8e
|
|
The rotation flags are typically only used for a camera preview, which
wants to avoid changing its orientation and flicker during rotation.
Prior to this CL, the rotation flags were tied to the primary display,
meaning that if the camera preview was on another display, the rotation
flags may not be up to date. For example, if the primary display is off,
its flags will not be updated on rotation.
Ideally, the flags should be based on the display where the preview will
be shown, but this is a much larger architectural change, tracked in
b/259407931.
As a temporary workaround, associate the flags with the active display.
Store the flags in SurfaceFlinger, which knows when the active display
changes. Update when the active display switches to a different display
or when the active display rotates, matching the behavior of
mActiveDisplayTransformHint, which seems similar but is different. Store
the flags as a static variable so that LayerFE can access it. LayerFE
does not have a way to access the actual SurfaceFlinger object, and it
should not.
Access to the new flags is safe because it is only read or written from
the main thread.
Bug: 269685949
Bug: 259407931
Test: ActiveDisplayRotationFlagsTest
Change-Id: I5532e140a603be222cb3ea1ae563638317c1d745
|
|
This semantics guarantees the virtual display will at least have the
specified refresh rate, e.g., if 60hz is requested on a 90hz display,
the virtual dislay will get a 90hz.
Bug: 266965278
Test: atest libsurfaceflinger_unittest
Change-Id: Ie7b30c5766454d0ad25cfd437f0498594c690a2e
|
|
|
|
Bug: 267195714
Test: manual
Change-Id: If518fabf16d91c1a58f7b68a5f4de0629df90fec
|
|
Previously we used a mocked up flinger to playback the transactions
and then generate the layers trace. This was prone to data races
since layers were added on binder thread and transactions were
committed on the main thread. This would lead to invalid data
being generated or crashes.
This cl modifies the transaction traces to capture state changes
in the main thread and uses the new front end logic to generate
the layer snapshots. New front end has no dependencies to the rest
of surfaceflinger and will be more robust in recreating layer
snapshots .
Test: presubmit
Test: capture layers and transaction traces
Fixes: 255901752
Change-Id: I416bff27c90eae1ab8383cbfff4403b0e93c1006
|
|
|
|
"Leader" became ambiguous once we began to consider that there are two
orthogonal concepts that "leader" seems to imply:
- The display with the highest refresh rate (originally called "leader")
- The display that is refreshed first in a given update (assuming it's
being updated)
To better distinguish between the two, we've come up with new names:
- pacesetter
- front runner (for the second concept)
Change uses of "leader" to "pacesetter" throughout SF and Scheduler.
Bug: 255635821
Bug: 256196556
Test: m
Change-Id: Ia02c35dd442d310695f1ce873fbaf30910c12419
|
|
Update the RefreshRateOverlay with the refresh
rate received from the HWC callback.
Test: Device boots, existing overlay works with SF
manual test with the patch of the HWC
Ibc80d66eae6b21c3cf84d35fa819e97ccc509ede
BUG: 202734676
Change-Id: I94bda4d054d878b173eb594d5c71e2f83459a20a
|