History log of /frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
fd9d183cd8c859ab8480dea572430398438ba8b5 31-Jul-2014 Michael Lentine <mlentine@google.com> Build fix to use the correct source.

Change-Id: If36710be600dd0e15c31682e0343f281baa55627
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
47e45405d1533aa73307014f7bf371e118695cf3 19-Jul-2014 Michael Lentine <mlentine@google.com> Allow for resizing of Virtual Displays.

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
24cd98eef88ac93f80c327f8d74f0a1ae0aceee4 13-Jul-2014 Jesse Hall <jessehall@google.com> Compile libsurfaceflinger with Clang and -std=c++11 [DO NOT MERGE]

This is necessary to use C11/C++11 stdlib atomics, which the next
change will do. This change also fixes a couple bits of syntax that
both GCC and Clang refuse to compile in -std=c++11 mode.

Change-Id: Ia14d9d6b537a3bb106c23e19a277e48be180754c
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
29a3e90879fd96404c971e7187cd0e05927bbce0 20-Jun-2014 Dan Stoza <stoza@google.com> BufferQueue: Add allocateBuffers method

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
0b63cd105cae094c21aafaa2bac8322427e75827 30-Apr-2014 Jesse Hall <jessehall@google.com> Handle failed requestBuffer after successful dequeueBuffer

If the virtual display consumer disconnects after the
VirtualDisplaySurface dequeues a buffer but before it requests it, the
request will fail. Previously the error was ignored, and the caller
would get a success result but a NULL buffer. Now the dequeued buffer
is cancelled and the error propagated to the caller.

Bug: 14140551
Change-Id: I91547885c2cf6063dc7a8f02d97f2df282cdde2c
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
fb39827ebce4637dcba03770f6644cf67e932e06 21-Apr-2014 Dan Stoza <stoza@google.com> Merge "BufferQueue: Increase max slots from 32 to 64"
febd4f4f462444bfcb3f0618d07ac77e3fc1f6ad 10-Apr-2014 Dan Stoza <stoza@google.com> BufferQueue: Increase max slots from 32 to 64

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
d9822a3843017444364899afc3c23fb5be6b9cb9 28-Mar-2014 Dan Stoza <stoza@google.com> BufferQueueProducer: add detachNextBuffer

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
f0eaf25e9247edf4d124bedaeb863f7abdf35a3e 21-Mar-2014 Dan Stoza <stoza@google.com> BufferQueue: Add producer buffer-released callback

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
b9b088375d33a87b201cdbe18be71802e2607717 13-Mar-2014 Dan Stoza <stoza@google.com> Remove deprecated BufferQueue constructor

Bug: 13415624
Change-Id: I9fe15e45daa7351f1db34ee75bfee6f19cb347d3
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
73ed82f809a40560fd3a6d53d18e5c846362d764 13-Mar-2014 Jesse Hall <jessehall@google.com> Merge "Add sideband streams to BufferQueue and related classes"
88a459a9b37f3b4eb3c9a044ad7af30616ad66c9 12-Mar-2014 Dan Stoza <stoza@google.com> VirtualDisplaySurface: no attach/detach support

Change-Id: I630dd6e352940318c33a4e072d2f33a6ec58c556
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
399184a4cd728ea1421fb0bc1722274a29e38f4a 04-Mar-2014 Jesse Hall <jessehall@google.com> Add sideband streams to BufferQueue and related classes

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
9f3053de78630815d60cf48a2cf2348cc5867c45 07-Mar-2014 Dan Stoza <stoza@google.com> BufferQueue: Allow detaching/reattaching buffers

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
7143316af216fa92c31a60d4407b707637382da1 05-Feb-2014 Dan Stoza <stoza@google.com> Fix virtual display nesting

This fixes the cycling rendering loop caused by nesting virtual
displays by preventing them from recomposing if their contents
haven't changed.

