Commit Graph

209 Commits

Author SHA1 Message Date
Mark Salyzyn
92dc3fc52c native frameworks: 64-bit compile issues
- Fix format (print/scanf)
- Suppress unused argument warning messages (bonus)

Change-Id: I05c7724d2aba6da1e82a86000e11f3a8fef4e728
2014-03-12 13:12:44 -07: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
19e872912a Implement per-display EGLConfig and configless EGLContext
Bug: 12230666
Change-Id: Icca608b108cbdcab9cf01a9236d8cdbda000a836
Signed-off-by: Jesse Hall <jessehall@google.com>
2013-12-23 21:53:39 -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
356c23865d Merge "Provide virtual display output buffer to HWC in prepare" into klp-dev 2013-11-07 04:43:20 +00:00
Jesse Hall
f7a675837b Provide virtual display output buffer to HWC in prepare
We were already making sure the HWComposer class had the handle before
prepare, but it wasn't passing the handle along to HWC as intended.

Partial fix for bug: 11430248
Change-Id: I25f672c4fdfaa6a81fe0acb24d9ad05153ee17dc
2013-11-05 16:27:14 -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
8e26b28be6 Filter out vsync events from HWC with duplicate timestamps
Bug: 11220224
Change-Id: I4efe0b66ea8969bf0ec3c4fcb325d354c8a0c315
2013-10-14 15:34:00 -07:00
Jamie Gennis
faf77cce9d SurfaceFlinger: SW-based vsync events
This change adds the DispSync class, which models the hardware vsync event
times to allow vsync event callbacks to be done at an arbitrary phase offset
from the hardware vsync.  This can be used to reduce the minimum latency from
Choreographer wake-up to on-screen image presentation.

Bug: 10624956
Change-Id: I8c7a54ceacaa4d709726ed97b0dcae4093a7bdcf
2013-10-07 17:59:53 -07:00
Jesse Hall
93573e91c2 Merge "Treat composition frames with no layers as using GLES composition" into klp-dev 2013-10-02 14:54:03 +00: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
Jesse Hall
d05a17fbb3 Treat composition frames with no layers as using GLES composition
When there are no window layers for a display, SurfaceFlinger clears
the undefined region using GLES. Some of the places that check for
GLES composition weren't considering this special case, in particular:

- We were skipping the eglSwapBuffers() on these frames.
- We were putting VirtualDisplaySurface in HWC-only composition mode.

This change centralizes the logic for this special case.

Bug: 10957068
Change-Id: I2deaf2ed101e8ea76708862a6bb67751b6078794
2013-09-30 17:08:28 -07:00
Mathias Agopian
86206b41b2 Merge "fix initialization of framebuffer target crop rect on hwc 1.3" into klp-dev 2013-09-26 19:41:22 +00:00
Mathias Agopian
8f63c2049b fix initialization of framebuffer target crop rect on hwc 1.3
Bug: 10936771
Change-Id: If283e5e231ca34b93e0b1784bb4e8e4c7bfd75de
2013-09-25 20:44:34 -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
Mathias Agopian
bef42c50eb handle several vsync signal correctly
Change-Id: I34935d2197ce8e914fef2f110896e47b44225ad2
2013-08-21 17:45:46 -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
Jesse Hall
353ddc6e77 Fix HWComposer dumping of float source crops
Change-Id: I45a9344b5fab17ccb54bebd01382d738a03860e6
2013-08-20 16:11:50 -07:00
Andy McFadden
90f59bf9eb Merge "Re-enable frame dropping for non-auto timestamps" into klp-dev 2013-08-19 14:27:28 +00: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
Jesse Hall
9e663de4fe Use new HWC display type/count constants.
Change-Id: I774d0c68906ac6dc69268f708c30a6b0868b8816
2013-08-16 14:28:37 -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
ad678e18b6 single buffer mode for BufferQueue
Bug: 9891035
Change-Id: Id1ab5f911a6dc4c1d8235e65775b3d3635231ad4
2013-07-26 18:45:02 -07: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
3bc3840888 Merge "Rewrite VirtualDisplaySurface" 2013-07-16 20:29:30 +00: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
Andy McFadden
c33f9a76b5 Merge "Pay attention to buffer timestamps" 2013-07-11 14:40:45 +00:00
Andy McFadden
1585c4d9fb Pay attention to buffer timestamps
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
2013-07-10 15:38:40 -07:00
Mathias Agopian
6b44267a3b fix SF buffer cropping
When a buffer had a crop (meaning its content is scaled to the window size)
and a window crop was defined, the resulting crop couldn't be expressed
properly because h/w composer's API was limited to integers, since
this is fixed in h/w composer 1.3, we take adventage of this to
make sure we get the correct crop.

