This prevents strong reference cycles when the listener implementation also
holds a strong pointer to the ConsumerBase
Bug: 7425644
Change-Id: I1514b13a32b18d421c902dddebec0765a989c55c
the scissor rect is now computed once by DisplayDevice
and is combined with the "undefined" region so that
the letter-boxed area of the screen get cleared in
drawWormhole.
Bug: 7149437
Change-Id: Id2f30516a5786f32eace7f876ff32028f954f357
we perform external display clipping only on the GL
side (ie: not done on the h/w composer side, which is
harder and would be too risky). in practice this means
that WFD will be clipped properly, while HDMI *may* or
may not depending on how hwc is used.
Bug: 7149437
Change-Id: I92d4d04220db72b6ffb134c7fa7a93af569723a5
a misbehaving or malicious client could cause SF to crash
by providing a "fake" IInterface. we now check the
IInterface we get is our own and local.
Bug: 7278879
Change-Id: Ia19d05902d4b2385c5a16416148378d4998833fd
This change adds support for displays that are not allowed to display surfaces
with the eSecure flag set. All non-virtual displays are considered secure,
while virtual displays have their secure-ness specified at creation time.
Bug: 7368436
Change-Id: I81ad535d2d1e5a7ff78269017e85b111f0098500
The code that reserves display IDs was only run when a hardware
composer was present. The eventControl() function, which handles
enabling of vsync, was ignoring the request because the primary
display didn't appear in its set of allocated IDs. This moves
reservation of IDs for built-in displays outside the HWC-only block.
Also, added a couple of warnings in eventControl().
Bug 7376568
Change-Id: I185ccdf817a25499b5c2668f8f6d594afb8c1568
we were holding a reference (ie: pointer) to a sp<DisplayDevice>
while processing the message. Meanwhile the object itself could
go away and we would end up accessing a dead object.
the root cause of the problem is that we are accessing mDisplays[]
in a few places outside of the main thread.
Bug: 7352770
Change-Id: I89e35dd85fb30e9a6383eca9a0bbc7028363876c
This change adds a transaction flag for WindowManager to indicate that a
transaction is being used to animate windows around the screen. SurfaceFlinger
will not allow more than one of these transactions to be outstanding at a time
to prevent the animation "frames" from being dropped.
Bug: 7353840
Change-Id: I6488a6e0e1ed13d27356d2203c9dc766dc6b1759
The screenshot is a GL_RGB texture, and the GL_REPLACE texture env
mode uses vertex alpha for GL_RGB textures instead of alpha=1.0.
Bug: 7340077
Change-Id: I6fbb907023e48f9c422b15a33da79757d6726840
Two issues:
(1) We were announcing the hotplug event before we were ready to
handle blank/unblank events, so we were losing the initial unblank
that power manager sends us when HDMI is first plugged in. This
left the display blank until you toggled the device power off/on.
(2) We were retaining fbTargetHandle for HDMI after the display was
disconnected. The value didn't get updated when HDMI was reconnected
because the display was blank, so we didn't go through that code
path. So, when HDMI was re-connected, we passed stale data into
the HWC.
Bug 7323938
Change-Id: I2335d24fd7b0f00bb23fc63aa7bcf44cb8857c73
this should be handled by the display-manager. we were doing
that in SF because until recently we didn't have enough support
in the HAL. however, this is now causing other problems when
plugging hdmi while the screen is off for instance.
Bug: 7150885
Change-Id: I739b209056a765d38d05295cf202f67ee0f506ae
DdmHandleAppName.setAppName() signature changed which broke
this debugging feature.
Needed for debugging b\7267680
Change-Id: I4482bf5a441e91bef89d1ddea9a4152333be7f88
The new disconnectDisplay function doesn't handle virtual displays,
but it may be called for them. Return without doing anything.
Bug 7281786
Change-Id: I62607f2ae6073fa66b393f55932604aeb8e03566
When a display is disconnected, removing it from SurfaceFlinger's
display list is non-atomic with removing it from the Display Manager
and any in-flight transactions. So SurfaceFlinger might get a display
state change transaction for a display it has already forgotten about.
Just ignore these.
Bug: 7288082
Change-Id: Ic27e55377f3db40fb34e3b1cd67e43297df117a2
when enabling/disabling vsync we now make sure to
not call into the HAL if the state wouldn't change.
Bug: 7274951
Change-Id: Ie24a6d68888a51b577acf9c2a973d85437cbacaf
The display was being removed from SurfaceFlinger's list before we
had a chance to reset HWComposer's layer list, so we were passing
stale data into the hardware composer (which has its own per-display
data). This resulted in "invalid gralloc handle" complaints.
We now clear the layer list immediately after removing the display.
The display was being removed while its EGLSurface was still
"current", resulting in "cancelBuffer: BufferQueue has been
abandoned" complaints. We now call makeCurrent on the primary
display before removing the external display.
Bug 7274254
Change-Id: Ia59e3a61d7ec46488b96bf93ec5e4ed3488b70e4
This reverts commit bdf277355d.
This reverts commit dc5b63e40e.
it might be responsible for a regression that makes the
rotation vector spin.
Bug: 7267330
Change-Id: Ifb10e933537e70c1d85a7ba73a7e3ae59002fe62
This change makes SurfaceFlinger reset the acquire fence fd to -1 after each
call to HWComposer::commit. The HWComposer implementation is resonsible for
closing the fd, so SurfaceFlinger should make sure not to pass it to HWC
multiple times.
Change-Id: I79554d9f6d6ef2b77d632d40251516c1f5b16ddb
Bug: 7258954
This allows us to blank and unblank displays other than the built-in
display (e.g. HDMI).
Bug: 7240511
Change-Id: I89ea13f9e497be74c3e1231d0c62fb558e93e0f8
This change fixes a bug in SurfaceFlinger that caused the HWC_GEOMETRY_CHANGED
flag to be set every flip.
Change-Id: I4f395a2883bcbb53b23b3d14941aff108739c9f0
Bug: 7234237
Some of the code in latchBuffer was calling invalidateHwcGeometry,
but that didn't cause the SurfaceFlinger visible region code to
re-evaluate the layer's visibility. Set the recomputeVisibleRegions
"out" parameter instead.
Bug 7235797
Change-Id: If6ba33fbd1a594cd64cc5253aebf752d6ceda1c9
The transparent region hint is computed only from view layout
locations, ignoring post-layout translation. If a SurfaceView is layed
out with no other views above it, but a view is moved above it
post-layout, that view's layout bounds would be subtracted from the
window's transparent region instead of its drawing bounds. Prior to
this change, the view would not be visible (except where its layout
bounds and drawing bounds overlap).
With this change, composition uses visible regions computed without
regard to the transparent regions. However, if all of a layer's
visible region is transparent, it will be removed from the list of
layers to composite. This doesn't fix the root problem of incorrect
transparent regions, and doesn't prevent bad composition in all cases.
But it does avoid it for some existing apps, whiel still allowing the
transparent region hint to save power in the important
fullscreen-video-in-a-SurfaceView case.
Bug: 7179570
Change-Id: I47cf939e12129b167afa344b8b036e8827103ac8
we now try first with EGL_FRAMEBUFFER_TARGET_ANDROID, and
pick the first config we find. Otherwise, we revert to
the old algorithm.
Bug: 7232584
Change-Id: I8d5c5a4ce48420832c2e2828718a8f53325effb0
MemoryHeapBase::getBase() returns MAP_FAILED in case or
OOM, not null which is what SF was checking against.
This addresses one of the issues of bug 7230543.
Bug: 7230543
Change-Id: I763a88f64a2f9ff75eb139cfbaf9a1a9746c5577
This adds a line to the "dumpsys SurfaceFlinger" output that shows
build-time configuration values.
Example:
Build configuration: [sf HAS_CONTEXT_PRIORITY] [libui] \
[libgui USE_FENCE_SYNC]
Bug 7206633
Change-Id: Ibe1856b459d34a4be6ee83a4ebfd2807e6cc68a0
this call is not needed and misleading on HWC 1.1; it can also have
a negative performance impact when multiple displays are used.
Bug: 7124069
Change-Id: I47cd25c9d6e69abcc9333b9ecd5044e8fb1919ec
getDisplayInfo() now returns proper information for
HWC managed displays.
hotplug is sitll not supported; so this is not fully correct
as the information returned will be bogus if the HDMI screen
is not plugged in.
Bug: 7191563
Change-Id: If55d8e829fae0443571548155007f486cdf9bc9f
until now we were tracking when a sensors was
physically enabled or disabled and we were reporting
that to the BattaryService.
this wasn incorrect because we could have several different
apps enabling the same sensor, so the accounting by the
battery service would be incorrect in that case (depending
on the order in which these apps disabled said sensor).
BatteryService tracks sensors per uid, however SensorService
does this per binder connection, so we could have several
binder connections for the same uid, to solve this we keep
a list of sensor/uid -> count, which is the bulk of this
change.
Bug: 6661604
Change-Id: I561c198c42ba1736a8671bdacda4c76d72b9dd6f
It shouldn't have caused much harm though.
Also log a warning when enabling a sensor
for a connection that is already enabled.
Change-Id: Ia4a052381e79183cd4cb1bedc7ba08e5228d7a38
This change makes updateTexImage default to performing the necessary
synchronization and adds an argument for SurfaceFlinger to disable that
synchronization so that it can be performed lazily.
Change-Id: I7c20923cc786634126fbf7021c9d2541aa77be5d
Bug: 6991805
The Surface createDisplay() call takes a display name for debugging.
This change carries it through SurfaceFlinger and displays it in
the "dumpsys SurfaceFlinger" output.
Bug 7058158
Change-Id: I79f3474a8656ff1beb7b478e0dbf2c5de666118a
we were not calling eglSwapBuffers() on external displays
because they can't use HWC which caused us to think they
didn't have GLES composition.
Change-Id: I6cef4ae40b138412d2e6f2acda33c9d222b03a83
- decouple GL and main display initialization
- ensure that each "supported" display has its own FramebufferSurface
- onScreenAcquired/Released now takes a display
Change-Id: If34a05f3dea40f6c79db77f4dde283a2580daac4
The hints were being set a little too late, so the pre-rotation stuff
wasn't quite working.
Bug 7054997
Change-Id: Id8d5c626db7a76f768ba762a145b315878ee08e6
There are two different translations to apply in the logical
orientation, one before scaling and one after.
So translate, scale, translate then rotate.
Bug: 7139798
Change-Id: I0726991cadb62988390e77503dbbaed54f07bfe3
we now make sure to take the blanked state of a display into
account when we build its list of visible layers, this ensures
that we won't call prepare/set with a non-empty list when the
display is blanked.
Possibly fixes 7075380, 7103553, 7130187, 7016215
Bug: 7075380
Change-Id: I9fdd2e73d1b7621eaeca3d4ac2ae60d9fb1b3631
This adds a trivial workaround for a one-shot boot time crash, plus
an explicit check and abort for a failure condition that currently
presents as a less obvious failure.
Bug: 7145521, 7147557
Change-Id: I548f6a9caa9f0bd5710aaecea0e1c6c7c8f2f281
FramebufferSurface no longer speaks directly to the FB HAL. Now
everything goes through HWComposer (which may or may not be
connected to a hardware composer).
Added display index arg to some query methods.
Change-Id: Id3e157d2d4e3555d33afbb703e518b6e92e2d6d5
This change adds a compile-option to use eglWaitSyncANDROID to ensure that
texturing operations that access the current buffer of a SurfaceTexture do not
occur until the buffer is completely written. It also moves this
synchronization into a new SurfaceTexture method called doGLFenceWait and
changes SurfaceFlinger's Layer class to use that method rather than performing
its own wait on the fence.
Change-Id: I70afa88086ca7ff49a80e3cd03d423767db7cb88
onInitializeDisplays() was posting a transaction with changes
to the display projection. Unfortunately, it only set the
display orientation field and left viewport and frame
uninitialized.
The uninitialized values flowed downstream and found themselves
baked into a bogus DisplayDevice mGlobalTransform. That transform
was then applied to some Rects which were turned into Regions
that were them combined with other Regions.
Under certain situations, the uninitialized data might have
a largish value, resulting in the creation of Regions with
components in excess of the Region max-value limit of 0x7ffffff
(note that this is not INT_MAX). Later when performing a
binary operation using the Region, the Spanner would loop
indefinitely trying to figure out how to stuff a humongous
region inside of a max-value region. Not content to try
just once, the Spanner would continue trying again and
again, pegging the CPU and hanging surface flinger during boot.
Insanity soon followed.
Bug: 7130713
Change-Id: I0016f0c9662185be833474c212a1dd408096ae23
This change moves some common fence handling code into the base class for
BufferQueue consumer classes. It also makes the ConsumerBase class initialize
a buffer slot's fence with the acquire fence every time a buffer is acquired.
Change-Id: I0bd88bc269e919653b659bfb3ebfb04dd61692a0
the problem was that LayerBase::setPerFrameData() was always setting
this flag. in fact there was no reason to do this at that point since
the layer is initialized to a default state in setGeometry().
Bug: 7111259
Change-Id: Ib37b0dd7391a6163070e9aca025512159c1705f9
If SurfaceFlinger needs to refresh the screen but the dirty region is
empty, it won't set the layer acquire fences, and stale file
descriptors will be passed to HWC commit(). Now we make sure to clear
the stale file descriptors for each layer right after commit().
Bug: 7078301
Change-Id: I6953ff91fc5488f105b30b07306f9c45a4c3f780
- the library is dlopened from libsurfaceflinger
- the library built only when libnativehelper exists
Bug: 7089510
Change-Id: Ib3ea1029d7e8f6e055f4b759d0bf68f5123fa8a1
we used to have a visibleRegion object per layer, but now
it's per screen; so at somepoint the code got changed to
calculate the per-screen visible region on the stack and that's
what got passed to HWC.
we're now setting the visibleRegionScreen at each frame and
freeing at after the HWC set() call. We use the underlaying
SharedBuffer so that in most cases we don't have to allocate,
free or copy memory around.
Bug: 7089478
Change-Id: I24fa556c76613a225d9fe7a6c6b727bb476144d8
This change makes BufferQueue derive the min undequeued buffer count from a max
acquired buffer count that is set by the consumer. This value may be set at
any time that a producer is not connected to the BufferQueue rather than at
BufferQueue construction time.
Change-Id: Icf9f1d91ec612a079968ba0a4621deffe48f4e22
this would happen when the composition was handled
entirely in h/w composer, in this case, we would
not set the fences for any involved layers.
Bug: 7049373
Change-Id: I1439dc156ce23c24041cdfbbebfe8ff4fdf790f8
This change is a clean up of some of the handling of the maximum number of
buffers that are allowed at once. It mostly renames a few member variables and
methods, but it includes a couple small refactorings.
Change-Id: I9959310f563d09583548d4291e1050a7bbc7d87d
this happened because we didn't check that the visible
region was within the bounds of the display.
Bug: 7064121
Change-Id: I2e81850a3dc3d1474253520ad7f9e559c26d5a96
DisplayDevices are now keyed of the wp<IBinder> the client uses.
DisplayID has now become DisplayType which is just used to identify
physical displays (as opposed to virtual displays such as wifi displays).
Change-Id: I0c5968f2c902dcd699a7e0afacf833ff070c12ea
Use only display tokens in the API to refer to new displays.
Don't require the caller to specify the display when creating
a surface (since in general a surface could be shown on
any display).
This is intended to be a minimum change just to update the API.
Note that SurfaceFlinger still uses DisplayID in a few places
internally that might cause some features not to work properly
when there are multiple displays (LayerScreenshot, for example).
Change-Id: I3d91eec2da406eefd97bcd53655d403ad865a7e6
The primary display device was being configured to "blank" by
default, which prevented the boot animation from appearing
(unless you got lucky with the hardware composer state).
Bug 6975688
Change-Id: I0fa52e9e719c6e997c5725a7baf15d9718461b78
The primary display device was being configured to "blank" by
default, which prevented the boot animation from appearing
(unless you got lucky with the hardware composer state).
Bug 6975688
(This reverts an earlier revert.)
HWComposer can now create IDs representing a display
it can deal with. IDs MAIN and HDMI are reserved.
SurfaceFlinger associate HWComposer IDs with a
DisplayDevice and uses that when it talks to HWComposer.
A DisplayDevice doesn't have to have a HWComposer ID,
in that case it just can't use h/w composer composition.
Change-Id: Iec3d7ac92e0c22bf975052ae2847402f58bade71
- we now clean-up "dead" connection in the main loop,
this entirely avoid the problem with the side effects of
releasing strong references. We now only hold on to strong
reference for the connection we will signal.
- also simplify how we build the list of "ready" connections, by
only adding them to the list when we did receive a vsync event
Change-Id: I2a84da431320a2af8e8a93e07622a1d258236f43
The primary display device was being configured to "blank" by
default, which prevented the boot animation from appearing
(unless you got lucky with the hardware composer state).
Bug 6975688
Change-Id: Idaa0d0b98ebb331a17d1b16774c6b05bfa1e8728
- one issues caused most timestamps to be reported as 0
- on rare occasions an uninitialized variable could be used
- vsync counts per connection were accessed unthreadsafely
we now have 2 lists of connections in the main loop, one just
keeps a list of strong refs to the connections because once
we have a strong ref we're not allowed to release it while
holding the lock.
the 2nd list holds the connections that have a vsync event to
be reported. all the calculations are made with the lock held.
Change-Id: Iacfad3745b05df79d9ece3719bd4c34ddbfd5b83
problem was that we were acquiring a strong reference
on Connection object with a lock held, when those
got out of scope (lock still held) their dtor
could be called if all other refs had dropped,
the dtor would acquire the lock again to
remove the Connection from the main list. boom.
we rearange the code so this doesn't happen.
Bug: 6942208
Change-Id: I0a0ebabce2842d29d60d645b64aac2f26640e59b
when multiple displays are connected, we ended-up having to
call eglMakeCurrent() twice per display due to a limitation
in EGL. this fixes that.
Change-Id: I11e4584df50f8c24bbecee74e37b28b3ee031d2f
fix a few bugs with external displays
- HWComposer doesn't really handle multiple displays yet
so there is a lot of ugliness there
- We also need to make sure that external displays are not
blanked by default
- due to some EGL limitations surfaces being swapped need
to be current
Change-Id: I82bff05b43bcebd8da863c7c76b4edbc3bc223a9
due to a typo, SF's main transaction was conditional to having a
display transaction.
more correct fix for 6970310
Bug: 6970310
Change-Id: Iafd8c4e02afa5db829cc1c65950cfcc74754c6af
Layers were not properly being removed because we were
setting the wrong transaction type flag at the time of
removal.
When layers are removed, we must use eDisplayTransactionNeeded,
not eTransactionNeeded, to ensure that the mLayersRemoved
flag is checked and the appropriate cleanup occurs.
Bug: 6970310
Change-Id: Id4b2897a34d4ac00aa0f92349c0ec6db95c1aaf7
- displays are represented by a binder on the client side
- c++ clients can now create and modify displays
Change-Id: I203ea5b4beae0819d742ec5171c27568f4e8354b
once a secure window is put on screen the display
would retain its "secure" flag forever, preventing
screenshots from being taken.
Bug: 6933967
Change-Id: I5be8355145ca7d580d84552311642f8fa912fe6a
- also replace C casts with C++ casts
- only the interface is changed, HWComposer still doesn't
fully handle multiple displays
Change-Id: I48eb89bff2edb76bf1d4d41f46802b9b2a7166a8
This change refactors the FramebufferSurface class to inherit from the new
ConsumerBase class.
Bug: 6620200
Change-Id: I46ec942ddb019658e3c5e79465548b171b2261f2
it's safer this way because this object owns an
EGLSurface which cannot be easily reference-counted.
it also gives us the ability to sub-class it, which
we might want to do soon.
Change-Id: I07358bb052dc5a13b4f2196b2c2b6e6e94c4bb4f
- fix typo drawForSreenshot misspelled
- get rid of DisplayDeviceBase
- removed unused or unneeded code
- always pass a DisplayDevice to Layer methods that are called
on a per-display basis (to make it clear that this could be
called more than once per composition).
Change-Id: Id948b7e09fe5c06db0e42d40d6ed75dd095c7f44
Commit 8630320 moved the eglSwapBuffers fallback (for devices with no
HWC implementation) from DisplayHardware to HWComposer. But HWComposer
only knows about the framebuffer EGL display and surface handles if
there is a HWC, so it was always passing bogus handles.
This change moves the eglSwapBuffers fallback up to SurfaceFlinger,
which has access to the framebuffer EGL handles.
Bug: 6886613
Change-Id: Iad3f5ff7c90ee48d7053999e6a4548d6794b6ebd
we will only ever have a single instance of HWComposer, so
it's now an attribute of SurfaceFlinger, instead of being part
of DisplayHardware.
DisplayHardware now just represents a "display" (it should be renamed).
Change-Id: Iec191e57686868e1df6daa8b880a286c9fefde56
this attribute can be set through a regular transaction using
SurfaceComposerClient (just like any other attribute, eg: position or size)
Change-Id: I701a47c677ea6442ca713728a93335328cd2b172
no change of functionality -- the old behavior is implemented
on top of this new protocol.
this new protocol will allow, eventually, to pass informations
about displays and layer stacks.
Change-Id: Ic6c2295e61ec8ecbc8ce01ab7664e35d928202fc
mostly refactored SurfaceFlinger.h, but also removed dead code.
cleaned-up a few includes as well.
Change-Id: Ib15f4ffe567912b61ee98aa076c6a283b72811b5
Call into the new HWC blank operation to blank or unblank the screen.
Legacy systems may have already blanked the screen via early suspend,
and can choose to not implement the blank operation in their hardware
composer implementation.
Change-Id: Ib403c8c0e36367a2cfef3e1d124872fcfeb9e7cb
- remove dependency on cached state in validateVisibility
- get rid of mVertices and mTransformedBounds
- get rid of validateVisibility
- get rid of unlockPageFlip
- handleTransaction now returns a dirty region
- computevisibileregion now uses window-manager space
if debug.sensors is true, extra debugging
sensors are enabled and HAL provided sensor fusion
is disabled
Change-Id: I9b093424edb8c5363d1337237cdf6abe4ab266f9
we now use a better quaternion propagation equation
this is especially beneficial for lower gyroscope rates
Change-Id: Ifbf273c8a092a8849ca4fe4b9bca30787e924018
both API and implementation will change, this is just a prototype
intended to show feasability.
SurfaceFlinger is passed an ISurfaceTexture through a new
callback, it is in turn used to create an EGLSurface which
surfaceflinger will draw into in addition to the main screen.
Change-Id: Id0bbb0b854bb7bae44d57246a90b65d4567f9a21
1) there was a typo when computing the system covariance
a term in dT^3 was ommitted; the impact was was very limited
because of how small this term is.
2) initialize the system covariance matrix with non-zero
values for the gyro-bias part. this improves the initial
bias estimation speed significantly.
3) added comments here and there
Change-Id: I4328c9cca73e089889d5e74b9fda99d7831762dc
some sensor HALs don't handle EINTR, make sure to catch it in the
sensorservice.
also if we ever encounter an error that we can't handle, we abort
which will restart us (or the whole system process if we're running
in it)
Bug: 5511741
Change-Id: I7051882b06980f778736b53d6cd021a99b5ca8d2
Requested rate will be clamped to the minimum rate and then
to 1ms. Previously we would return an error if a lower
rate was asked. The SensorManager documentation wording
allows this change.
We do this to get more consistancy between all the sensor
drivers / HALs
Change-Id: I199f76486fb76ccbb11e7280460a03726c767e84
When the app requests "fastest", the java layer encodes this as a
delay of 0. SensorService was passing this unchanged to the HAL.
However the HAL is required to reject delays lower that the
advertised lower delay.
Change-Id: I92be77acd3af62ffeb49e4b31e24ddcd203510e2
This is intended to absorb the cost of the IPC
to the permission controller.
Cached permission checks cost about 3us, while
full blown ones are two orders of magnitude slower.
CAVEAT: PermissionCache can only handle system
permissions safely for now, because the cache is
not purged upon global permission changes.
Change-Id: I8b8a5e71e191e3c01e8f792f253c379190eee62e
when we do our own sensor fusion, we also export an
improved orientation sensor and hide the HAL sensor.
The fused orientation sensor is much more precise, fast
and smooth.
Change-Id: I0ea843b47ad9d12f6b22cce51f8629852d423126
also use correct time propagation equation
disable the fused sensors when gyro is not present since
they were unusable in practice.
Change-Id: Iad797425784e67dc6c5690e97c71c583418cc5b5
Add support for 9-axis gravity and linear-acceleration sensors
virtual orientation sensor using 9-axis fusion
Change-Id: I6717539373fce781c10e97b6fa59f68a831a592f
SensorService main thread wasn't java-enabled. however, in
some situations we end-up calling into the BatteryService from
that thread which causes a crash.
Change-Id: Iffba90e4c4b743dba84d62f1342001a9db31916d
Make sure to send an event down only for sensors that report a value only on data
change. Other sensors, will naturally send an event when the next event is available.
Bug: 4025681
Change-Id: I6d444deda388b6bc9a33e3371e09d390f1566ec5
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
