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
The screenshot is a GL_RGB texture, and the GL_REPLACE texture env
mode uses vertex alpha for GL_RGB textures instead of alpha=1.0.
Bug: 7340077
Change-Id: I6fbb907023e48f9c422b15a33da79757d6726840
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
error codes are returned in errno, this caused ::waitForwever()
to only wait for 1 second and return improper error code (-1).
needed to help debugging 7316632
Bug: 7316632
Change-Id: Ie144f614a88393393972a3a770c6b4b0581f961a
DdmHandleAppName.setAppName() signature changed which broke
this debugging feature.
Needed for debugging b\7267680
Change-Id: I4482bf5a441e91bef89d1ddea9a4152333be7f88
This needs the ConsumerBase mutex locked, but wasn't locking it. Two
of the four places that called it already held the lock so were fine.
Now addReleaseFence() takes the lock itself, and I added
addReleaseFenceLocked() for the two already-locked callers, since in
one of them dropping the lock would be inconvenient.
Bug: 7289269
Change-Id: I7a5628adb516f8eec782aa6c14128202f96d7b0a
The new disconnectDisplay function doesn't handle virtual displays,
but it may be called for them. Return without doing anything.
Bug 7281786
Change-Id: I62607f2ae6073fa66b393f55932604aeb8e03566
The CleanSpec is missing parens, which causes $P to be interpreted as a
single variable, and the following printed to the log:
Clean step: rm -rf RODUCT_OUT/obj/SHARED_LIBRARIES/libgui_intermediates
This patch adds parens as needed.
Change-Id: I587998fa67a4884418c286360a577cdbb6ea9a21
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
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
