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
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>
Adds a sourceCrop Rect parameter to screenshot commands, which allows
clients to capture only a portion of the screen instead of the whole
screen.
Bug: 15137922
Change-Id: I629447573cd34ffb96334cde7ba02490b9ea06d8
This allows querying and switching display device configurations
through the ISurfaceComposer/SurfaceComposerClient interface.
Bug: 14320401
Change-Id: I8c22165698950e5da32204c1c4da92122f91a715
SensorService should hold a wakelock till the app reads events from a wakeup sensor. Currently drivers hold a wakelock with a
timeout while delivering events from a wake up sensor like Significant Motion. This hack can be removed now.
Bug: 9774884
Change-Id: If3b5acb99c9cf0cd29012fcfa9d6b04c74133d01
Finally remove the BufferQueue constructor itself. From now on, all
BufferQueues must be created through the createBufferQueue method.
Bug: 13415624
Change-Id: I192bf9430265bab761dcd59db1f02c9d0ac4feed
Increases NUM_BUFFER_SLOTS from 32 to 64 and changes the mask
returned by IGBC::getReleasedBuffers from 32 to 64 bits.
Bug: 13174352
Change-Id: Ie8ef0853916cfb91f83881c7241886bb1950f01a
Adds a StreamSplitter class, that takes one IGraphicBufferConsumer
interface and multiple IGraphicBufferProducer interfaces and
implements a one-to-many broadcast of GraphicBuffers (while managing
fences correctly).
Change-Id: I38ecdf3e311ac521bc781c30dde0cc382a4376a3
Adds a new method, IGBP::detachNextBuffer, that effectively does
dequeue + request + detach in a single call, but does not need to
know anything about the dequeued buffer, and will not block on
dequeue. This is mostly for the upcoming StreamSplitter to use in
its onBufferReleased callback.
Change-Id: Ie88a69de109003acebaa486a5b44c8a455726550
* commit 'ef89f7638c43ce5f73e32d487bf65c3375995e3b':
Add stringType and requiredPermission to sensors, effectively adding permission checking for sensors
* commit 'cf818ebbf07c6a20ef48d71bf82f8d4bdf3a398c':
Add stringType and requiredPermission to sensors, effectively adding permission checking for sensors
It turns out that there's no reason to have both I* and Bn* versions
of the createBufferQueue method, so I removed the Bn* version.
Change-Id: I66aeb09e10458ae540ddf1f38d2d0154ea8f315b
* commit '00f4dde1aa88576811bca79bc8242e1fc1edb333':
Add stringType and requiredPermission to sensors, effectively adding permission checking for sensors
* commit 'c57a019e117117c5a76c772970b26cd0f5db8c6a':
Add stringType and requiredPermission to sensors, effectively adding permission checking for sensors
Add a callback to the producer side, onBufferReleased, which will be
called every time the consumer releases a buffer back to the
BufferQueue. This will enable a buffer stream splitter to work
autonomously without having to block on dequeueBuffer.
The binder object used for the callback replaces the generic IBinder
token that was passed into IGraphicBufferProducer::connect to detect
the death of the producer. If a producer does not wish to listen for
buffer release events, it can pass in an instance of the
DummyProducerListener class defined in IProducerListener.h, if it even
cares about death events (BufferQueue doesn't enforce the token being
non-NULL, though perhaps we should).
Change-Id: I23935760673524abeafea2b58dccc3583b368710
To make struct Event have consistent memory layout between x86
and x86_64, force nsecs_t timestamp align to 64bit because it's
not true for x86.
Change-Id: I49eaddd89e10d595cf6a5130f9762b5388c96625
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
This adds a second createBufferQueue method that returns
sp<IGraphicBuffer*> interfaces instead of sp<BnGraphicBuffer*>, since
most clients don't actually need the Binderized versions (but some
might).
Change-Id: Iaf4f719c96ddb6f704afc75cf52be22588173e32
Sideband streams are essentially a device-specific buffer queue that
bypasses the BufferQueue system. They can be used for situations with
hard real-time requirements like high-quality TV and video playback
with A/V sync. A handle to the stream is provided by the source HAL,
and attached to a BufferQueue. The sink HAL can read buffers via the
stream handle rather than acquiring individual buffers from the
BufferQueue.
Change-Id: Ib3f262eddfc520f4bbe3d9b91753ed7dd09d3a9b
Adds detachBuffer and attachBuffer calls to both the producer and
consumer sides of BufferQueue. Buffers may be detached while dequeued
by the producer or acquired by the consumer, and when attached, enter
the dequeued and acquired states, respectively.
Bug: 13173343
Change-Id: Ic152692b0a94d99e0135b9bfa62747dab2a54220
Now that BufferQueue has been split into core + producer + consumer,
rewrite BufferQueue to be a thin layer over a producer and consumer
interface. Eventually, this layer will be deprecated in favor of
only using either the producer or consumer interface, as applicable.
Change-Id: I340ae5f5b633b244fb594615ff52ba50b9e2f7e4
Add the ability to ignore layers' transformation matrices during
screenshot capture, which will allow the window manager to capture
unrotated images for recents during the device rotation animation.
Bug: 11805195
Change-Id: I854d87bc84ca06ef9a054a454af1c080ee66fbb8
* Basic tests only. Needs more complicated queue/dequeue tests.
* Also needs consumer-side tests to really be thorough.
Change-Id: I1099dd56d65b6e9dfa15377726d6054ce657c0ca
This change makes GLConsumer use the EGL_ANDROID_image_crop extension when
available on a device. The crop rectangle is passed to the EGL driver when
creating EGLImages, allowing the crop to be performed by the driver rather than
using the texture transform matrix.
Bug: 10897141
Change-Id: I63e9a5d5c85067376abc420e3639154468346311
we add a flag to ANativeWindow::setBufferTransform that means
"apply the inverse rotation of the display this buffer is displayed
onto to".
Bug: 10804238
Change-Id: Id2447676271950463e8dbcef1b95935c5c3f32b2
BitTube used to send objects one at a time and didn't
handle errors properly.
We now send all the objects in one call, which means they
have to be read as a single batch as well. This changes the
BitTube API.
Update SensorService to the new API.
Also added an API to set the size of the send buffer.
Bug: 10641596
Change-Id: I77c70d35e351fdba0416fae4b7ca3b1d56272251
This change adds an entire field to note whether the timestamp was
auto-generated by Surface or supplied by the application.
The value is used when deciding whether or not to drop frames based
on buffer presentation timestamps. If a desired presentation time
was set explicitly, BufferQueue will use that value to decide if a
frame should be dropped. If the timestamp was generated by Surface
at the time the buffer was queued, the timestamp is ignored.
Bug 10151804
Change-Id: Ibd571a7578351063b813cbdad2ddbeed70655ba5
- 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
While currently untested, this should allow to move the
BuffereQueue in the consumer process and have everything
work as usual.
Bug: 9265647
Change-Id: I9ca8f099f7c65b9a27b7e7a3643b46d1b58eacfc
Fallout from the Flattenable change, update all its uses.
Additionnaly, fix/tighten size checks when (un)flatten()ing
things.
Removed the assumption by some flattenables (e.g.: Fence)
that the size passed to them would be exact (it can
and will be larger in some cases)
The code in Parcel is a bit complicated so that we don't
have to expose the full implementation (and also to
keep the code smallish).
Change-Id: I0bf1c8aca2a3128491b4f45510bc46667e566dde
we can now queue/dequeue a buffer in asynchrnous mode by using the
async parameter to these calls. async mode is only specified
with those calls (it is not modal anymore).
as a consequence it can only be specified when the buffer count
is not overidden, as error is returned otherwise.
Change-Id: Ic63f4f96f671cb9d65c4cecbcc192615e09a8b6b
we tag queued buffers with the "bufferqueue cannot block" flag
and use that bit to discard a buffer in the queue by new ones
comming in. this allows us to remove the buffer queue drain in
disconnect while maintaining the right behaviour if it gets
connected again (since each buffer remembers how it was enqueued).
Change-Id: I1e703d363a687b70b19ba49cef32213116e8bd3f
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
Now that we are having separate buffer-instances for the buffer-
queue, we can free all buffers; we don't have to keep the head
alive.
Change-Id: I023e9161a2501d99333f8868ce438afa914ec50f
Signed-off-by: Lajos Molnar <lajos@google.com>
Related-to-bug: 7093648
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
- Add fields to CpuConsumer::LockedBuffer for new information
- New lock methods for GraphicBuffer and GraphicBufferMapper for
the format
Bug: 8734880
Change-Id: If31f82c62d64b6942cf4cc6e5715585c03273f12
mDefaultWidth, mDefaultHeight and mCurrentScallingMode are now
initialized to the same default value that BufferQueue uses.
Change-Id: I0d4da2022b06419d12745716d8ddbd48c8869953
This moves the call to ConsumerBase::abandon from the ConsumerBase dtor to
ConsumerBase::onLastStrongRef. The abandon call relies on virtual methods to
perform the clean-up, so calling it from the ConsumerBase dtor after the
derived classes dtors ran was skipping some of the clean-up. The
onLastStrongRef method should get called just before the most derived class's
dtor gets called.
Bug: 8349135
Change-Id: I836946826927cc1ed69c049049f525f92b17a269
We now detect at runtime which sync features to use, which
allows us to remove a lot of the compile-time configuration
options. There is still one option though, to disable
KHR_fence_sync on some devices (which are more efficient
without it).
- added a backdoor to get the vendor's EGL strings
the new logic is:
- use always ANDROID_native_fence_sync if available
- fallback to KHR_fence_sync if available and not disabled
by the compile-time option
- use KHR_wait_sync if available and either of the above is
enabled
Change-Id: I9c4b49d9ff1151faf902cc93bd53ea5f205aaabf
We're not using IMemoryHeap as a transport anymore,
instead we're providing a CpuConsumer and use the
IGraphicBufferProducer version of the screenshot API.
However, some GPU drivers don't support properly
a GPU to CPU path, to work around this, we use a
temporary BufferQueue on the server side for the
GL rendering, and we use glReadPixels into the
CpuConsumer (we're now using a CPU to CPU path
which is always supported).
Currently this "wrapping" is always performed,
but it can be bypassed on devices that support
the GPU to CPU path.
This also addresses a DoS attack vector on
SurfaceFlinger, where an application could
consume all of SF's filedescriptors by creating
a lot of screenshots in a row.
Bug: 8390553
Change-Id: I9e81514c2a7711b9bb393f74305be7d2abe08f1c
* changes:
Add BufferQueueInterposer and use it for virtual displays
Add DisplaySurface abstraction
Fix argument types in IGraphicBufferProducer methods
Minor cleanups/fixes before virtual display refactoring
None of these should change behavior, except for removing some
incorrect log messages when using a virtual display.
- HWComposer::getAndResetReleaseFenceFd() checks the HWC version, so
no need to do that in the DisplayDevice::onSwapBuffersCompleted().
However, it should check that mFramebufferSurface is not NULL like
it is for virtual displays.
- Comment that FramebufferSurface::dump() overrides the non-virtual
ConsumerBase::dump(), and fix it so the right thing happens
regardless of the static type of the pointer/reference the callee
has. FramebufferSurface::dump() could be removed right now, but I'd
need to bring it back in a later change.
- Use the right enum for validating display type ids.
- Don't try to send hotplug events for virtual displays.
- Mark virtual displays as connected so HWComposer::prepare() doesn't
think something is wrong when it gets a non-NULL layer list.
- Remove unused FramebufferSurface methods.
Bug: 8384764
Change-Id: Id28a2f9be86b45f4bb7915fdf7752157035f4294
the recent screenshot rework allowed the older screenshot
interface to work without that permission
Change-Id: I6c4743f4591c81106e3b823d55a055f7b4907de1
ISurface was only used to get the IGraphicBufferProducer from
a Layer. It's now replaced by a BBinder subclass / IBinder and
is only used as a handle to the surface, to both refer to it
and manage its life-time.
Also cleaned-up a bit the ISurfaceComposer interface and
"create layer" code path.
Change-Id: I68d0e02d57b862cffb31d5168c3bc10cea0906eb
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
