Modify SurfaceFlinger to use VirtualDisplaySurface in all cases when a virtual
display is used. Add functionality in VirtualDisplaySurface to resize the
buffers aquired in the QueueBufferOutput. Add transaction support in
SurfaceFlinger for resize. Add the modification of the size in DisplayDevice.
Change-Id: Iae7e3556dc06fd18d470adbbd76f7255f6e6dd6b
Tested: None
Commit 78014f32da introduced a bug that
made us pre-allocate buffers into the last available free slots instead
of the first available ones. This in turn caused more re-allocations,
and possibly triggered driver bugs.
Change-Id: Ic4a70e676b4f2bbb054bc873be62ced26e3099a0
i) Send ack for wake_up sensors on the socket connection instead of using Binder RPC.
ii) Cache events per connection in case there are write failures. Compute cache size
from FIFO counts of sensors.
iii) Send FlushCompleteEvent only for apps that explicitly called flush().
Change-Id: I018969736b7794b1b930529586f2294a03ee8667
If getNativeBuffer() is called on a NULL GraphicBuffer the
static_cast of this from GraphicBuffer* to ANativeWindowBuffer*
will return a small pointer like (ANativeWindowBuffer*)0x10.
This value can propagate past NULL checks until it causes a crash
far away from the original NULL pointer. Crash immediately
instead.
Change-Id: Id614b9eb1484108b3c3c733545309844c4b87532
BufferQueueProducer::allocateBuffers used to keep the BufferQueueCore
mutex while doing the buffer allocation, which would cause the consumer
(which also needs the mutex) to block if the allocation takes a long
time.
Instead, release the mutex while doing the allocation, and grab it again
before filling the slots. Keep a bool state and a condvar to prevent
other producers from trying to allocate the slots while the mutex is
released.
Bug: 11792166
Change-Id: I4ab1319995ef892be2beba892f1fdbf50ce0416d
(cherry picked from commit ea96044470)
In most cases, EGLImages can be created one-to-one with graphic
buffers in slots, but that was difficult due to some special
cases:
- ReleaseTexImage binds a custom 'unslotted' debug image.
- When all slots are freed, we still need to hang on to one.
These cases were handled by keeping an additional reference to
the 'current' buffer (mCurrentTextureBuf), but we would create
new images since we can't reference count them in the same way.
This patch uses the same semantics, except that it reference
counts the image (an EglImage wrapper class) rather than just
buffer. The wrapper class also detects the cases when we need
a new EGLImage, and only creates them in those rare cases.
Change-Id: I2915761dbe49d2a9bda1f59e60f857543634636b
Bug: 15116722
- Adds a sticky transform field that can be set from a
SurfaceFlinger client Surface. This transform is
added to any transform applied to the Surface.
Change-Id: Idaa4311dfd027b2d2b8ea5e2c6cba2da5779d753
Adds a constructor that doesn't require a GLES texture name and sets
up the GLConsumer in detached mode.
Bug: 15616428
Change-Id: Idc9ea2e59baa24bbd959da9fffe0fb71c0aa9818
Removes the dependency on default constructor parameters for
GLConsumer so that a different constructor prototype can safely be
added.
Change-Id: I0da924bbd4c141edbf305598c1be8bc575654680
This adds an allocateBuffers method to BufferQueue, which instructs
it to allocate up to the maximum number of buffers allowed by the
current configuration. The goal is that this method can be called
ahead of render time, which will prevent dequeueBuffers from blocking
in allocation and inducing jank.
This interface is also plumbed up to the native Surface (and, in
another change, up to the Java Surface and ThreadedRenderer).
Bug: 11792166
Change-Id: I4aa96b4351ea1c95ed5db228ca3ef98303229c74
All uses of this API have been removed. It should
never have been made public in the first place.
bug: 15424960
Change-Id: Id07d24ec95b2b393e6da138a7e8a9a4ecebeca94
We replace the blank/unblank calls in surfaceFlinger with a more generic
setPowerMode() routine.
Some displays support different power modes (for example, with reduced
color palettes). Depending on the use case we should be able to toggle
these modes, so as to achieve incremental power savings.
Initially, three power modes will be supported:
- HWC_POWER_MODE_OFF
- HWC_POWER_MODE_DOZE
- HWC_POWER_MODE_NORMAL
HWC_POWER_MODE_OFF will correspond to blanking the display, while
HWC_POWER_MODE_NORMAL will correspond to unblanking. HWC_POWER_MODE_DOZE
will put the display into a low power setting, if it is supported in
hardware.
If such a low power mode is not supported, it should be treated as a
call to set the mode to HWC_POWER_MODE_NORMAL.
As a consequence of adding the mPowerMode field, the mScreenAcquired is
no longer required, and thus references to it are removed and replaced
equivalent references to mPowerMode.
We also add the glue code to connect the services invocation of setting
a power mode and the HAL implementation in HWComposer.
Bug: 13472578
Change-Id: I431595ecf16d2f2c94259272db3dd42f29636204
Signed-off-by: Prashant Malani <pmalani@google.com>