Bug: 12101046
Change-Id: I600365c0fd5d3ad93e04295d26cf9de177ffc79b
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
fdfde88d0bcd0b293c9deb37f49254bdd97e4dac 23-Jan-2014 mayank parshar <mayankp@broadcom.com> SurfaceFlinger: mFbProducerSlot initailization

b/12487813

SurfaceFlinger crash is observed during simulation of
Secondary display

Note: change 14e8b01a761180250671f3d6494532d8bd04fa8e
removed the initialization leading to the crash when
simulating secondary display. Restore the initialization
to solve the problem.

Change-Id: Iae5845fb82735e01de5cc0dc582d13c27e3c614f
Signed-off-by: mayank parshar <mayankp@broadcom.com>
Signed-off-by: Pierre Couillaud <pierre@broadcom.com>
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
b988f85fc44efd24f11f2e5ab8fb9b653916f666 10-Jan-2014 mayank parshar <mayankp@broadcom.com> SurfaceFlinger: mFbFence initialization

MobC00383030
b/12487813

SurfaceFlinger crash is observed while connecting
to Wi-Fi display.

Note: change 14e8b01a761180250671f3d6494532d8bd04fa8e
removed the initialization leading to the crash when
running through the HWC composition path. Restore the
initialization to solve the problem.

Change-Id: I581defc7135ac512080c0da06a62b1dae7d218c4
Signed-off-by: mayank parshar <mayankp@broadcom.com>
Signed-off-by: Pierre Couillaud <pierre@broadcom.com>
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
14e8b01a761180250671f3d6494532d8bd04fa8e 07-Nov-2013 Jesse Hall <jessehall@google.com> Don't change the framebuffer target until we render a new one

Continuing to send the last-rendered framebuffer to HWC on subsequent
frames allows the HWC to read partially-composed regions that haven't
changed, instead of re-composing from scratch.

Bug: 11573910
Change-Id: I8829877d2a06001f1e1b3f168cbba71c7b217b2d
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
497ba0e08503806571b52ebe27cc7eee4c0e71a7 05-Nov-2013 Jesse Hall <jessehall@google.com> Don't use implementation-defined format with CPU consumers

If the virtual display surface is being consumed by the CPU, it can't
be allowed with HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED since there is
no way for the CPU consumer to find out what format gralloc chose. So
for CPU-consumer surfaces, just use the BufferQueue's default format,
which can be set by the consumer.

A better but more invasive change would be to let the consumer require
a certain format (or set of formats?), and disallow the producer from
requesting a different format.

Bug: 11479817
Change-Id: I5b20ee6ac1146550e8799b806e14661d279670c0
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
c354effe97be26638618e3bc0da81a3f8b384b20 25-Oct-2013 Jesse Hall <jessehall@google.com> Fix handling of undefined TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS

related to b/8316155 - Implement HWComposer 1.3 w/ virtual display support
Change-Id: I2dc8d65a74174aa833cc491264f97f1f2df49307
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
6a968462f9ce4d93d81fcc13672073e3e6eb2e0f 04-Oct-2013 Naseer Ahmed <naseer@codeaurora.org> Add a boardconfig to force HWC composition of virtual displays

When this boardconfig is defined, even when all virtual display
composition is done by GLES, the HWC will be forced to copy from the
GLES framebuffer to the output buffer. On some hardware this allows
HWC to do format conversions that would otherwise have to be done by
the consumer, with worse power and/or performance.

Bug: 8316155
Change-Id: If980ecc589f138cef063eafa757f7f748196713e
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
1e27ba234c5bfd4f6535ee221a6c20407a50f868 27-Sep-2013 Jesse Hall <jessehall@google.com> Use implementation-defined format when HWC writes to output buffer

When GLES isn't writing to the output buffer directly, request an
implementation-defined format with minimal usage flags, leaving the
format choice up to gralloc. On some hardware this allows HWC to do
format conversions during composition that would otherwise need to be
done (with worse power and/or performance) by the consumer.

