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 want functions like isEmpty() to return true if NANs are
involved in the Rect
- also clean-up the intersect familly of calls
- minor cleanup in the int32_t Rect as well
These played a role in http://b/5331198.
Bug: 5331198
Change-Id: I5369725ab482e4b83da9f1bd4cee5256e5de75b2
Bug: 5265529
Rewrote the velocity tracker to fit a polynomial curve
to pointer movements using least squares linear regression.
The velocity is simply the first derivative of this polynomial.
Clients can also obtain an Estimator that describes the
complete terms of the estimating polynomial including
the coefficient of determination which provides a measure
of the quality of the fit (confidence).
Enhanced PointerLocation to display the movement curve predicted
by the estimator in addition to the velocity vector.
By default, the algorithm computes a 2nd degree (quadratic)
polynomial based on a 100ms recent history horizon.
Change-Id: Id377bef44117fce68fee2c41f90134ce3224d3a1
Bug: 5265529
Calculate the velocity using the most recent touch sample as the
point of reference instead of the oldest. This change more heavily
weights recent touch samples and reduces the sample time window
used for calculation. This significantly improves the accuracy
of fling gesture detection.
Change-Id: Ib1940933e786e5f6a731552a99bcd9400741d55f
Added Surface.setPosition(float, float) which allows to set a surface's
position in float.
Bug: 5239859
Change-Id: I903aef4ad5b5999142202fb8ea30fe216d805711
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
Bug: 5049148
Finished stylus support, including support for indirect stylus
and mouse tools.
Added TILT axis. When stylus tilt X/Y is available, it is transformed
into an orientation and tilt inclination which is a more convenient
representation and a simpler extension to the exiting API.
Touch devices now only report touch data using a single input
source. Previously touch devices in pointer mode would report
both absolute touch pad data and cooked pointer gestures.
Now we just pick one. The touch device switches modes as needed
when the focused application enables/disables pointer gestures.
This change greatly simplifies the code and reduces the load
on the input dispatcher.
Fixed an incorrect assumption that the value of ABS_(MT_)DISTANCE
would be zero whenever the stylus was in direct contact. It appears
that the correct way to determine whether the stylus is in direct
contact (rather than hovering) is by checking for a non-zero
reported pressure.
Added code to read the initial state of tool buttons and axis values
when the input devices are initialized or reset. This fixes
problems where the input mapper state might have the wrong initial
state.
Moved responsibility for cancelling pending inputs (keys down,
touches, etc.) to the InputDispatcher by sending it a device reset
notification. This frees the InputReader from having to synthesize
events during reset, which was cumbersome and somewhat brittle
to begin with.
Consolidated more of the common accumulator logic from
SingleTouchInputMapper and MultiTouchInputMapper into
TouchInputMapper.
Improved the PointerLocation output.
Change-Id: I595d3647f7fd7cb1e3eff8b3c76b85043b5fe2f0
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
we were not reseting mCurrentTexture in some situations
which in turn caused dequeueBuffers() return a
"FREE" buffer that was also current.
Very often it was harmless, but it created a race with
updateTexImage() which could cause the following
queueBuffers() to fail.
Bug: 5156325
Change-Id: If15a31dc869117543d220d6e5562c57116cbabdb
we would leak a weakref_impl if a RefBase was never incWeak()'ed.
there was also a dangling pointer that would cause memory corruption
and double-delete when a custom destroyer was used to delay the
execution of ~RefBase.
it turns out that the custom destroyer feature caused most of the
problems, so it's now gone. The only client was SurfaceFlinger
who now handles things on its own.
RefBase is essentially back its "gingerbread" state, but the
code was slightly cleaned-up.
Bug: 5151207, 5084978
Change-Id: Id6ef1d707f96d96366f75068f77b30e0ce2722a5
* changes:
fix a crasher in SurfaceTexture::updateTexImage()
rework dequeueBuffer()'s main loop.
error out when SurfaceTexture APIs are called while not connected
we now make sure to drain the buffer queue on disconnect.
this happens only when in synchrnous mode. in async mode
we clear all buffers except the head of the queue.
for extra safety we also catch the null pointer
in updateTexImage (which should never happen) and return
an error.
Bug: 5111008
Change-Id: I5174a6ecbb0de641c6510ef56a611cbb4e9e1f59
this simplifies the code a bit and also makes sure
we reevaluate mAbandoned and mConnectedApi each time
we come back from waiting on mDequeueCondition
Change-Id: I1f8538b62ad321b51ed79d953b700036daba796d
- also log a warning when freeAllBuffers is called with a non empty buffer queue
- rename freeAllBuffers to freeAllBuffersLocked
Change-Id: Idb71fdcf233b9ccae62d5a2a7c3c4bad2501d877
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
Bug: 5064702
Introduced the concept of an InputListener to further decouple
the InputReader from the InputDispatcher. The InputListener
exposes just the minimum interface that the InputReader needs
to communicate with the outside world. The InputReader
passes arguments to the InputListener by reference, which makes
it easy to queue them up.
Consolidated all of the InputReader locks into one simple global
Mutex. The reason this wasn't done before was due to potential
re-entrance in outbound calls to the InputDispatcher. To fix this,
the InputReader now queues up all of the events it wants to send
using a QueuedInputListener, then flushes them outside of the
critical section after all of the event processing is finished.
Removing all of the InputMapper locks greatly simplifies the
implementation.
Added tests for new stylus features such as buttons, tool types,
and hovering.
Added some helpers to BitSet32 to handle common code patterns
like finding the first marked bit and clearing it.
Fixed a bug in VelocityTracker where the wrong pointer trace
could get cleared when handling ACTION_POINTER_DOWN. Oops.
Changed PointerCoords so it no longer stores useless zero
axis values. Removed editAxisValue because it is not very
useful when all zero value axes are absent and therefore
cannot be edited in place.
Added dispatch of stylus hover events.
Added support for distance and tool types.
Change-Id: I4cf14d134fcb1db7d10be5f2af7b37deef8f8468
When querying switch state for a given device id, ensure that the device
exposes the given switch in its capabilities, report AKEY_STATE_UNKNOWN
otherwise.
This fix a bug in InputManager that reports an incorrect switch state
(down) when a device exposes at least one switch in its capabilites and
another switch is queried. For example, this can leads in always
reporting LID state open (SW_LID down) if only SW_HEADPHONE_INSERT is
exposed in capabilities.
Change-Id: I4e5265ec02af918c317673789e7948529842aa2d
Signed-off-by: Michaël Burtin <mburtin@gmail.com>
The built-in ZipFile class was quite a long time to find an unpack
libraries. Move everything to using the libutils ZipFileRO class that
goes quite a bit faster. Initial measurements are 6 times faster than
the Java code.
Also, read files off the disk and compare their CRC against the APK's
CRC to see if we need to write the new file to disk. This also cuts down
the bootup time by up to a second per APK that has native files.
Change-Id: Ic464a7969a17368fb6a6b81d026888c4136c7603