this bug could result in the buffer being scaled by an incorrect ratio and
be slightly offset; moreover, it would produce different results from the
GL code path, which is always correct.

Change-Id: I8e20e00b6e26177d14f4ab4d2cd581e26c818892
2013-07-10 15:08:29 -07:00
Lajos Molnar
c5d7b7d323 BufferQueue: track buffer-queue by instance vs. by reference
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
2013-05-23 22:17:54 +00:00
Mathias Agopian
2381033ad0 am e6eef6c1: am ea74d3b7: make the warning timout of Fence::waitForever() implicit and longer
* commit 'e6eef6c136b007f3a7e1e19884875b855c0c5f95':
  make the warning timout of Fence::waitForever() implicit and longer
2013-05-17 10:18:45 -07:00
Mathias Agopian
ea74d3b78d make the warning timout of Fence::waitForever() implicit and longer
- 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
2013-05-16 18:15:57 -07:00
Jesse Hall
c0db61966a am dda42952: am 64f3b2fd: Merge "Remove experimental HWC virtual display support" into jb-mr2-dev
* commit 'dda4295221f831560ca9d554cd9b7be1c672d0b6':
  Remove experimental HWC virtual display support
2013-05-08 15:05:15 -07:00
Jesse Hall
e737c11cd8 Remove experimental HWC virtual display support
Bug: 8384764
Change-Id: I97b52ed83ad85466bd91cb9291308994048568a1
2013-05-07 11:58:47 -07:00
Mathias Agopian
74d211ae26 clean-up/simplify all dump() APIs
remove the scratch buffer parameter and use
String8::appendFormat() instead.

Change-Id: Ib96c91617c8e7292de87433d15cf6232b7d591b0
2013-04-22 21:51:28 +02:00
Jesse Hall
1df59c93fe Merge "Tell HWComposer the dimensions of virtual displays" into jb-mr2-dev 2013-04-06 03:32:19 +00:00
Jesse Hall
d5e345b0cf Merge "Actually set the virtual display output buffer." into jb-mr2-dev 2013-04-06 03:31:49 +00:00
Jesse Hall
1c569c4d45 Tell HWComposer the dimensions of virtual displays
HWComposer queries the HWC for dimensions of physical displays, but
can't do that for virtual displays. The dimensions are used to set the
display frame of the framebuffer target layer passed to HWC, and
implicitly the dimensions of the virtual display.

Bug: 8316155
Change-Id: I9cbd2530d2fa878f86128a1472def520b5d694a5
2013-04-05 14:38:52 -07:00
Jesse Hall
6d5b8e600e Merge "Clean up HWC state when releasing a DisplayDevice" into jb-mr2-dev 2013-04-04 22:36:10 +00:00
Jesse Hall
2ba647e9f5 Actually set the virtual display output buffer.
Bug: 8316155
Change-Id: Ida1ac47e5a932fdaad3ec862e121cfe55d255699
2013-04-04 12:59:37 -07:00
Mathias Agopian
33ceeb3258 Fix include paths
Change-Id: If5350a3de995cc0cb1afea067e7ce168bc00d3f5
2013-04-01 16:54:58 -07:00
Jesse Hall
02d86567d9 Clean up HWC state when releasing a DisplayDevice
DisplayDevices can be released when DisplayManager removes them from
the display list, or (for virtual displays) when the surface is set to
NULL. We were only cleaning up HWC resources associated with the
display in the first case.

Bug: 8384764
Change-Id: Id3d226dd7178fbe6d0a2ac4e2660b864ee073de3
2013-03-27 14:58:09 -07:00