When the screen is turned off, the current stack is set to -1. This causes
logic in iSurfaceFlinger's handleTransactionLocked() function to fail to
match the current stack, and the latest orientation is not set into the
layer. This causes BufferQueue, later, to potentially set an obsolete
transformHint on a created surface (such as in the case with ImageWallpaper's
Egl surface, in the bug below).
The fix is to note this situation and use a default value for the DisplayDevice,
which should have the current orientation information.
Issue #8508397 ImageWallpaper sometimes rendered in wrong orientation causing a ~30-40% drop in graphics performance
Change-Id: Ibae15d73b289a8343c67f4f6bb77fdf11dd95ee7
SF transactions were always handled on VSYNC which allowed
the screenshot to sneak-in between closing the transaction
and vsync (before it's latched), resulting in a screenshot
with the previous state.
we now always force transactions to happen immediately
before screenhots.
Bug: 7552304
Change-Id: I0afc86b7e8366173daff5b9988bbb4d2a0f43860
HWComposer queries the HWC for dimensions of physical displays, but
can't do that for virtual displays. The dimensions are used to set the
display frame of the framebuffer target layer passed to HWC, and
implicitly the dimensions of the virtual display.
Bug: 8316155
Change-Id: I9cbd2530d2fa878f86128a1472def520b5d694a5
since the transparent region hint really depends on the
content of the window containing the SurfaceView
(it's calculated by the view hierarchy based on
overlapping views), it makes sense to latch it only when
the content of the window (the app) changes.
This should help fixing drawing artifacts when changing the
layout of a window containing a SurfaceView.
Bug: 8511430
Change-Id: Ic3aa668495293cb4d82a2cd7dcf3b6a337287678
We now detect at runtime which sync features to use, which
allows us to remove a lot of the compile-time configuration
options. There is still one option though, to disable
KHR_fence_sync on some devices (which are more efficient
without it).
- added a backdoor to get the vendor's EGL strings
the new logic is:
- use always ANDROID_native_fence_sync if available
- fallback to KHR_fence_sync if available and not disabled
by the compile-time option
- use KHR_wait_sync if available and either of the above is
enabled
Change-Id: I9c4b49d9ff1151faf902cc93bd53ea5f205aaabf
DisplayDevices can be released when DisplayManager removes them from
the display list, or (for virtual displays) when the surface is set to
NULL. We were only cleaning up HWC resources associated with the
display in the first case.
Bug: 8384764
Change-Id: Id3d226dd7178fbe6d0a2ac4e2660b864ee073de3
If we're using a HWC that doesn't support virtual displays, or we have
more virtual displays than HWC supports concurrently, the
VirtualDisplaySurface should simply be a passthrough from source
(GLES) to sink.
This change also tries to distinguish between display types and HWC
display IDs a little better, though there's more to do here. Probably
needs a higher-level rethink; it's too error-prone now.
Bug: 8446838
Change-Id: I708d2cf262ec30177042304f174ca5b8da701df1
some drivers don't support this yet, so we use a system
property to enable the glReadPixels "workaround" for them:
ro.bq.gpu_to_cpu_unsupported=1
Change-Id: I74d6a3a8f0cee8d5a507b72c760cf247e39195e0
We're not using IMemoryHeap as a transport anymore,
instead we're providing a CpuConsumer and use the
IGraphicBufferProducer version of the screenshot API.
However, some GPU drivers don't support properly
a GPU to CPU path, to work around this, we use a
temporary BufferQueue on the server side for the
GL rendering, and we use glReadPixels into the
CpuConsumer (we're now using a CPU to CPU path
which is always supported).
Currently this "wrapping" is always performed,
but it can be bypassed on devices that support
the GPU to CPU path.
This also addresses a DoS attack vector on
SurfaceFlinger, where an application could
consume all of SF's filedescriptors by creating
a lot of screenshots in a row.
Bug: 8390553
Change-Id: I9e81514c2a7711b9bb393f74305be7d2abe08f1c
* changes:
Add BufferQueueInterposer and use it for virtual displays
Add DisplaySurface abstraction
Fix argument types in IGraphicBufferProducer methods
Minor cleanups/fixes before virtual display refactoring
DisplayDevice now has a DisplaySurface instead of using
FramebufferSurface directly. FramebufferSurface implements
DisplaySurface, and so does the new VirtualDisplaySurface class.
DisplayDevice now always has a surface, not just for virtual displays.
In this change VirtualDisplaySurface is just a stub; buffers still go
directly from GLES to the final consumer.
Bug: 8384764
Change-Id: I57cb668edbc6c37bfebda90b9222d435bf589f37
None of these should change behavior, except for removing some
incorrect log messages when using a virtual display.
- HWComposer::getAndResetReleaseFenceFd() checks the HWC version, so
no need to do that in the DisplayDevice::onSwapBuffersCompleted().
However, it should check that mFramebufferSurface is not NULL like
it is for virtual displays.
- Comment that FramebufferSurface::dump() overrides the non-virtual
ConsumerBase::dump(), and fix it so the right thing happens
regardless of the static type of the pointer/reference the callee
has. FramebufferSurface::dump() could be removed right now, but I'd
need to bring it back in a later change.
- Use the right enum for validating display type ids.
- Don't try to send hotplug events for virtual displays.
- Mark virtual displays as connected so HWComposer::prepare() doesn't
think something is wrong when it gets a non-NULL layer list.
- Remove unused FramebufferSurface methods.
Bug: 8384764
Change-Id: Id28a2f9be86b45f4bb7915fdf7752157035f4294
the recent screenshot rework allowed the older screenshot
interface to work without that permission
Change-Id: I6c4743f4591c81106e3b823d55a055f7b4907de1
the purgatory list wasn't needed anymore; in fact it had no effect as
buffer life-time management is now handled by the BufferQueue.
For QueuesToWindowComposer we keep a list of wp<> on the IBinder
for IGraphicBufferProducers we hand over to clients so we can
easily check if an IGraphicBufferProducer is ours. We clean-up the
list when our IGraphicBufferProducer are destroyed.
Bug: 8349142
Change-Id: I1aa06652ade8c72d0004a3f5e6c3d6e8a82fc2ae
since we're using glReadPixels(), we only need to use
the width (as opposed to the stride) of the source
screenshot.
Bug: 8374664
Change-Id: I145c80f4fff5444df7c77c4f52e70a7203caddbd
ISurface was only used to get the IGraphicBufferProducer from
a Layer. It's now replaced by a BBinder subclass / IBinder and
is only used as a handle to the surface, to both refer to it
and manage its life-time.
Also cleaned-up a bit the ISurfaceComposer interface and
"create layer" code path.
Change-Id: I68d0e02d57b862cffb31d5168c3bc10cea0906eb
We were using the "visible layer list" when taking screenshots,
which doesn't work when a layer is behind other opaque layers
and therefore hidden.
We fix this by using the full layer list, filtered by the
layerstack of the display we're looking at.
Bug: 7552304
Change-Id: I4b6f77e5511aea94f8d218975b6e22738e7e5d5b
older drivers which are doing implicit synchronization need this
or they could deadlock.
Bug: 8341885
Change-Id: Icd980a6be16071678d6151e34725b3c1c547d7ee
* changes:
Get rid of LayerBase.
Make LayerDim a regular Layer instead of a LayerBase
fold LayerBaseClient into LayerBase
Remove support for ScreenshotLayer
The functionality of LayerBase and Layer is folded
into Layer. There wasn't a need for this abstraction
anymore.
Change-Id: I66511c08cc3d89009ba4deabf47e26cd4cfeaefb
- SurfaceFlinger now supports to take a screenshot
directly into an IGraphicBufferProducer
- reimplement the IMemoryHeap screenshot on top
of the above
- reimplement LayerScreenshot such that its
BufferQueue is directly used as the destination
of the screenshot. LayerScreenshot is now a thin
wrapper around Layer
Bug: 6940974
Change-Id: I69a2096b44b91acbb99eba16f83a9c78d94e0d10
When a display is added, initialize it to use an empty layer stack, so
if it is somehow visible it will show black. It will be assigned the
real layer stack -- along with a projection and other properties -- by
window manager soon. Normally a display remains blanked until window
manager has decided what to show on it, but for HDMI connected at boot
that isn't currently the case.
Bug: 7258935
Change-Id: Ic9bb25f7a9b8d9d3772b097ab1d6fa03bc8780a1
The crop always had left=top=0, because the crop position
and the layer's transform were merged together in
computeBounds() (which really used to compute the
bounds in screen space, which we usually call the
"frame" elsewhere in the code)
Note: in practice this crop value is not used by
hwc, because it's overridden in Layer::setGeometry(), which
is why this bug was never apparent.
Change-Id: I1ec6400a8fc8314408e4252708f43ea98c2fe64e
This change makes the 'dumpsys SurfaceFlinger --latency' command with no extra
args dump the frame timestamp data for the most recent frames that
SurfaceFlinger generated that included window animation transaction changes.
Change-Id: I8bded1ea08a4cddefef0aa955401052bb9107c90
The C++ class names don't match what the classes do, so rename
ISurfaceTexture to IGraphicBufferProducer, and SurfaceTexture to
GLConsumer.
Bug 7736700
Change-Id: Ia03e468888025b5cae3c0ee1995434515dbea387
For hotpluggable builtin displays (currently just HDMI), create the
display device IBinder token when the display is connected and destroy
it when the display is disconnected. Previously we created the tokens
at startup and never changed them. This made it so that when comparing
current and drawing state, we couldn't tell whether a display had been
disconnected and reconnected.
Bug: 7491120
Change-Id: I2ac82b864e10cb1cd0a308782d7e0ab9745c5d81
if a layer is not mirrored, we now use its display
as the source for the transfrom hint calculation
instead of always using the default (main) display.
this change does two thing:
1) we make updateTransformHint take a DisplayDevice
as a parameter instead of hard-coding the
main display.
2) each time we do a transaction that could change
the hint, we go through all layers and
figure out which display should be used for their
transform hint.
Bug: 7599344
Change-Id: I9b04a95e6c372dd770bacf81d8ef6f8e31b87b83
For hotpluggable builtin displays (currently just HDMI), create the
display device IBinder token when the display is connected and destroy
it when the display is disconnected. Previously we created the tokens
at startup and never changed them. This made it so that when comparing
current and drawing state, we couldn't tell whether a display had been
disconnected and reconnected.
Bug: 7491120
Change-Id: I23b77037dc0f548d549abf580339edd0e3c626e9
If we switched from HWC to GLES but the dirty region was empty
(could happen if the dirty region is outside of the screen for instance), we
need to force a full screen composition.
In this change we ignore the dirty region for the purpose of
rejecting the whole update and we rely on the fact that it will later
be expanded to the whole screen. This was the least risky fix.
Bug: 7467760, 7452931
Change-Id: I2132f2f963b00a3ce7150adadb107b0367b3862e
the scissor rect is now computed once by DisplayDevice
and is combined with the "undefined" region so that
the letter-boxed area of the screen get cleared in
drawWormhole.
Bug: 7149437
Change-Id: Id2f30516a5786f32eace7f876ff32028f954f357
we perform external display clipping only on the GL
side (ie: not done on the h/w composer side, which is
harder and would be too risky). in practice this means
that WFD will be clipped properly, while HDMI *may* or
may not depending on how hwc is used.
Bug: 7149437
Change-Id: I92d4d04220db72b6ffb134c7fa7a93af569723a5
a misbehaving or malicious client could cause SF to crash
by providing a "fake" IInterface. we now check the
IInterface we get is our own and local.
Bug: 7278879
Change-Id: Ia19d05902d4b2385c5a16416148378d4998833fd
This change adds support for displays that are not allowed to display surfaces
with the eSecure flag set. All non-virtual displays are considered secure,
while virtual displays have their secure-ness specified at creation time.
Bug: 7368436
Change-Id: I81ad535d2d1e5a7ff78269017e85b111f0098500
we were holding a reference (ie: pointer) to a sp<DisplayDevice>
while processing the message. Meanwhile the object itself could
go away and we would end up accessing a dead object.
the root cause of the problem is that we are accessing mDisplays[]
in a few places outside of the main thread.
Bug: 7352770
Change-Id: I89e35dd85fb30e9a6383eca9a0bbc7028363876c
This change adds a transaction flag for WindowManager to indicate that a
transaction is being used to animate windows around the screen. SurfaceFlinger
will not allow more than one of these transactions to be outstanding at a time
to prevent the animation "frames" from being dropped.
Bug: 7353840
Change-Id: I6488a6e0e1ed13d27356d2203c9dc766dc6b1759
Two issues:
(1) We were announcing the hotplug event before we were ready to
handle blank/unblank events, so we were losing the initial unblank
that power manager sends us when HDMI is first plugged in. This
left the display blank until you toggled the device power off/on.
(2) We were retaining fbTargetHandle for HDMI after the display was
disconnected. The value didn't get updated when HDMI was reconnected
because the display was blank, so we didn't go through that code
path. So, when HDMI was re-connected, we passed stale data into
the HWC.
Bug 7323938
Change-Id: I2335d24fd7b0f00bb23fc63aa7bcf44cb8857c73
this should be handled by the display-manager. we were doing
that in SF because until recently we didn't have enough support
in the HAL. however, this is now causing other problems when
plugging hdmi while the screen is off for instance.
Bug: 7150885
Change-Id: I739b209056a765d38d05295cf202f67ee0f506ae
When a display is disconnected, removing it from SurfaceFlinger's
display list is non-atomic with removing it from the Display Manager
and any in-flight transactions. So SurfaceFlinger might get a display
state change transaction for a display it has already forgotten about.
Just ignore these.
Bug: 7288082
Change-Id: Ic27e55377f3db40fb34e3b1cd67e43297df117a2
when enabling/disabling vsync we now make sure to
not call into the HAL if the state wouldn't change.
Bug: 7274951
Change-Id: Ie24a6d68888a51b577acf9c2a973d85437cbacaf
The display was being removed from SurfaceFlinger's list before we
had a chance to reset HWComposer's layer list, so we were passing
stale data into the hardware composer (which has its own per-display
data). This resulted in "invalid gralloc handle" complaints.
We now clear the layer list immediately after removing the display.
The display was being removed while its EGLSurface was still
"current", resulting in "cancelBuffer: BufferQueue has been
abandoned" complaints. We now call makeCurrent on the primary
display before removing the external display.
Bug 7274254
Change-Id: Ia59e3a61d7ec46488b96bf93ec5e4ed3488b70e4
This allows us to blank and unblank displays other than the built-in
display (e.g. HDMI).
Bug: 7240511
Change-Id: I89ea13f9e497be74c3e1231d0c62fb558e93e0f8
This change fixes a bug in SurfaceFlinger that caused the HWC_GEOMETRY_CHANGED
flag to be set every flip.
Change-Id: I4f395a2883bcbb53b23b3d14941aff108739c9f0
Bug: 7234237
The transparent region hint is computed only from view layout
locations, ignoring post-layout translation. If a SurfaceView is layed
out with no other views above it, but a view is moved above it
post-layout, that view's layout bounds would be subtracted from the
window's transparent region instead of its drawing bounds. Prior to
this change, the view would not be visible (except where its layout
bounds and drawing bounds overlap).
With this change, composition uses visible regions computed without
regard to the transparent regions. However, if all of a layer's
visible region is transparent, it will be removed from the list of
layers to composite. This doesn't fix the root problem of incorrect
transparent regions, and doesn't prevent bad composition in all cases.
But it does avoid it for some existing apps, whiel still allowing the
transparent region hint to save power in the important
fullscreen-video-in-a-SurfaceView case.
Bug: 7179570
Change-Id: I47cf939e12129b167afa344b8b036e8827103ac8
we now try first with EGL_FRAMEBUFFER_TARGET_ANDROID, and
pick the first config we find. Otherwise, we revert to
the old algorithm.
Bug: 7232584
Change-Id: I8d5c5a4ce48420832c2e2828718a8f53325effb0
MemoryHeapBase::getBase() returns MAP_FAILED in case or
OOM, not null which is what SF was checking against.
This addresses one of the issues of bug 7230543.
Bug: 7230543
Change-Id: I763a88f64a2f9ff75eb139cfbaf9a1a9746c5577
This adds a line to the "dumpsys SurfaceFlinger" output that shows
build-time configuration values.
Example:
Build configuration: [sf HAS_CONTEXT_PRIORITY] [libui] \
[libgui USE_FENCE_SYNC]
Bug 7206633
Change-Id: Ibe1856b459d34a4be6ee83a4ebfd2807e6cc68a0
this call is not needed and misleading on HWC 1.1; it can also have
a negative performance impact when multiple displays are used.
Bug: 7124069
Change-Id: I47cd25c9d6e69abcc9333b9ecd5044e8fb1919ec
getDisplayInfo() now returns proper information for
HWC managed displays.
hotplug is sitll not supported; so this is not fully correct
as the information returned will be bogus if the HDMI screen
is not plugged in.
Bug: 7191563
Change-Id: If55d8e829fae0443571548155007f486cdf9bc9f
The Surface createDisplay() call takes a display name for debugging.
This change carries it through SurfaceFlinger and displays it in
the "dumpsys SurfaceFlinger" output.
Bug 7058158
Change-Id: I79f3474a8656ff1beb7b478e0dbf2c5de666118a
- decouple GL and main display initialization
- ensure that each "supported" display has its own FramebufferSurface
- onScreenAcquired/Released now takes a display
Change-Id: If34a05f3dea40f6c79db77f4dde283a2580daac4
The hints were being set a little too late, so the pre-rotation stuff
wasn't quite working.
Bug 7054997
Change-Id: Id8d5c626db7a76f768ba762a145b315878ee08e6
There are two different translations to apply in the logical
orientation, one before scaling and one after.
So translate, scale, translate then rotate.
Bug: 7139798
Change-Id: I0726991cadb62988390e77503dbbaed54f07bfe3
we now make sure to take the blanked state of a display into
account when we build its list of visible layers, this ensures
that we won't call prepare/set with a non-empty list when the
display is blanked.
Possibly fixes 7075380, 7103553, 7130187, 7016215
Bug: 7075380
Change-Id: I9fdd2e73d1b7621eaeca3d4ac2ae60d9fb1b3631
This adds a trivial workaround for a one-shot boot time crash, plus
an explicit check and abort for a failure condition that currently
presents as a less obvious failure.
Bug: 7145521, 7147557
Change-Id: I548f6a9caa9f0bd5710aaecea0e1c6c7c8f2f281
FramebufferSurface no longer speaks directly to the FB HAL. Now
everything goes through HWComposer (which may or may not be
connected to a hardware composer).
Added display index arg to some query methods.
Change-Id: Id3e157d2d4e3555d33afbb703e518b6e92e2d6d5
onInitializeDisplays() was posting a transaction with changes
to the display projection. Unfortunately, it only set the
display orientation field and left viewport and frame
uninitialized.
The uninitialized values flowed downstream and found themselves
baked into a bogus DisplayDevice mGlobalTransform. That transform
was then applied to some Rects which were turned into Regions
that were them combined with other Regions.
Under certain situations, the uninitialized data might have
a largish value, resulting in the creation of Regions with
components in excess of the Region max-value limit of 0x7ffffff
(note that this is not INT_MAX). Later when performing a
binary operation using the Region, the Spanner would loop
indefinitely trying to figure out how to stuff a humongous
region inside of a max-value region. Not content to try
just once, the Spanner would continue trying again and
again, pegging the CPU and hanging surface flinger during boot.
Insanity soon followed.
Bug: 7130713
Change-Id: I0016f0c9662185be833474c212a1dd408096ae23
- the library is dlopened from libsurfaceflinger
- the library built only when libnativehelper exists
Bug: 7089510
Change-Id: Ib3ea1029d7e8f6e055f4b759d0bf68f5123fa8a1
this would happen when the composition was handled
entirely in h/w composer, in this case, we would
not set the fences for any involved layers.
Bug: 7049373
Change-Id: I1439dc156ce23c24041cdfbbebfe8ff4fdf790f8
this happened because we didn't check that the visible
region was within the bounds of the display.
Bug: 7064121
Change-Id: I2e81850a3dc3d1474253520ad7f9e559c26d5a96