Bug: 8316155
Change-Id: Iee6ee8404282036f9fd1833067cfe11dbadbf0bf
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
b716e57048e945d5bceda33c2434c65d06464dba 02-Oct-2013 Jesse Hall <jessehall@google.com> Set the outbuf acquire fence after we actually have it.

In GLES-only mode, we don't have the outbuf acquire fence until after
GLES composition is done for the frame. We were setting the fence in
HWC's state immediately after dequeueing the buffer from the consumer,
before GLES had started. This fence got passed through HWC and on to
the consumer, so the consumer was reading the buffer before GLES was
done writing to it.

Now we update HWC's state just before set(), when we know we have the
right fence.

Bug: 11000763
Change-Id: Iea9db4c69634c352dc2d600f0bdb6bef2a432636
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
6da15f46f5f8b38e31384d641f8d3db2c3c6ea30 26-Sep-2013 Mathias Agopian <mathias@google.com> fix crashers with wifi/virtual displays

Bug: 10647742
Change-Id: I4b8ed9da52ef95af3a3b3a04b98514a3776a674d
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
365857df8b94c959dea984a63013f6e7730ef976 12-Sep-2013 Mathias Agopian <mathias@google.com> Make sure do disconnect from a BQ when its client dies.

Bug: 5679534

Change-Id: If447e8673df83fe0b1d6210641e0a48522501a53
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
8db92553e9e6263cd41eaf1a1ebc9e3f88f92b5f 30-Aug-2013 Jesse Hall <jessehall@google.com> Force async behavior for the virtual display output BufferQueue

Bug: 10551087
Change-Id: I40bbb2b87d64420939a0ea309254f281437dab56
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
028dc8f2d72bc7cd4fbe7808781443125a742f78 21-Aug-2013 Jesse Hall <jessehall@google.com> Provide HWC prepare with a valid output buffer

We weren't dequeing and setting the output buffer until just before
set(). This didn't allow HWC to make decisions in prepare() based on
the output buffer format, dimensions, etc.

Now we dequeue the output buffer at the beginning of the composition
loop and provide it to HWC in prepare. In GLES-only rendering, we may
have to cancel the buffer and acquire a new one if GLES requests a
buffer with properties different than the one we already dequeued.

Bug: 10365313
Change-Id: I96b4b0a851920e4334ef05080d58097d46467ab8
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
3c25621ad7d13f64d3ab95a27fa970fbc9998f73 16-Aug-2013 Andy McFadden <fadden@android.com> Re-enable frame dropping for non-auto timestamps

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
db89edc94bd2a78226b407f9f7261e202e7fa325 02-Aug-2013 Mathias Agopian <mathias@google.com> All consumers now take an IGraphicBufferConsumer instead of a BufferQueue

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
7cdd786fa80cf03551291ae8feca7b77583be1c5 19-Jul-2013 Mathias Agopian <mathias@google.com> Make ANW.setSwapInterval(0) work again

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
595264f1af12e25dce57d7c5b1d52ed86ac0d0c9 17-Jul-2013 Mathias Agopian <mathias@google.com> BufferQueue improvements and APIs changes

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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
bce7611e8e4514026bf12f96baaf9168f6d5894e 16-Jul-2013 Jesse Hall <jessehall@google.com> Fix build -- update for function signature change

Change-Id: I9c2448d5853c69ec7e962847fdaba9a99906cc42
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
38efe86d9459cf5c96a24a34cc5cbf31fdba7e19 07-Apr-2013 Jesse Hall <jessehall@google.com> Rewrite VirtualDisplaySurface

The previous implementation assumed that the HWC could read and write
the same buffer on frames that involved both GLES and HWC composition.
It turns out some hardware can't do this. The new implementation
maintains a scratch buffer pool to use on these mixed frames, but on
GLES-only or HWC-only frames still does composition directly into the
output buffer.

