when an app dies, make sure to disable all sensors that process
is connected to, regardless of wether this was the LAST connection
to this sensor.
Change-Id: I9c72b1792eee03815304674d5c2f25b5270e4748
The cut-off frequency of the lowpass filter was too high
for the sampling rate used by DELAY_NORMAL.
Now we use the same filters used for the gravity vector
(cascaded biquad at 1.5 Hz)
Change-Id: I319dc4f449a3abd553d61b196a9ddcf7782f912d
whether a physical sensor needed to be active or not was managed by
a simpe reference counter; unfortunatelly nothing prevented it to
get out of sync if a sensor was disabled more than once.
sensorservice already maintainted a list of all the "clients"
connected to a physical sensor; we now use that list to determine if
a sensor should be enabled. This can never be "out-of-sync" since
this is the only data structure linking a sensor to a user of that
sensor.
also removed the isEnabled() method, which was never used and
implemented wrongly (since it didn't take into account that a sensor
could be disabled for a client but not of another).
Change-Id: I789affb877728ca957e99f7ba749def37c4db1c7
Most accelerometers have 8-bits accuracy so we beed to
reject 48dB in thestop-band, which requires a 4-th order
filter at the cut-off frequency we're using.
Change-Id: Ic00421d38d751641f86b1f3ad7663e6b44a91198
- upadte documentation for rotation vector
- update method dealing with rotation vector to deal with 4 components
- virtual rotation-vector sensor reports all four components
- improve SensorManager documentation layout
Whent he 4-th component of the rotation-vector is present, we can save
a square-root when computing the quaternion or rotation matrix from it.
Change-Id: Ia84d278dd5f0909fab1c5ba050f8df2679e2c7c8
indeed, by construction of the rotation matrix, it is
guaranteed to have a length of 1.
moreover, the normalization code was missing a square-root,
fortunatelly, since the length is 1, this didn't cause any
damage (since sqrt(1) = 1).
Change-Id: I9facd668caaf5bb3bfccb139ab872f2bb2066365
Rework sensorservice to allow "virtual sensors", that is
sensors that report a synthetized value based on real sensors.
the main change to sensorservice is around managing which real
sensor need to be activated and which rate to use.
The logic for all this has been moved into SensorDevice, which
essentially wraps the sensor HAL but adds two features to it:
- it keeps track of which sensors need to be activated
- it keeps track of what rate needs to be used
For this purpose an "identity" is associated with each real sensor
activation, so we can track them.
On start-up we check for gravity, linear-acceleration and
rotation-vector sensors, if they're not present in the HAL, we
synthetize them in sensor-service.
Change-Id: I841db2c1b37ef127ed571efa21732ecc5adf1800
the per-connection state assumed the main sensorservice
lock was held during access. This is however not true while
pre-processing the events just before sending them to clients.
Therefore, there was a small window during which this state
could be modified while being used.
we now have an internal lock that protects this state.
Change-Id: I594680f20f09d6a4f1f38f093a1d3f650dcef1be
We only recorded the last received event (which is needed when a sensor
is activated on a connection) when there was some connection active.
This should fix an issue where sometimes the light sensor doesn't
return an event whent activated.
we also didn't need to hold the main lock while dispatching events
to clients.
Change-Id: I6c6386c040051ce205e3c0516c678e0603fa45e1
the increased maximum rate is needed for proper gyro integration, current gyro
parts can sample at up to 800Hz
Change-Id: Ide75f6d5bc7a0fdafeb2dafd72db39e7afb9e794
As part of this change, consolidated and cleaned up the Looper API so
that there are fewer distinctions between the NDK and non-NDK declarations
(no need for two callback types, etc.).
Removed the dependence on specific constants from sys/poll.h such as
POLLIN. Instead looper.h defines events like LOOPER_EVENT_INPUT for
the events that it supports. That should help make any future
under-the-hood implementation changes easier.
Fixed a couple of compiler warnings along the way.
Change-Id: I449a7ec780bf061bdd325452f823673e2b39b6ae
SensorService now correctly sends the last known
state of a sensor as soon as a new connection is made.
This fixes the issue where, for instance, an application
could wait a long time before getting the light or proximity
sensor initial state.
Change-Id: Ic41392f3626e26c4f15746c7e17c7ecd44bbb10b
remove old sensor service and implement SensorManager
on top of the new (native) SensorManger API.
Change-Id: Iddb77d498755da3e11646473a44d651f12f40281
After a HWC set, each SurfaceFlinger Layer retrieves the release fence
HWC returned and gives it to the layer's SurfaceTexture. The
SurfaceTexture accumulates the fences into a merged fence until the
next updateTexImage, then passes the merged fence to the BufferQueue
in releaseBuffer.
In a follow-on change, BufferQueue will return the fence along with
the buffer slot in dequeueBuffer. For now, dequeueBuffer waits for the
fence to signal before returning.
The releaseFence default value for BufferQueue::releaseBuffer() is
temporary to avoid transient build breaks with a multi-project
checkin. It'll disappear in the next change.
Change-Id: Iaa9a0d5775235585d9cbf453d3a64623d08013d9
The desc.txt file can now mark parts as 'must finish cleanly' by using
'c' as the part line prefix rather than 'p'. If so indicated, if the
bootanimation is asked to quit it will do so only after waiting to
finish that part.
I considered either making init.c service killing smarter or promoting
bootanim to be a bindable service with a requestExit method. However,
these changes are probably too big/risky given our ship date. So
I used a property as a mailbox between SurfaceFlinger and bootanim.
Bug: 6679877
Change-Id: Id7dca22caa50b450fff25ca94f7242d971034f41
When turning the screen off we could have 2 waiters on the
vsync condition: The main vsync waiter as well as one in
onScreenReleased(). We were only signaling the condition though,
so it it would be possible to wake onScreenReleased() without waking
the main vsync thread which would then be stuck in .wait().
We fix this by just using broadcast() when receiving a vsync event.
We also add a broadcast() to signal when the state of
mUseSoftwareVSync changes. This is important particularly for
the transition from hardware to software vsync because the main
vsync waiter might have observed mUseSoftwareVSync == false
and decided to block indefinitely pending a hardware vsync
signal that will never arrive.
Removed a potentially deadlocking wait for a signal in
onScreenReleased(). The function was trying to wait for the last
vsync event from the hardware to be delivered to clients but there
was no guarantee that another thread would signal it to wake up
again afterwards. (As far as I can tell, the only other other
thread that might wake it up at this point would be a client
application issuing a vsync request.) We don't really need to wait
here anyhow. It's enough to set the mUseSoftwareVSync flag,
wake up the thread loop and go. If there was a pending vsync
timestamp from the hardware, then the thread loop will grab
it and use it then start software vsync on the next iteration.
Bug: 6672102
Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
The acquire and release fences aren't yet used; this is just support
for the new version and temporary backwards compatibility for older
versions.
Change-Id: Ia5ccc05a97c86f649042b9a35e11042fa0187e84
HWComposer must abstract the HWC HAL entirely, so that the
HAL can continue to evolve (and break binary compatibility)
without breaking SurfaceFlinger. The HWC data structure had
leaked outside of HWComposer, this is now fixed.
We now have an abstract interface that provide all the
needed functionality, HWCompose provides concrete
implementations of it based on the the HWC version.
Change-Id: I40c4676dc986b682ede5520a1c60efe64037b0bb
SF now has its own implementation of ANW for the
framebuffer and it uses BufferQueue. FramebufferNativeWindow
is now only used by stand-alone apps.
Change-Id: Iddeb24087df62bd92b0f78e391dda9b97ddc859c
this would happen when a resize was pending (ie: we have received
and processed a resize transaction but have not received a buffer
with the right size) and a new transaction came in that didn't
involve a resize, for instance a translate-only transaction.
in this case, we would incorrectly update the drawing state
with the pending size, eventhough we still don't have a buffer
for it.
the solution is quite simple, we never allow the size to propagate
from current to drawing state during the regular transaction processing
(unless we are in fixed-size mode -- meaning we don't need to have
a matching size buffer), this propagation happens later once we
receive the buffer.
Bug: 6624163
Change-Id: I11a97e4b88a7f3a0571ddcfe99c86cb04ce01a4d
SurfaceFlinger will no longer directly synchronize with early suspend.
Instead, PowerManagerService will synchronize with SurfaceFlinger to
ensure that a black frame has been drawn on the display, and then
trigger all early suspend handlers.
Change-Id: I07acdd628440d23fdb69db94319ec5d65d3f4919
this would happen when a window started with size A, was
resized to B and immediately resized to A. In this situation
the erquested and active size would be the same, and SF
would think a transaction wasn't needed.
we fix this by always comparing the requested sizes.
Also, make sure to set mRefreshPending once we're sure
we have succesfully called updateTexImage().
Bug: 6580962
Change-Id: I2c48b4df7f05fd35c9e1d2dd82095b0f3d5a0b6a
this bug introduced recently would happen when the very first
buffer of a surface was rejected for not having the right size
Bug: 6577035
Change-Id: I9fabf20006019f2a6c308be7c7f5c05bdcfd5014
SurfaceFlinger is using this new feature to reject buffers that
don't have the right size.
Bug: 6498869
Change-Id: I8a7250a47db6c082a357b703feb3b9d0fc8d3443
here we just shuffle a bit the code inside lockPageFlip(),
we move the code that handles the buffer size closer to the call
to updateTexImage(). no functionality change.
Change-Id: Ie3193cd86cd32cf3c89532449fd747d145ca0ab6
use a flag instead of pre-committing the "requested" state
to prevent propagation or "requested" to "active", which makes
things a lot clearer when reading the code.
also avoid going through the "resized" code-path when requested
size is equal to "active" size.
Bug: 6498869
Change-Id: I24f893ba0ec5ca06aac5b8da9818989ae7ce4005
The crop is now handled like a resize, it's latched only when we
receive a new buffer in the case we have a resize in the same
transaction.
Bug: 6498869
Change-Id: I9f3cbbe08fb19443899461ec441c714748a4fd1a
This change removes some visible region recomputation that was needed to handle
the SCALING_MODE_FREEZE cropping. We've changed things to use a window crop
from the WindowManager instead, so this is no longer needed.
Bug: 6299171
Change-Id: I32fbc2b689c985837126d8ba3d9a91e79613ffbf
This change adds a crop rectangle specified in window coordinates to the layer
state. The all window pixels outside this crop rectangle are treated as though
they were fully transparent. This change also adds the plumbing necessary for
WindowManager to set that crop.
Change-Id: I582bc445dc8c97d4c943d4db8d582a6ef5a66081
This change makes a change in the crop, scaling mode, transform, or buffer
dimensions trigger a recomputation of the visible regions of a window. With
the new cropping behavior for SCALING_MODE_FREEZE all of these can now affect
the visible region.
Bug: 6470541
Change-Id: I1904e47efbd708e28bf189f637d24dbef65cd41e
This change adss support for applying a buffer crop to layers with the
SCALING_MODE_FREEZE scaling mode. These layers do not scale the image, but
rather treat all pixels outside the crop rectangle as fully transparent.
Change-Id: I762518e56a37aef7747f9b581df2f2589b232c49
Bug: 6299171
This change makes SurfaceFlinger set the filtering-enable on each layer's
SurfaceTexture before querying the texture matrix to use for GLES composition.
Change-Id: I40c3defd73ebf96e3cabb3bfdb1fc97f2036753a
indeed, connect and queueBuffer return the same data, so it's
easier to have them use the same protocol.
Change-Id: I4f9fa3be0a80c9ab0a7a4039b282ae843aab02e1
this seems to hurt performance on some GPU. this change
might negatively affect performance on other GPUs though, but
probably in less time-sensitive cases. If this becomes a
problem it might become necessary to pre-clip the geometry
(so that we don't have to use glScissor).
This improves the rotation animation quite a bit.
Change-Id: I5dbe1286f7ad858ef2c1e1ad9a07ee3f26c0b1f3
this optimization didn't improve performance and in fact
seemed to hurt more than anything else. it also made
things a lot more complex as it introduced edges cases
when switching to/from h/w composer.
Change-Id: Iaafc235e175f5740cd98bff914d706e02ab88bb8
surfaceflinger will now handle each surface post
as soon as possible and handle the composition
itself at VSYNC time as usual.
Change-Id: I6b1ae33fd56062d86e5419ebab8def0ca5803fbf
this prevents the GPU from running when composition
is fully handled by overlays. this should improve
animations a bit.
Change-Id: If4ae584b7a3976e6bdd36e318686ac3940b6b075
Move services/powermanager into frameworks/native so audioflinger can
use it. Note that this is not the same as a PowerManagerService,
which is part of systemserver and handles turning the screen on and
off, etc. This is just a binder interface to allow taking wakelocks.
Change-Id: I6b6a8b41cdbad17e826fda45aab5f059f22fc64e
pdk builds don't have libandroid.so available. Remove it from
projects that aren't actually using it.
Change-Id: I100dc84aaf8160c1062a122ef6d5aec0534d73fa
this could happen after an orientation change. basically
we need to triger a geometry-changed when the very first buffer
is received
Change-Id: I097e411fd6612c18725737cffccdbf6b2af3511c
re-add support for pixelformats L_8, LA_88 and RGB_332 in libui
for backward compatibility.
This may or may not fix 6058926
Bug: 6049685
Change-Id: Ic1b8b4cc994522f7fe664da64c0ef76b98bc6d53
Most of these tests in this directory don't currently build,
but test-surface did build incorrectly by bad luck, using the old API.
test-resize still doesn't build, but when the other build errors
are fixed then it will use the right API.
Change-Id: I388d6d59fe0a2328f352214dcdc28839a24043f0
SF could end-up in an infinite crash-loop during startup if it
was stopped while the screen was off. This happened because
the thread that manages screen blanking was started before
other important pieces of SF were initialized.
Change-Id: I0dded11dbf2395fdd57b673859a7aa0fa9eb32b6
we're seeing UI freezes when window updates and
composition are separated. for now we workaround this
by always doing a composition after window updates on
vsync. triple buffering is reenabled for performance.
Change-Id: I693d705000b7452489bb0b4918fbeadb9879315c
In some situations SF would mark a window as "has a pending update"
but would never process that update because the window is not
visible (fully transparent, hidden by another window, etc...), this
window would then be "stuck" until some other window updated.
Change-Id: Ifa18a9aef3a53f2593b473556702688ae62d9503
recent changes in SF introduced a hang where some windows would
stop being refreshed.
This is an attemp to fix that.
Change-Id: I6aa32ac0d6f1c0a6aea8f6195825dc4f4e6f93f9
we now exit the Display thread on any error happening on these files.
also refactor the code and remove a lot of unused stuff.
Change-Id: I8d080c35b211890ca20ae09fa36fbdccdf5669a8
with this changes, SF transactions are handled as soon as possible
but do not trigger updates. the update is delayed until the next
vsync.
this allows us to work much better without requiring triple-buffering.
Change-Id: I1fa10794d0cf742129f0877698b7b1e1f2ec7401
vsync events were sometimes delivered to connected
client who didn't request them. this happened if
another client requested the delivery and that client
was first in the client list.
also fix the vsync test which didn't request any events as
well as DisplayEventReveiver documentation which was misleading
about the necessity to request vsync events.
Change-Id: Ie990fda3f337f8f0042745c4b2cde67936c45686
--latency-clear [name]
clears the latency data for the specified layer or for
all layers if none is specified
--list
prints the list of all layers regardless of their visibility
Change-Id: I7c07ae020f838c173b98ee50f3fb3e93da78acbb
It is now possible to say:
dumpsys SurfaceFlinger --latency
to print latency information about all windows
dumpsys SurfaceFlinger --latency window-name
to print the latency stats of the specified window
for instance: dumpsys SurfaceFlinger --latency SurfaceView
The data consists of one line containing global stats, followed by
128 lines of tab separated timestamps in nanosecond.
The first line currently contains the refresh period in nanosecond.
Each 128 following line contains 3 timestamps, of respectively
the app draw time, the vsync timestamp just prior the call to set and
the timestamp of the call to set.
Change-Id: Ib6b6da1d7e2e6ba49c282bdbc0b56a7dc203343a
Some implementations of NPOT, particular those derived from core
GLES2, require the wrap mode to be CLAMP_TO_EDGE. Set the required
wrap mode for the screenshot texture so it passes the completeness
check.
Change-Id: I735016123e4acaf54b40d1435bd70281cef88a31
Several source files privately defined macros LIKELY and UNLIKELY in terms
of __builtin_expect. But <cutils/compiler.h> already has CC_LIKELY and
CC_UNLIKELY which are intended for this purpose. So rename the private
uses to use the standard names.
In addition, AudioFlinger was relying on the macro expanding to extra ( ).
Change-Id: I2494e087a0c0cac0ac998335f5e9c8ad02955873
- add the ability to set the vsync delivery rate, when the rate is
set to N>1 (ie: receive every N vsync), SF process' is woken up for
all of vsync, but clients only see the every N events.
- add the concept of one-shot vsync events, with a call-back
to request the next one. currently the call-back is a binder IPC.
Change-Id: I09f71df0b0ba0d88ed997645e2e2497d553c9a1b
the deadlock would happen when the pipe became invalid and SF
trying to remove the connection from its list.
we know make sure to process events without holding a lock.
Change-Id: I39927ed8824fc7811e16db3c7608a2ebc72d9642
Layer::lockPageFlip() and layer::onRemove() could be called on
different threads and race such that lockPageFlip() successfully
called mSurfaceTexture->updateTexImage() but then gets NULL back from
mSurfaceTexture->getCurrentBuffer(), leading to a crash.
This change moves Layer::onRemove() calls to
SurfaceFlinger::commitTransaction() so they happen after the Layer is
done being drawn from and only happen on the main surfaceflinger
thread.
Change-Id: I4b550caadff4cc1878d7c3bca6129193fb0c713e
This change adds a compile-time option for SurfaceTexture to use the
EGL_KHR_fence_sync extension to synchronize access to Gralloc buffers.
Bug: 5122031
Change-Id: I7e973a358631fff5308acf377581b811911fe790
use gui/DisplayEvent to receive the events. Events are
dispatched through a unix pipe, so the API is compatible
with utils/Looper. see gui/DisplayEvent.h for more info.
Bug: 1475048
Change-Id: Ia720f64d1b950328b47b22c6a86042e481d35f09
Revert "Add support for sending VSYNC events to the framework"
This reverts commit f3918c5bd4bc9f02f74da42995564150ca2dd382.
Change-Id: I998e3e1aa3fa310829ae973b64fe11b01f6f468f
* changes:
Add support for sending VSYNC events to the framework
BitTube::read now handles EAGAIN
split ComposerService out of SurfaceComposerClient.h
rewrite SF's message loop on top of Looper
use gui/DisplayEvent to receive the events. Events are
dispatched through a unix pipe, so the API is compatible
with utils/Looper. see gui/DisplayEvent.h for more info.
Bug: 1475048
Change-Id: If4126023fc9c067e56087ec7d16a8fd542ce1794
- don't advertise extensions that are not supported
by any implementation
- remove EGL_ANDROID_swap_rectangle which is not
implemented by anybody and confuses people
- add some comments about mandatory extensions
Bug: 5428001
Change-Id: Id8dc48116ac1d1eb79ec9ef55d03e29d4257c1f3
This fixes the issue:
"Call not sent" dialog takes too long to dismiss after hitting OK"
Note: the system would recover after a 5 second timeout.
Bug: 5534520
Change-Id: Ifa37e594b50581f498479a5858672441b3d7dd87
The ScreenShot layer is now created hidden. The screenshot itself
is aquired during the transaction when the layer is made visible.
This guarantees the screenshot and the layer happen atomically
with respect to screen updates.
Bug: 5534521
Change-Id: Ida23e1f13d5716ec83b78a15712e0646d6cf8729
We now have mInvalidateRegion which holds the region to invalidate, it
can be set from any thread as long as mInvalidateLock is held. We use
fine-grained locking here because mInvalidateRegion can be set from anywhere,
in particular frmo HWC callbacks.
Bug: 5466774
Change-Id: Iafca20aa3f5b25a87755e65bde7b769aa8f997bc
A LayerScreenshot is a special type of layer that contains a screenshot of
the screen acquired when its created. It works just like LayerDim.
Make sure to call compositionComplete() after rendering into a FBO.
Bug: 5446982, 5467587, 5466259
Change-Id: I5d8a1b4c327f9973d950cd4f4c0bca7f62825cd4
there was situations where SF's main loop would run (as if there was
an invalidate), but the dirty region was empty (so no new buffers
were retired). In this case we return early and don't swap, which
would cause drawing artifacts.
Bug: 5476838
Change-Id: Id3b7bf4b7aabec7919c50d9278eb2165973a4c3d
when taking a screenshot, in particular, we could end up
with stale GL state when drawing LayerDim which resulted
in incortect rendering.
Bug: 5467587
Change-Id: Id9fbed2843481d31063620f3662b364c7e3ac781
removed a test that could violate this guarantee. note that we
have no proof tha this ever happened, but consequences could be
hard lock-ups.
the code here was intended to track the region to update for displays
that can do partial update. the logic discarded the update entirely
if that region was empty. instead we just redraw the whole thing
(note that we should never be there with an empty region and retired
buffers though).
Bug: 5466259
Change-Id: I91ccab3b1a599e729e438eb833939e2236da6854
This change removes the dead code from SurfaceFlinger that resulted from
disabling support for freezing the display.
Change-Id: I4e5ff00c94b4c7a79af2f65c9850c135210068ed
This change adds two tests for SurfaceFlinger's behavior when updating
the position and size of a layer.
Change-Id: Id5e3ca1d7e629a3bd2c2d28275d80c7f9256d6da
This change enables a layer or orientation update transaction sent to
SurfaceFlinger to explicitly request a synchronous transaction.
Change-Id: I97cbba610c13679849f66114b216fa6dbf12f2a9
A LayerScreenshot is a special type of layer that contains a screenshot of
the screen acquired when its created. It works just like LayerDim.
Bug: 5446982
Change-Id: I7814aff2380e7e146937f2b641907be2a30c76cc
This change merges the ISurfaceComposer::setOrientation functionality
into ISurfaceComposer::setTransactionState. It enables the window
manager to atomically update both the display orientation and the
position and size of the windows in a single transaction with
SurfaceFlinger.
Bug: 5439574
Change-Id: I18a8ccc564d7d760ef8afb2d015ccdb7a7963900
this would happen when toggling on/off/on very fast, the screen
could stay black (while the panel is on).
Bug: 5429724
Change-Id: Ic8aa6aff066e6267923c0d47ef65e314e7bb6d41
This change modifies SurfaceFlinger's screenshot behavior when a layer
with a protected buffer is visible. The previous behavior was to simply
fail the screenshot. The new behavior is to render the screenshot using
a placeholder texture where the protected buffer would have been.
Change-Id: I5e50cb2f3b31b2ea81cfe291c9b4a42e9ee71874
This change makes SurfaceFlinger update a SurfaceTextureLayer's default
buffer size in response to a window resize even if the Layer is in fixed
size mode.
Change-Id: I3871c8f19a045d03904d1284390cad7659be71ff
Bug: 5366426
when areas of the FB are undefined (transparent windows on top of
nothing), we clear those areas before composition.
however, it makes no sense to do this when the FB is not in use
(case where hwc handles all layers)
Bug: 5360529
Change-Id: I761a7d3664228ebbee0944aca8b0cc278fc94c9c
This change fixes the transform hint to use only the global display
transform rather than incorporating the transient layer-specific
transform used during animations.
Bug: 5366891
Change-Id: I5408dcd3f4771d010953e8a696a484c835bfe81e
when areas of the FB are undefined (transparent windows on top of
nothing), we clear those areas before composition.
however, it makes no sense to do this when the FB is not in use
(case where hwc handles all layers)
Bug: 5360529
Change-Id: If51bb669307e8419bbe1f3a89d1c88e0ec1f216c
Bug: 4981385
Simplify the orientation changing code path in the
WindowManager. Instead of the policy calling setRotation()
when the sensor determined orientation changes, it calls
updateRotation(), which figures everything out. For the most
part, the rotation actually passed to setRotation() was
more or less ignored and just added confusion, particularly
when handling deferred orientation changes.
Ensure that 180 degree rotations are disallowed even when
the application specifies SCREEN_ORIENTATION_SENSOR_*.
These rotations are only enabled when docked upside-down for
some reason or when the application specifies
SCREEN_ORIENTATION_FULL_SENSOR.
Ensure that special modes like HDMI connected, lid switch,
dock and rotation lock all cause the sensor to be ignored
even when the application asks for sensor-based orientation
changes. The sensor is not relevant in these modes because
some external factor (or the user) is determining the
preferred rotation.
Currently, applications can still override the preferred
rotation even when there are special modes in play that
might say otherwise. We could tweak this so that some
special modes trump application choices completely
(resulting in a letter-boxed application, perhaps).
I tested this sort of tweak (not included in the patch)
and it seems to work fine, including transitions between
applications with varying orientation.
Delete dead code related to animFlags.
Handle pausing/resuming orientation changes more precisely.
Ensure that a deferred orientation change is performed when
a drag completes, even if endDragLw() is not called because the
drag was aborted before the drop happened. We pause
the orientation change in register() and resume in unregister()
because those methods appear to always be called as needed.
Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
we need to clear the whole framebuffer in that situation because
we can't trust the content of the FB when partial (fb preserving)
updates are used.
Bug: 5318492
Change-Id: I3f0e01b0fb665a34e44d88ad9f0f54a5d990060b
we need to clear the whole framebuffer in that situation because
we can't trust the content of the FB when partial (fb preserving)
updates are used.
Bug: 5318492
Change-Id: I3f0e01b0fb665a34e44d88ad9f0f54a5d990060b
This change fixes an issue where Layer::isOpaque was being called in
lockPageFlip to get the opaqueness for the new buffer before
mActiveBuffer was updated.
Bug: 5321313
Change-Id: Ibb5d7d3f4e9a2b1448e117a484a0d9f9ca5fc9de
This change fixes an issue where Layer::isOpaque was being called in
lockPageFlip to get the opaqueness for the new buffer before
mActiveBuffer was updated.
Bug: 5321313
Change-Id: Ibb5d7d3f4e9a2b1448e117a484a0d9f9ca5fc9de
we were not redrawing and/or clearing the FB properly when
hwc moved a layer from/to FB to/from OVERLAY.
In these cases we needed to expand the dirty region to include
the layer that changed mode.
Also split composeSurfaces() which was becoming quite large.
Change-Id: Id6fa1acfc4ff694037fddf7efd037a4405732073
this happened when the overlays were in use, since the animation
is rendered in the FB and the FB is not used.
we now have a way to turn hwc off temporarily.
Change-Id: I3385f0c25bb9cc91948e7b26e7cd31ed18c36ace
these were due to the "preserve backbuffer" optimization
interfering with hw composer. basically the screen needed
to be redrawn in the areas that move from GL to
overlay.
Bug: 5245513
Change-Id: I9bf75c4fe905f3ef62005e52108b94edae692304
Added Surface.setPosition(float, float) which allows to set a surface's
position in float.
Bug: 5239859
Change-Id: I903aef4ad5b5999142202fb8ea30fe216d805711
We were not updating the h/w composer state when the buffer size
changed.
We also didn't update the h/w composer state when the transformation
matrix changed (which is related to the above issue, since it would
probably change when the buffer size changes).
Also moved updating the crop to setGeometry(), since we decided
that the "crop" change requires the GEOMETRY_CHANGED flag (ie:
not need to do this every frame)
Bug: 5238473
Change-Id: Ia7b47e145b48581b568d89d9aa2c14ff778be862
When taking screenshots we need to use the full drawing state list
instead of the visible list.
Bug: 5186823
Change-Id: I214ee0203aaf8e2c038e44581f7f1ae36edf08c5
This change makes SurfaceFlinger always use the
GRALLOC_USAGE_HW_COMPOSER usage bit when allocating buffers that may be
passed to the HWComposer.
Change-Id: I70362a8ede2b359fb2046853f85149d597465817
we were using the "orientation" value instead of the
real transform, which may contain arbitrary rotations for
instance, and in some case ended up with a final "orientation"
that looked valid, but wasn't.
this fixes a problem on devices with a h/w composer hal where
the rotation animation looked weird.
Change-Id: I4be8a2a1bde49c33456fcf5c8d87ab515c216763
This change fixes the NATIVE_WINDOW_QUEUES_TO_WINDOW_COMPOSER query of
Surface and SurfaceTextureClient. Surface now uses the inherited
SurfaceTextureClient implementation of this query. SurfaceTextureClient
now queries SurfaceFlinger to determine whether buffers that are queued
to its ISurfaceTexture will be sent to SurfaceFlinger (as opposed to
some other process).
Change-Id: Iff187e72f30d454229f07f896b438198978270a8
this is disabled by default. To enable:
setprop debug.sf.ddms 1
this debug option requires to restart SurfaceFlinger
Change-Id: Ic2f8050b29911b55bcd21721648b6978700c277d
a wrong orientation would be briefly shown when
rotation the screen. this happened when the window manager
set a custom transformation and the h/w composer was used.
the custom transformation was applied twice in that case.
Bug: 5037522
Change-Id: Ic1f87b63cd843f4475e4265d1624463825d775c4
the first time a surface was connected, the values returned
by query NATIVE_WINDOW_DEFAULT_{WIDTH|HEIGHT} and
NATIVE_WINDOW_TRANSFORM_HINT were wrong until a call
to queueBuffer was performed.
Bug: 5137366, 5121607
Change-Id: I7ac6b5b0daa876638f6bed7c20f286a6e6d984f6
This is useful in various situations, for instance if the HAL
wants to change its compositing strategy.
Bug: 4488017
Change-Id: I5afc14e5917c6db7926d7417d48677d5aba50caa
This change makes SurfaceFlinger's SurfaceTexture objects default to
async mode whenever a camera or video decoder connects. This behavior
can be disabled by #defining NEVER_DEFAULT_TO_ASYNC_MODE.
Change-Id: I8965951d1775915da180e4af298dd7af3afafecc
This change makes the Layer::onRemoved method call
SurfaceTextures::abandon on the layer's SurfaceTexture. This will cause
all client-initiated operations on the SurfaceTexture to fail. In
particular, this will result in an error on the client side, rather than
a deadlock when removing a layer that used a SurfaceTexture in
synchronous mode.
Change-Id: I14014d00369f29560a21b606831edee432bb8867
Bug: 5020874
This change fixes a bug where the window visibility would be computed
before any buffers were available, causing the window to be treated as
non-opaque. When the first buffer arrived, if both mCurrentOpacity and
the opacity determined by the buffer's format were 'opaque', a
recomputation of the opacity would not be done, and the window would
continue to be treated as non-opaque. SurfaceFlinger could then
unnecessarily draw fully occluded layers.
Change-Id: I2b95da2f4b50e68d50fc5afd8b772e26e62f58d6
Bug: 5057122
- fixed uninitialized variable
- set hint to indentity when transform is too complex
- make sure FrameBufferNativeWindow doesn't fail on needed perform commands
Bug: 4487161
Change-Id: I7cb2b0869b72404732eca7cb2d145ff669e2ed9b
