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
since the transparent region hint really depends on the
content of the window containing the SurfaceView
(it's calculated by the view hierarchy based on
overlapping views), it makes sense to latch it only when
the content of the window (the app) changes.
This should help fixing drawing artifacts when changing the
layout of a window containing a SurfaceView.
Bug: 8511430
Change-Id: Ic3aa668495293cb4d82a2cd7dcf3b6a337287678
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
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
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
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
some drivers don't support this yet, so we use a system
property to enable the glReadPixels "workaround" for them:
ro.bq.gpu_to_cpu_unsupported=1
Change-Id: I74d6a3a8f0cee8d5a507b72c760cf247e39195e0
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
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
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
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
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
the purgatory list wasn't needed anymore; in fact it had no effect as
buffer life-time management is now handled by the BufferQueue.
For QueuesToWindowComposer we keep a list of wp<> on the IBinder
for IGraphicBufferProducers we hand over to clients so we can
easily check if an IGraphicBufferProducer is ours. We clean-up the
list when our IGraphicBufferProducer are destroyed.
Bug: 8349142
Change-Id: I1aa06652ade8c72d0004a3f5e6c3d6e8a82fc2ae
since we're using glReadPixels(), we only need to use
the width (as opposed to the stride) of the source
screenshot.
Bug: 8374664
Change-Id: I145c80f4fff5444df7c77c4f52e70a7203caddbd
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
We were using the "visible layer list" when taking screenshots,
which doesn't work when a layer is behind other opaque layers
and therefore hidden.
We fix this by using the full layer list, filtered by the
layerstack of the display we're looking at.
Bug: 7552304
Change-Id: I4b6f77e5511aea94f8d218975b6e22738e7e5d5b
older drivers which are doing implicit synchronization need this
or they could deadlock.
Bug: 8341885
Change-Id: Icd980a6be16071678d6151e34725b3c1c547d7ee
* changes:
Get rid of LayerBase.
Make LayerDim a regular Layer instead of a LayerBase
fold LayerBaseClient into LayerBase
Remove support for ScreenshotLayer
The functionality of LayerBase and Layer is folded
into Layer. There wasn't a need for this abstraction
anymore.
Change-Id: I66511c08cc3d89009ba4deabf47e26cd4cfeaefb
- SurfaceFlinger now supports to take a screenshot
directly into an IGraphicBufferProducer
- reimplement the IMemoryHeap screenshot on top
of the above
- reimplement LayerScreenshot such that its
BufferQueue is directly used as the destination
of the screenshot. LayerScreenshot is now a thin
wrapper around Layer
Bug: 6940974
Change-Id: I69a2096b44b91acbb99eba16f83a9c78d94e0d10
When a display is added, initialize it to use an empty layer stack, so
if it is somehow visible it will show black. It will be assigned the
real layer stack -- along with a projection and other properties -- by
window manager soon. Normally a display remains blanked until window
manager has decided what to show on it, but for HDMI connected at boot
that isn't currently the case.
Bug: 7258935
Change-Id: Ic9bb25f7a9b8d9d3772b097ab1d6fa03bc8780a1
