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
Vsync array size is specified as HWC_DISPLAY_TYPES_SUPPORTED whose
value luckily happens to be 2. That enum is actually used for querying
hwc for the number of displays supported.
The implementation file EventThread.cpp correctly accesses the array
upto HWC_NUM_DISPLAY_TYPES
Change-Id: I36e3f0913e7d6fda7bbf4449c1fb32c7f18bb934
Signed-off-by: Amara Venkata Mastan Manoj Kumar<manojavm@codeaurora.org>
Signed-off-by: Saurabh Shah <saurshah@codeaurora.org>
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
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
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
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: I2be85660d9dc65d239d68f6d3ab3c973c13b34cc
it now displays the reported trigger mode properly, as well as
the number and type of the last received data
Change-Id: I2ff64b32ab71f1332bc2e09671c8c02bb9550490
this is the first step to add support for GLES 2.x, this
change breaks the dependency of SF on GLES 1.x by moving
all operation into their own class.
Bug: 8679321
Change-Id: I0d2741eca2cefe67dfd9cf837cac10c4d126928b
Allow releasing a buffer acquired in the past.
Change-Id: I3f27f1caec109c1a47286fc4d2235c6e1afe9022
Signed-off-by: Lajos Molnar <lajos@google.com>
Bug: 9516405
- most methods on Layer didn't need to be virtual
- more consistency in naming drawing/current state
Change-Id: Ieb7b4951b40fc673b807994ed21ae4aea7281068
generally the last reference to a Layer is released in commitTransaction()
with mStateLock held. Layer itself only holds weak references to Client,
however, ~Layer() briefly promotes this weak reference -- during that time
the all other strong references to that Client go away, ~Layer is left with
the last one... then hell breaks loose as ~Client is called, which in turn
needs to acquire mStateLock.
We fix this by holding a temporary copy of the drawing state during
the transaction so that the side-effects of copying the current
state into the drawing state are seen only after mStateLock has
been released.
Bug: 9106453
Change-Id: Ic5348ac12283500ead87286a37565e8da35f1db2
initialize the system covariance matrix with non-zero
values for the gyro-bias part. this improves the initial
bias estimation speed significantly.
the initial covariance matrix should be small because the drift
changes slowly. the real problem is that we're not starting with
a good estimate of the drift, which this algorithm relies on.
so with this revert, it'll take a while for the drift to be estimated
but it won't be unstable.
Change-Id: Id5584bc114a2390d507643b2451b2650c1b90721
we used to estimate the gyro rate and deduce the period from that
but it turns out this is causing problems.
Bug: 5192288
Change-Id: I8ca826d0e11e488587bcaa1720de99e92b82f191
To keep the code readable now that we have four different texenv
configurations, this change separates the decisions about what
configuration to use from the GL calls to set up the configuration.
Bug: 8963244
Change-Id: Ia07a306a7809ba8f93493d0160ccbd509e948581
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
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
1) "google" sensors are now reporting AOSP as the vendor string
2) don't expose the system's sensor fusion if the HAL provides it
3) use uncalibrated gyro if availble for the system's sensor fusion
Change-Id: I25140436cdb29d55e39fd6fbbf8c44a410a83d5c
- 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
If an invalid display device is detected during surface composition
(e.g., a simulated secondary display is removed), abort the
composition.
Change-Id: Ia6afb2e287882d8ae0614eb25463d3f85b687adf
until now it was only used to discard a layer entirely.
we're now reducing the size of the layer if it is still
visible, if possible.
this works for instance when a surfaceView is used and
only the menu bar is displayed over it.
Change-Id: I3f5527c5cd1e69ecc968272c8948f1513ada8c55
this allows us to render into a buffer with a
pixelformat of our own choice; this is much faster
on all platform.
Bug: 8582615
Change-Id: I61298fc8e43fa6f92044c5123955cb5c7897dab7
colorize a bit the output of dumpsys SurfaceFlinger to
make it easier to read. Right now it will bold the
title of each section and use green for the name of
each layer.
Change-Id: I0d9f18d115401cb45109d244ef3a278481f68cc6
