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
DisplayDevices are now keyed of the wp<IBinder> the client uses.
DisplayID has now become DisplayType which is just used to identify
physical displays (as opposed to virtual displays such as wifi displays).
Change-Id: I0c5968f2c902dcd699a7e0afacf833ff070c12ea
Use only display tokens in the API to refer to new displays.
Don't require the caller to specify the display when creating
a surface (since in general a surface could be shown on
any display).
This is intended to be a minimum change just to update the API.
Note that SurfaceFlinger still uses DisplayID in a few places
internally that might cause some features not to work properly
when there are multiple displays (LayerScreenshot, for example).
Change-Id: I3d91eec2da406eefd97bcd53655d403ad865a7e6
Mathias Agopian