Bug: 8384764
Change-Id: I7a3addb34fad9bfcbdabbb8b635083e10223df69
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
e737c11cd83a449d9a544c5c6d4e0dfd42250a56 07-May-2013 Jesse Hall <jessehall@google.com> Remove experimental HWC virtual display support

Bug: 8384764
Change-Id: I97b52ed83ad85466bd91cb9291308994048568a1
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
2ba647e9f5249d9ed97739d29d879064e31ba34a 04-Apr-2013 Jesse Hall <jessehall@google.com> Actually set the virtual display output buffer.

Bug: 8316155
Change-Id: Ida1ac47e5a932fdaad3ec862e121cfe55d255699
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
ffe1f19ca9707f84cb9fdb06209bf36cd8c2ef0a 22-Mar-2013 Jesse Hall <jessehall@google.com> Fix virtual displays for HWC<=1.1

If we're using a HWC that doesn't support virtual displays, or we have
more virtual displays than HWC supports concurrently, the
VirtualDisplaySurface should simply be a passthrough from source
(GLES) to sink.

This change also tries to distinguish between display types and HWC
display IDs a little better, though there's more to do here. Probably
needs a higher-level rethink; it's too error-prone now.

Bug: 8446838
Change-Id: I708d2cf262ec30177042304f174ca5b8da701df1
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
851cfe834295224cd64bdd499872b95b19c4de8c 20-Mar-2013 Jesse Hall <jessehall@google.com> Isolate knowledge that fb target == output buffer

HWComposer didn't allow the virtual display output buffer to be set
directly, instead it always used the framebuffer target buffer.
DisplayDevice was only providing the framebuffer release fence to
DisplaySurfaces after a commit.

This change fixes both of these, so both HWComposer and DisplayDevice
should continue to work if VirtualDisplaySurface changes to use
separate framebuffer and output buffers. It's also more correct since
VirtualDisplaySurface uses the correct release fence when queueing the
buffer to the sink.

Bug: 8384764
Change-Id: I95c71e8d4f67705e23f122259ec8dd5dbce70dcf
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
13f01cbdbd34779a234bc674df79e23672fd5c0b 20-Mar-2013 Jesse Hall <jessehall@google.com> Pass sp<Fence>s around instead of file descriptors

Change-Id: Iac70584a2207940730e8f803a543e4e9a4000c47
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
7414965606f82ac2bcace5d3e2c8a4810517bf1e 20-Mar-2013 Jesse Hall <jessehall@google.com> Release virtual display buffer immediately after HWC set

Previously we only queued a virtual display buffer to the sink when
the next frame was about to be displayed. This may delay the "last"
frame of an animation indefinitely. Now we queue the buffer as soon as
HWC set() returns and gives us the release fence.

Bug: 8384764
Change-Id: I3844a188e0f6ef6ff28f3e11477cfa063a924b1a
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
80e0a397a4712666661ecc629a64ec26e7f6aac3 15-Mar-2013 Jesse Hall <jessehall@google.com> Add BufferQueueInterposer and use it for virtual displays

BufferQueueInterposer allows a client to tap into a
IGraphicBufferProducer-based buffer queue, and modify buffers as they
pass from producer to consumer. VirtualDisplaySurface uses this to
layer HWC composition on top of GLES composition before passing the
buffer to the virtual display consumer.

Bug: 8384764
Change-Id: I61ae54f3d90de6a35f4f02bb5e64e7cc88e1cb83
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
99c7dbb24994df2f3e175f7b25dd2c9dd92a72f0 14-Mar-2013 Jesse Hall <jessehall@google.com> Add DisplaySurface abstraction

DisplayDevice now has a DisplaySurface instead of using
FramebufferSurface directly. FramebufferSurface implements
DisplaySurface, and so does the new VirtualDisplaySurface class.
DisplayDevice now always has a surface, not just for virtual displays.

In this change VirtualDisplaySurface is just a stub; buffers still go
directly from GLES to the final consumer.

Bug: 8384764
Change-Id: I57cb668edbc6c37bfebda90b9222d435bf589f37
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp