Commit Graph

43 Commits

Author SHA1 Message Date
Dan Stoza
dd883c0b08 libgui: Enable -Weverything and -Werror
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:
  d723bd7669
  00d504c06e
  429ba89cd2

Change-Id: I034abec27bf4020d84af60d7acc1939c59986dd6
2014-12-05 14:59:29 -08:00
Dan Stoza
01049c8321 Enable clang for libui/libgui/surfaceflinger
Enables clang and C++11 for libui/libgui/surfaceflinger, and
eliminates all compile-time warnings.

Change-Id: Ie237fdb5ae44f2bfcddaa884f9c65ec3f08ae50f
(cherry picked from commit f10c46ef85)
2014-12-04 17:56:17 -08:00
Michael Lentine
fd9d183cd8 Build fix to use the correct source.
Change-Id: If36710be600dd0e15c31682e0343f281baa55627
2014-07-30 15:39:17 -07:00
Michael Lentine
47e45405d1 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
2014-07-30 14:36:25 -07:00
Jesse Hall
24cd98eef8 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
2014-07-14 12:18:00 -07:00
Dan Stoza
29a3e90879 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
2014-06-20 13:13:57 -07:00
Jesse Hall
0b63cd105c 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
2014-05-01 10:37:33 -07:00
Dan Stoza
fb39827ebc Merge "BufferQueue: Increase max slots from 32 to 64" 2014-04-21 16:11:22 +00:00
Dan Stoza
febd4f4f46 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
2014-04-18 11:40:14 -07:00
Dan Stoza
d9822a3843 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
2014-04-15 10:27:25 -07:00
Dan Stoza
f0eaf25e92 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
2014-03-31 14:10:07 -07:00
Dan Stoza
b9b088375d Remove deprecated BufferQueue constructor
Bug: 13415624
Change-Id: I9fe15e45daa7351f1db34ee75bfee6f19cb347d3
2014-03-18 10:08:44 -07:00
Jesse Hall
73ed82f809 Merge "Add sideband streams to BufferQueue and related classes" 2014-03-13 20:28:17 +00:00
Dan Stoza
88a459a9b3 VirtualDisplaySurface: no attach/detach support
Change-Id: I630dd6e352940318c33a4e072d2f33a6ec58c556
2014-03-12 09:34:36 -07:00
Jesse Hall
399184a4cd 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
2014-03-11 12:23:14 -07:00
Dan Stoza
9f3053de78 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
2014-03-10 16:45:38 -07:00
Dan Stoza
7143316af2 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
2014-02-04 16:46:54 -08:00
mayank parshar
fdfde88d0b SurfaceFlinger: mFbProducerSlot initailization
b/12487813

SurfaceFlinger crash is observed during simulation of
Secondary display

Note: change 14e8b01a76
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>
2014-01-28 09:33:33 -08:00
mayank parshar
b988f85fc4 SurfaceFlinger: mFbFence initialization
MobC00383030
b/12487813

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

Note: change 14e8b01a76
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>
2014-01-25 06:35:24 -08:00
Jesse Hall
14e8b01a76 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
2013-11-07 12:37:13 -08:00
Jesse Hall
497ba0e085 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
2013-11-04 16:43:03 -08:00
Jesse Hall
c354effe97 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
2013-10-25 17:48:09 +00:00
Naseer Ahmed
6a968462f9 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
2013-10-17 13:57:58 -07:00
Jesse Hall
1e27ba234c 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
2013-10-17 11:20:22 -07:00
Jesse Hall
b716e57048 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
2013-10-01 17:25:20 -07:00
Mathias Agopian
6da15f46f5 fix crashers with wifi/virtual displays
Bug: 10647742
Change-Id: I4b8ed9da52ef95af3a3b3a04b98514a3776a674d
2013-09-25 20:40:07 -07:00
Mathias Agopian
365857df8b Make sure do disconnect from a BQ when its client dies.
Bug: 5679534

Change-Id: If447e8673df83fe0b1d6210641e0a48522501a53
2013-09-16 16:15:21 -07:00
Jesse Hall
8db92553e9 Force async behavior for the virtual display output BufferQueue
Bug: 10551087
Change-Id: I40bbb2b87d64420939a0ea309254f281437dab56
2013-08-29 16:09:11 -07:00
Jesse Hall
028dc8f2d7 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
2013-08-20 16:35:32 -07:00
Andy McFadden
3c25621ad7 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
2013-08-16 15:15:16 -07:00
Mathias Agopian
db89edc94b 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
2013-08-06 20:05:36 +00:00
Mathias Agopian
7cdd786fa8 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
2013-07-19 17:38:01 -07:00
Mathias Agopian
595264f1af 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
2013-07-18 22:28:18 -07:00
Jesse Hall
bce7611e8e Fix build -- update for function signature change
Change-Id: I9c2448d5853c69ec7e962847fdaba9a99906cc42
2013-07-16 13:46:20 -07:00
Jesse Hall
38efe86d94 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
2013-07-15 13:59:41 -07:00
Jesse Hall
e737c11cd8 Remove experimental HWC virtual display support
Bug: 8384764
Change-Id: I97b52ed83ad85466bd91cb9291308994048568a1
2013-05-07 11:58:47 -07:00
Jesse Hall
2ba647e9f5 Actually set the virtual display output buffer.
Bug: 8316155
Change-Id: Ida1ac47e5a932fdaad3ec862e121cfe55d255699
2013-04-04 12:59:37 -07:00
Jesse Hall
ffe1f19ca9 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
2013-03-22 15:27:58 -07:00
Jesse Hall
851cfe8342 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
2013-03-22 15:27:57 -07:00
Jesse Hall
13f01cbdbd Pass sp<Fence>s around instead of file descriptors
Change-Id: Iac70584a2207940730e8f803a543e4e9a4000c47
2013-03-22 09:56:58 -07:00
Jesse Hall
7414965606 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
2013-03-20 11:16:55 -07:00
Jesse Hall
80e0a397a4 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
2013-03-18 14:21:45 -07:00
Jesse Hall
99c7dbb249 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
2013-03-18 14:21:16 -07:00