GitLab

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 reverts commit 2da2c150.

needed for investigating 7309949

Bug: 7309949
Change-Id: If29a5c08d0e87f46b44ba2e1030be61cb4d1403b

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

Bug: 7309812
Change-Id: Ia401d642094a46c62f0d26c65da1d11341e203a1

Bug: 7288401
Change-Id: I14beeef58fac5270cef3b611e18c163060efe6c3

DdmHandleAppName.setAppName() signature changed which broke
this debugging feature.

Needed for debugging b\7267680

Change-Id: I4482bf5a441e91bef89d1ddea9a4152333be7f88

Merge "Revert "ugly, temporary, workaroung for a problem where a binder thread spins forever"" into jb-mr1-dev

This reverts commit 0845d024

Change-Id: I395037cb9427cd11f7de6bb78fbdfa917fc6263a

Bug: 7289992
Change-Id: I0c3d482a1af57e5f444be2ba7f2751ac3e954af2

Merge "ugly, temporary, workaroung for a problem where a binder thread spins forever" into jb-mr1-dev

Bug: 7289992
Change-Id: I0c3d482a1af57e5f444be2ba7f2751ac3e954af2

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

Change-Id: I0440a942d3e685d619ec9cc402d3293cb3f52df1

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

Adding logs to tell which specific methods throw OpenGL errors.

Change-Id: I1d73c7566ed1ea6610392020411762c6255a0ede

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

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

Change-Id: Id7662c503815293040c240232a6622bd6f6eab37

Change-Id: Iffc48412b8c951116a956a3ac7dab8d75eed13da
Bug: 7238122