Enables -Weverything and -Werror, with just a few exceptions for
warnings we can't (or shouldn't need to) work around.
This is a squashed commit based on an initial change with a couple of
fixes to avoid breaking certain targets. The source commits are:
d723bd766900d504c06e429ba89cd2
Change-Id: I034abec27bf4020d84af60d7acc1939c59986dd6
In C++11 mode, "foo"MACRO_THAT_EXPANDS_TO_STRING gets lexed as a user
defined literal. Add space around the macro.
Change-Id: I2741f5be9c0b1562e0f413d1309ef9d687e89b41
- Return NOT_ENOUGH_DATA instead of INVALID_OPERATION when too many
buffers have already been locked.
- INVALID_OPERATION is nominally used when something irrecoverable happens,
but in this case the client just needs to call unlockBuffer to go back into a
good state.
Bug: 10333400
Change-Id: I3a034d77de85741429f832a90eedd670afa1dc94
this means they only have access to the consumer end of
the interface. we had a lot of code that assumed consumers
where holding a BufferQueue (i.e.: both ends), so most of
this change is untangling in fix that
Bug: 9265647
Change-Id: Ic2e2596ee14c7535f51bf26d9a897a0fc036d22c
this is the first step of a series of improvements to
BufferQueue. A few things happen in this change:
- setSynchronousMode() goes away as well as the SynchronousModeAllowed flag
- BufferQueue now defaults to (what used to be) synchronous mode
- a new "controlled by app" flag is passed when creating consumers and producers
those flags are used to put the BufferQueue in a mode where it
will never block if both flags are set. This is achieved by:
- returning an error from dequeueBuffer() if it would block
- making sure a buffer is always available by replacing
the previous buffer with the new one in queueBuffer()
(note: this is similar to what asynchrnous mode used to be)
Note: in this change EGL's swap-interval 0 is broken; this will be
fixed in another change.
Change-Id: I691f9507d6e2e158287e3039f2a79a4d4434211d
When acquiring a buffer, SurfaceFlinger now computes the expected
presentation time and passes it to the BufferQueue acquireBuffer()
method. If it's not yet time to display the buffer, acquireBuffer()
returns PRESENT_LATER instead of a buffer.
The current implementation of the expected-present-time computation
uses approximations and guesswork.
Bug 7900302
Change-Id: If9345611c5983a11a811935aaf27d6388a5036f1
Instead of representing the buffer-queue as a vector of buffer
indices, represent them as a vector of BufferItems (copies).
This allows modifying the buffer slots independent of the queued
buffers.
As part of this change, BufferSlot properties that are only
been relevant in the buffer-queue have been removed.
Also, invalid scalingMode in queueBuffer now returns an error.
ConsumerBase has also changed to allow reuse of the same
buffer slots by different buffers.
Change-Id: If2a698fa142b67c69ad41b8eaca6e127eb3ef75b
Signed-off-by: Lajos Molnar <lajos@google.com>
Related-to-bug: 7093648
- timeout is now 3 seconds instead of 1
- simplifies the API a bit
- allows us to change/tweak this timeout globaly
Bug: 8988871
Change-Id: I8d3c6ec43a372f602fb3f29856710339f86c0ec9
- Add fields to CpuConsumer::LockedBuffer for new information
- New lock methods for GraphicBuffer and GraphicBufferMapper for
the format
Bug: 8734880
Change-Id: If31f82c62d64b6942cf4cc6e5715585c03273f12
CpuConsumer cannot simply assume a slot's buffer is the same buffer
between acquire and release, and therefore it could be possible for
the same slot to get used for a second acquired buffer, if there's a
producer disconnect in between. This would cause a problem when the
first buffer is released by the consumer.
Instead, use an independent list of acquired buffers to properly track
their state.
Bug: 8291751
Change-Id: I0241ad8704e53d47318c7179b13daed8181b1fab
This change moves some common fence handling code into the base class for
BufferQueue consumer classes. It also makes the ConsumerBase class initialize
a buffer slot's fence with the acquire fence every time a buffer is acquired.
Change-Id: I0bd88bc269e919653b659bfb3ebfb04dd61692a0
This change makes BufferQueue derive the min undequeued buffer count from a max
acquired buffer count that is set by the consumer. This value may be set at
any time that a producer is not connected to the BufferQueue rather than at
BufferQueue construction time.
Change-Id: Icf9f1d91ec612a079968ba0a4621deffe48f4e22
BufferItemConsumer allows for acquiring BufferQueue's BufferItems,
which contain all the data and metadata the BufferQueue has for a
given graphics buffer.
This consumer is useful when direct access to the native buffer_handles
is needed by the client.
Also includes a minor cleanup of CpuConsumer's use of 'virtual'.
Bug: 6243944
Change-Id: If7dc4192b15ac499555f1eda42a85140f2434795
After a HWC set, each SurfaceFlinger Layer retrieves the release fence
HWC returned and gives it to the layer's SurfaceTexture. The
SurfaceTexture accumulates the fences into a merged fence until the
next updateTexImage, then passes the merged fence to the BufferQueue
in releaseBuffer.
In a follow-on change, BufferQueue will return the fence along with
the buffer slot in dequeueBuffer. For now, dequeueBuffer waits for the
fence to signal before returning.
The releaseFence default value for BufferQueue::releaseBuffer() is
temporary to avoid transient build breaks with a multi-project
checkin. It'll disappear in the next change.
Change-Id: Iaa9a0d5775235585d9cbf453d3a64623d08013d9
Aimed for use cases where gralloc buffers need to be consumed by CPU
users, such as camera image data streams.
The CpuConsumer is a synchronous queue, which exposes raw pointers to
the underlying graphics buffers to applications. Multiple buffers may
be acquired at once, up to the limit set at time of construction.
Change-Id: If1d99f12471438e95a69696e40685948778055fd
