sensorservice would deadlock if for some reason
a sensor failed to enable.
simplifed the code a bit, and made it behave a little
closer to mr1.1 -- I couldn't convince myself that
some changes in how locks were used were correct.
Bug: 9794362
Change-Id: I6110f5dbb67e543f1c71d127de2299232badb36a
because surfaceflinger handles screenshot in a different
thread from the binder thread that requested it and because
the IGraphicBufferProducer is a synchronous interface
calling back into the system server; it is possible for
the latter to run out of binder threads (b/c it holds
a lock while calling into SF).
The solution is to make sure all calls on IGraphicBufferProducer
happen on the incoming binder thread. We achieve this by creating
a IGBP wrapper which is given to the screenshot code.
Bug: 8734824
Change-Id: Ife2441c7322e51ecfb20e0df03dacf6bce49578e
- 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
Auto disabled sensors get auto disabled after trigger.
An activation after this wasn't working because the
state was not being reset.
b/8609561
Change-Id: If72c9f27345e91671d7ad0a7a066f6dc3d255b78
this mimics the code we used for the size. basically we need to
also update the "current state" because it gets copied to the
"drawing state" when a transaction occurs, and it would
"undo" our change.
Bug: 8511430
Bug: 8581533
Change-Id: I08c02abbf21b7f168f7124cd14ee717d7d3d502c
1. Some sensors can wake up the AP. Add wakelocks.
2. Handle backward compatibility for rotation vector
heading accuracy.
3. Cleanup auto disabled sensors.
4. Fix race condition between enable and dispatch.
Change-Id: I39dddf12e208d83cd288201986ee994312555820
this affects devices that need a glReadPixels(). We use
a FBO instead of a GlConsumer as an intermediate render target, this
saves 2 calls to eglMakeCurrent().
On Galaxy Nexus this allows us to go from ~135ms to ~35ms for
recent's screenshots.
Bug: 8582615
Change-Id: I6b25291ecc235f1927579bbb2db3c731e985c6e8
When the screen is turned off, the current stack is set to -1. This causes
logic in iSurfaceFlinger's handleTransactionLocked() function to fail to
match the current stack, and the latest orientation is not set into the
layer. This causes BufferQueue, later, to potentially set an obsolete
transformHint on a created surface (such as in the case with ImageWallpaper's
Egl surface, in the bug below).
The fix is to note this situation and use a default value for the DisplayDevice,
which should have the current orientation information.
Issue #8508397 ImageWallpaper sometimes rendered in wrong orientation causing a ~30-40% drop in graphics performance
Change-Id: Ibae15d73b289a8343c67f4f6bb77fdf11dd95ee7
SF transactions were always handled on VSYNC which allowed
the screenshot to sneak-in between closing the transaction
and vsync (before it's latched), resulting in a screenshot
with the previous state.
we now always force transactions to happen immediately
before screenhots.
Bug: 7552304
Change-Id: I0afc86b7e8366173daff5b9988bbb4d2a0f43860
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
