Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2010 The Android Open Source Project
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _UI_INPUT_DISPATCHER_H
|
|
|
|
#define _UI_INPUT_DISPATCHER_H
|
|
|
|
|
2012-02-17 15:34:57 -08:00
|
|
|
#include <androidfw/Input.h>
|
|
|
|
#include <androidfw/InputTransport.h>
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
#include <utils/KeyedVector.h>
|
|
|
|
#include <utils/Vector.h>
|
|
|
|
#include <utils/threads.h>
|
|
|
|
#include <utils/Timers.h>
|
|
|
|
#include <utils/RefBase.h>
|
|
|
|
#include <utils/String8.h>
|
2010-09-13 23:17:30 -07:00
|
|
|
#include <utils/Looper.h>
|
2010-09-26 22:20:12 -07:00
|
|
|
#include <utils/BitSet.h>
|
2012-02-07 14:46:57 -08:00
|
|
|
#include <cutils/atomic.h>
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
|
|
|
#include <stddef.h>
|
|
|
|
#include <unistd.h>
|
2010-09-08 11:49:43 -07:00
|
|
|
#include <limits.h>
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2011-01-10 11:17:36 -08:00
|
|
|
#include "InputWindow.h"
|
|
|
|
#include "InputApplication.h"
|
2011-07-27 16:04:54 -07:00
|
|
|
#include "InputListener.h"
|
2011-01-10 11:17:36 -08:00
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
|
|
|
namespace android {
|
|
|
|
|
2010-06-17 20:52:56 -07:00
|
|
|
/*
|
|
|
|
* Constants used to report the outcome of input event injection.
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
/* (INTERNAL USE ONLY) Specifies that injection is pending and its outcome is unknown. */
|
|
|
|
INPUT_EVENT_INJECTION_PENDING = -1,
|
|
|
|
|
|
|
|
/* Injection succeeded. */
|
|
|
|
INPUT_EVENT_INJECTION_SUCCEEDED = 0,
|
|
|
|
|
|
|
|
/* Injection failed because the injector did not have permission to inject
|
|
|
|
* into the application with input focus. */
|
|
|
|
INPUT_EVENT_INJECTION_PERMISSION_DENIED = 1,
|
|
|
|
|
|
|
|
/* Injection failed because there were no available input targets. */
|
|
|
|
INPUT_EVENT_INJECTION_FAILED = 2,
|
|
|
|
|
|
|
|
/* Injection failed due to a timeout. */
|
|
|
|
INPUT_EVENT_INJECTION_TIMED_OUT = 3
|
|
|
|
};
|
|
|
|
|
2010-07-28 15:48:59 -07:00
|
|
|
/*
|
|
|
|
* Constants used to determine the input event injection synchronization mode.
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
/* Injection is asynchronous and is assumed always to be successful. */
|
|
|
|
INPUT_EVENT_INJECTION_SYNC_NONE = 0,
|
|
|
|
|
|
|
|
/* Waits for previous events to be dispatched so that the input dispatcher can determine
|
|
|
|
* whether input event injection willbe permitted based on the current input focus.
|
|
|
|
* Does not wait for the input event to finish processing. */
|
|
|
|
INPUT_EVENT_INJECTION_SYNC_WAIT_FOR_RESULT = 1,
|
|
|
|
|
|
|
|
/* Waits for the input event to be completely processed. */
|
|
|
|
INPUT_EVENT_INJECTION_SYNC_WAIT_FOR_FINISHED = 2,
|
|
|
|
};
|
|
|
|
|
2010-06-17 20:52:56 -07:00
|
|
|
|
2010-06-15 01:31:58 -07:00
|
|
|
/*
|
|
|
|
* An input target specifies how an input event is to be dispatched to a particular window
|
|
|
|
* including the window's input channel, control flags, a timeout, and an X / Y offset to
|
|
|
|
* be added to input event coordinates to compensate for the absolute position of the
|
|
|
|
* window area.
|
|
|
|
*/
|
|
|
|
struct InputTarget {
|
|
|
|
enum {
|
2010-09-15 15:18:56 -07:00
|
|
|
/* This flag indicates that the event is being delivered to a foreground application. */
|
2011-03-07 16:56:21 -08:00
|
|
|
FLAG_FOREGROUND = 1 << 0,
|
2010-06-15 01:31:58 -07:00
|
|
|
|
2010-09-01 17:01:00 -07:00
|
|
|
/* This flag indicates that the target of a MotionEvent is partly or wholly
|
|
|
|
* obscured by another visible window above it. The motion event should be
|
|
|
|
* delivered with flag AMOTION_EVENT_FLAG_WINDOW_IS_OBSCURED. */
|
2011-03-07 16:56:21 -08:00
|
|
|
FLAG_WINDOW_IS_OBSCURED = 1 << 1,
|
2010-09-26 22:20:12 -07:00
|
|
|
|
|
|
|
/* This flag indicates that a motion event is being split across multiple windows. */
|
2011-03-07 16:56:21 -08:00
|
|
|
FLAG_SPLIT = 1 << 2,
|
|
|
|
|
2011-06-02 15:16:05 -07:00
|
|
|
/* This flag indicates that the pointer coordinates dispatched to the application
|
|
|
|
* will be zeroed out to avoid revealing information to an application. This is
|
|
|
|
* used in conjunction with FLAG_DISPATCH_AS_OUTSIDE to prevent apps not sharing
|
|
|
|
* the same UID from watching all touches. */
|
|
|
|
FLAG_ZERO_COORDS = 1 << 3,
|
|
|
|
|
2011-03-07 16:56:21 -08:00
|
|
|
/* This flag indicates that the event should be sent as is.
|
|
|
|
* Should always be set unless the event is to be transmuted. */
|
|
|
|
FLAG_DISPATCH_AS_IS = 1 << 8,
|
|
|
|
|
|
|
|
/* This flag indicates that a MotionEvent with AMOTION_EVENT_ACTION_DOWN falls outside
|
|
|
|
* of the area of this target and so should instead be delivered as an
|
|
|
|
* AMOTION_EVENT_ACTION_OUTSIDE to this target. */
|
|
|
|
FLAG_DISPATCH_AS_OUTSIDE = 1 << 9,
|
|
|
|
|
|
|
|
/* This flag indicates that a hover sequence is starting in the given window.
|
|
|
|
* The event is transmuted into ACTION_HOVER_ENTER. */
|
|
|
|
FLAG_DISPATCH_AS_HOVER_ENTER = 1 << 10,
|
|
|
|
|
|
|
|
/* This flag indicates that a hover event happened outside of a window which handled
|
|
|
|
* previous hover events, signifying the end of the current hover sequence for that
|
|
|
|
* window.
|
|
|
|
* The event is transmuted into ACTION_HOVER_ENTER. */
|
|
|
|
FLAG_DISPATCH_AS_HOVER_EXIT = 1 << 11,
|
|
|
|
|
2011-06-08 15:37:10 -07:00
|
|
|
/* This flag indicates that the event should be canceled.
|
|
|
|
* It is used to transmute ACTION_MOVE into ACTION_CANCEL when a touch slips
|
|
|
|
* outside of a window. */
|
|
|
|
FLAG_DISPATCH_AS_SLIPPERY_EXIT = 1 << 12,
|
|
|
|
|
|
|
|
/* This flag indicates that the event should be dispatched as an initial down.
|
|
|
|
* It is used to transmute ACTION_MOVE into ACTION_DOWN when a touch slips
|
|
|
|
* into a new window. */
|
|
|
|
FLAG_DISPATCH_AS_SLIPPERY_ENTER = 1 << 13,
|
|
|
|
|
2011-03-07 16:56:21 -08:00
|
|
|
/* Mask for all dispatch modes. */
|
|
|
|
FLAG_DISPATCH_MASK = FLAG_DISPATCH_AS_IS
|
|
|
|
| FLAG_DISPATCH_AS_OUTSIDE
|
|
|
|
| FLAG_DISPATCH_AS_HOVER_ENTER
|
2011-06-08 15:37:10 -07:00
|
|
|
| FLAG_DISPATCH_AS_HOVER_EXIT
|
|
|
|
| FLAG_DISPATCH_AS_SLIPPERY_EXIT
|
|
|
|
| FLAG_DISPATCH_AS_SLIPPERY_ENTER,
|
2010-06-15 01:31:58 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
// The input channel to be targeted.
|
|
|
|
sp<InputChannel> inputChannel;
|
|
|
|
|
|
|
|
// Flags for the input target.
|
|
|
|
int32_t flags;
|
|
|
|
|
|
|
|
// The x and y offset to add to a MotionEvent as it is delivered.
|
|
|
|
// (ignored for KeyEvents)
|
|
|
|
float xOffset, yOffset;
|
2010-09-26 22:20:12 -07:00
|
|
|
|
Better compat mode part one: start scaling windows.
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
|
|
|
// Scaling factor to apply to MotionEvent as it is delivered.
|
|
|
|
// (ignored for KeyEvents)
|
|
|
|
float scaleFactor;
|
|
|
|
|
2010-09-26 22:20:12 -07:00
|
|
|
// The subset of pointer ids to include in motion events dispatched to this input target
|
|
|
|
// if FLAG_SPLIT is set.
|
|
|
|
BitSet32 pointerIds;
|
2010-06-15 01:31:58 -07:00
|
|
|
};
|
|
|
|
|
2010-06-17 20:52:56 -07:00
|
|
|
|
2011-05-26 19:17:02 -07:00
|
|
|
/*
|
|
|
|
* Input dispatcher configuration.
|
|
|
|
*
|
|
|
|
* Specifies various options that modify the behavior of the input dispatcher.
|
|
|
|
*/
|
|
|
|
struct InputDispatcherConfiguration {
|
|
|
|
// The key repeat initial timeout.
|
|
|
|
nsecs_t keyRepeatTimeout;
|
|
|
|
|
|
|
|
// The key repeat inter-key delay.
|
|
|
|
nsecs_t keyRepeatDelay;
|
|
|
|
|
|
|
|
InputDispatcherConfiguration() :
|
|
|
|
keyRepeatTimeout(500 * 1000000LL),
|
2012-02-03 13:35:13 -08:00
|
|
|
keyRepeatDelay(50 * 1000000LL) { }
|
2011-05-26 19:17:02 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2010-06-15 01:31:58 -07:00
|
|
|
/*
|
|
|
|
* Input dispatcher policy interface.
|
|
|
|
*
|
|
|
|
* The input reader policy is used by the input reader to interact with the Window Manager
|
|
|
|
* and other system components.
|
|
|
|
*
|
|
|
|
* The actual implementation is partially supported by callbacks into the DVM
|
|
|
|
* via JNI. This interface is also mocked in the unit tests.
|
|
|
|
*/
|
|
|
|
class InputDispatcherPolicyInterface : public virtual RefBase {
|
|
|
|
protected:
|
|
|
|
InputDispatcherPolicyInterface() { }
|
|
|
|
virtual ~InputDispatcherPolicyInterface() { }
|
|
|
|
|
|
|
|
public:
|
|
|
|
/* Notifies the system that a configuration change has occurred. */
|
|
|
|
virtual void notifyConfigurationChanged(nsecs_t when) = 0;
|
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
/* Notifies the system that an application is not responding.
|
|
|
|
* Returns a new timeout to continue waiting, or 0 to abort dispatch. */
|
2010-09-15 15:18:56 -07:00
|
|
|
virtual nsecs_t notifyANR(const sp<InputApplicationHandle>& inputApplicationHandle,
|
2011-01-10 11:17:36 -08:00
|
|
|
const sp<InputWindowHandle>& inputWindowHandle) = 0;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
2010-06-15 01:31:58 -07:00
|
|
|
/* Notifies the system that an input channel is unrecoverably broken. */
|
2011-01-10 11:17:36 -08:00
|
|
|
virtual void notifyInputChannelBroken(const sp<InputWindowHandle>& inputWindowHandle) = 0;
|
2010-06-15 01:31:58 -07:00
|
|
|
|
2011-05-26 19:17:02 -07:00
|
|
|
/* Gets the input dispatcher configuration. */
|
|
|
|
virtual void getDispatcherConfiguration(InputDispatcherConfiguration* outConfig) = 0;
|
2010-06-15 01:31:58 -07:00
|
|
|
|
2011-05-26 19:17:02 -07:00
|
|
|
/* Returns true if automatic key repeating is enabled. */
|
|
|
|
virtual bool isKeyRepeatEnabled() = 0;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
2011-03-30 02:25:18 -07:00
|
|
|
/* Filters an input event.
|
|
|
|
* Return true to dispatch the event unmodified, false to consume the event.
|
|
|
|
* A filter can also transform and inject events later by passing POLICY_FLAG_FILTERED
|
|
|
|
* to injectInputEvent.
|
|
|
|
*/
|
|
|
|
virtual bool filterInputEvent(const InputEvent* inputEvent, uint32_t policyFlags) = 0;
|
|
|
|
|
2010-10-08 22:31:17 -07:00
|
|
|
/* Intercepts a key event immediately before queueing it.
|
|
|
|
* The policy can use this method as an opportunity to perform power management functions
|
|
|
|
* and early event preprocessing such as updating policy flags.
|
|
|
|
*
|
|
|
|
* This method is expected to set the POLICY_FLAG_PASS_TO_USER policy flag if the event
|
|
|
|
* should be dispatched to applications.
|
|
|
|
*/
|
2010-11-18 20:53:46 -08:00
|
|
|
virtual void interceptKeyBeforeQueueing(const KeyEvent* keyEvent, uint32_t& policyFlags) = 0;
|
2010-10-08 22:31:17 -07:00
|
|
|
|
2011-03-02 19:23:13 -08:00
|
|
|
/* Intercepts a touch, trackball or other motion event before queueing it.
|
2010-10-08 22:31:17 -07:00
|
|
|
* The policy can use this method as an opportunity to perform power management functions
|
|
|
|
* and early event preprocessing such as updating policy flags.
|
|
|
|
*
|
|
|
|
* This method is expected to set the POLICY_FLAG_PASS_TO_USER policy flag if the event
|
|
|
|
* should be dispatched to applications.
|
|
|
|
*/
|
2011-03-02 19:23:13 -08:00
|
|
|
virtual void interceptMotionBeforeQueueing(nsecs_t when, uint32_t& policyFlags) = 0;
|
2010-10-08 22:31:17 -07:00
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
/* Allows the policy a chance to intercept a key before dispatching. */
|
2011-10-12 13:57:59 -07:00
|
|
|
virtual nsecs_t interceptKeyBeforeDispatching(const sp<InputWindowHandle>& inputWindowHandle,
|
2010-09-08 11:49:43 -07:00
|
|
|
const KeyEvent* keyEvent, uint32_t policyFlags) = 0;
|
|
|
|
|
2010-12-06 17:13:33 -08:00
|
|
|
/* Allows the policy a chance to perform default processing for an unhandled key.
|
|
|
|
* Returns an alternate keycode to redispatch as a fallback, or 0 to give up. */
|
2011-01-10 11:17:36 -08:00
|
|
|
virtual bool dispatchUnhandledKey(const sp<InputWindowHandle>& inputWindowHandle,
|
2010-12-06 17:13:33 -08:00
|
|
|
const KeyEvent* keyEvent, uint32_t policyFlags, KeyEvent* outFallbackKeyEvent) = 0;
|
2010-11-05 15:02:16 -07:00
|
|
|
|
2010-10-08 22:31:17 -07:00
|
|
|
/* Notifies the policy about switch events.
|
|
|
|
*/
|
|
|
|
virtual void notifySwitch(nsecs_t when,
|
|
|
|
int32_t switchCode, int32_t switchValue, uint32_t policyFlags) = 0;
|
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
/* Poke user activity for an event dispatched to a window. */
|
2010-09-26 22:20:12 -07:00
|
|
|
virtual void pokeUserActivity(nsecs_t eventTime, int32_t eventType) = 0;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
/* Checks whether a given application pid/uid has permission to inject input events
|
|
|
|
* into other applications.
|
|
|
|
*
|
|
|
|
* This method is special in that its implementation promises to be non-reentrant and
|
|
|
|
* is safe to call while holding other locks. (Most other methods make no such guarantees!)
|
|
|
|
*/
|
|
|
|
virtual bool checkInjectEventsPermissionNonReentrant(
|
|
|
|
int32_t injectorPid, int32_t injectorUid) = 0;
|
2010-06-15 01:31:58 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
/* Notifies the system about input events generated by the input reader.
|
|
|
|
* The dispatcher is expected to be mostly asynchronous. */
|
2011-07-27 16:04:54 -07:00
|
|
|
class InputDispatcherInterface : public virtual RefBase, public InputListenerInterface {
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
protected:
|
|
|
|
InputDispatcherInterface() { }
|
|
|
|
virtual ~InputDispatcherInterface() { }
|
|
|
|
|
|
|
|
public:
|
2010-09-08 11:49:43 -07:00
|
|
|
/* Dumps the state of the input dispatcher.
|
|
|
|
*
|
|
|
|
* This method may be called on any thread (usually by the input manager). */
|
|
|
|
virtual void dump(String8& dump) = 0;
|
|
|
|
|
2011-08-10 16:25:21 -07:00
|
|
|
/* Called by the heatbeat to ensures that the dispatcher has not deadlocked. */
|
|
|
|
virtual void monitor() = 0;
|
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
/* Runs a single iteration of the dispatch loop.
|
|
|
|
* Nominally processes one queued event, a timeout, or a response from an input consumer.
|
|
|
|
*
|
|
|
|
* This method should only be called on the input dispatcher thread.
|
|
|
|
*/
|
|
|
|
virtual void dispatchOnce() = 0;
|
|
|
|
|
2010-06-17 20:52:56 -07:00
|
|
|
/* Injects an input event and optionally waits for sync.
|
2010-07-28 15:48:59 -07:00
|
|
|
* The synchronization mode determines whether the method blocks while waiting for
|
|
|
|
* input injection to proceed.
|
2010-06-17 20:52:56 -07:00
|
|
|
* Returns one of the INPUT_EVENT_INJECTION_XXX constants.
|
|
|
|
*
|
|
|
|
* This method may be called on any thread (usually by the input manager).
|
|
|
|
*/
|
|
|
|
virtual int32_t injectInputEvent(const InputEvent* event,
|
2011-03-30 02:25:18 -07:00
|
|
|
int32_t injectorPid, int32_t injectorUid, int32_t syncMode, int32_t timeoutMillis,
|
|
|
|
uint32_t policyFlags) = 0;
|
2010-06-17 20:52:56 -07:00
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
/* Sets the list of input windows.
|
|
|
|
*
|
|
|
|
* This method may be called on any thread (usually by the input manager).
|
|
|
|
*/
|
2011-07-13 22:51:29 -07:00
|
|
|
virtual void setInputWindows(const Vector<sp<InputWindowHandle> >& inputWindowHandles) = 0;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
/* Sets the focused application.
|
|
|
|
*
|
|
|
|
* This method may be called on any thread (usually by the input manager).
|
|
|
|
*/
|
2011-07-13 22:51:29 -07:00
|
|
|
virtual void setFocusedApplication(
|
|
|
|
const sp<InputApplicationHandle>& inputApplicationHandle) = 0;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
/* Sets the input dispatching mode.
|
|
|
|
*
|
|
|
|
* This method may be called on any thread (usually by the input manager).
|
|
|
|
*/
|
|
|
|
virtual void setInputDispatchMode(bool enabled, bool frozen) = 0;
|
|
|
|
|
2011-03-30 02:25:18 -07:00
|
|
|
/* Sets whether input event filtering is enabled.
|
|
|
|
* When enabled, incoming input events are sent to the policy's filterInputEvent
|
|
|
|
* method instead of being dispatched. The filter is expected to use
|
|
|
|
* injectInputEvent to inject the events it would like to have dispatched.
|
|
|
|
* It should include POLICY_FLAG_FILTERED in the policy flags during injection.
|
|
|
|
*/
|
|
|
|
virtual void setInputFilterEnabled(bool enabled) = 0;
|
|
|
|
|
2010-09-27 14:52:15 -07:00
|
|
|
/* Transfers touch focus from the window associated with one channel to the
|
|
|
|
* window associated with the other channel.
|
|
|
|
*
|
|
|
|
* Returns true on success. False if the window did not actually have touch focus.
|
|
|
|
*/
|
|
|
|
virtual bool transferTouchFocus(const sp<InputChannel>& fromChannel,
|
|
|
|
const sp<InputChannel>& toChannel) = 0;
|
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
/* Registers or unregister input channels that may be used as targets for input events.
|
2010-09-08 11:49:43 -07:00
|
|
|
* If monitor is true, the channel will receive a copy of all input events.
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
*
|
|
|
|
* These methods may be called on any thread (usually by the input manager).
|
|
|
|
*/
|
2011-01-10 11:17:36 -08:00
|
|
|
virtual status_t registerInputChannel(const sp<InputChannel>& inputChannel,
|
|
|
|
const sp<InputWindowHandle>& inputWindowHandle, bool monitor) = 0;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
virtual status_t unregisterInputChannel(const sp<InputChannel>& inputChannel) = 0;
|
|
|
|
};
|
|
|
|
|
2010-06-15 01:31:58 -07:00
|
|
|
/* Dispatches events to input targets. Some functions of the input dispatcher, such as
|
|
|
|
* identifying input targets, are controlled by a separate policy object.
|
|
|
|
*
|
|
|
|
* IMPORTANT INVARIANT:
|
|
|
|
* Because the policy can potentially block or cause re-entrance into the input dispatcher,
|
|
|
|
* the input dispatcher never calls into the policy while holding its internal locks.
|
|
|
|
* The implementation is also carefully designed to recover from scenarios such as an
|
|
|
|
* input channel becoming unregistered while identifying input targets or processing timeouts.
|
|
|
|
*
|
|
|
|
* Methods marked 'Locked' must be called with the lock acquired.
|
|
|
|
*
|
|
|
|
* Methods marked 'LockedInterruptible' must be called with the lock acquired but
|
|
|
|
* may during the course of their execution release the lock, call into the policy, and
|
|
|
|
* then reacquire the lock. The caller is responsible for recovering gracefully.
|
|
|
|
*
|
|
|
|
* A 'LockedInterruptible' method may called a 'Locked' method, but NOT vice-versa.
|
|
|
|
*/
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
class InputDispatcher : public InputDispatcherInterface {
|
|
|
|
protected:
|
|
|
|
virtual ~InputDispatcher();
|
|
|
|
|
|
|
|
public:
|
2010-06-15 01:31:58 -07:00
|
|
|
explicit InputDispatcher(const sp<InputDispatcherPolicyInterface>& policy);
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
virtual void dump(String8& dump);
|
2011-08-10 16:25:21 -07:00
|
|
|
virtual void monitor();
|
2010-09-08 11:49:43 -07:00
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
virtual void dispatchOnce();
|
|
|
|
|
2011-07-27 16:04:54 -07:00
|
|
|
virtual void notifyConfigurationChanged(const NotifyConfigurationChangedArgs* args);
|
|
|
|
virtual void notifyKey(const NotifyKeyArgs* args);
|
|
|
|
virtual void notifyMotion(const NotifyMotionArgs* args);
|
|
|
|
virtual void notifySwitch(const NotifySwitchArgs* args);
|
2011-08-18 11:20:58 -07:00
|
|
|
virtual void notifyDeviceReset(const NotifyDeviceResetArgs* args);
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2010-06-17 20:52:56 -07:00
|
|
|
virtual int32_t injectInputEvent(const InputEvent* event,
|
2011-03-30 02:25:18 -07:00
|
|
|
int32_t injectorPid, int32_t injectorUid, int32_t syncMode, int32_t timeoutMillis,
|
|
|
|
uint32_t policyFlags);
|
2010-06-17 20:52:56 -07:00
|
|
|
|
2011-07-13 22:51:29 -07:00
|
|
|
virtual void setInputWindows(const Vector<sp<InputWindowHandle> >& inputWindowHandles);
|
|
|
|
virtual void setFocusedApplication(const sp<InputApplicationHandle>& inputApplicationHandle);
|
2010-09-08 11:49:43 -07:00
|
|
|
virtual void setInputDispatchMode(bool enabled, bool frozen);
|
2011-03-30 02:25:18 -07:00
|
|
|
virtual void setInputFilterEnabled(bool enabled);
|
2010-06-22 01:27:15 -07:00
|
|
|
|
2010-09-27 14:52:15 -07:00
|
|
|
virtual bool transferTouchFocus(const sp<InputChannel>& fromChannel,
|
|
|
|
const sp<InputChannel>& toChannel);
|
|
|
|
|
2011-01-10 11:17:36 -08:00
|
|
|
virtual status_t registerInputChannel(const sp<InputChannel>& inputChannel,
|
|
|
|
const sp<InputWindowHandle>& inputWindowHandle, bool monitor);
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
virtual status_t unregisterInputChannel(const sp<InputChannel>& inputChannel);
|
|
|
|
|
|
|
|
private:
|
|
|
|
template <typename T>
|
|
|
|
struct Link {
|
|
|
|
T* next;
|
|
|
|
T* prev;
|
2012-02-03 15:08:02 -08:00
|
|
|
|
|
|
|
protected:
|
|
|
|
inline Link() : next(NULL), prev(NULL) { }
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
};
|
|
|
|
|
2010-09-26 22:20:12 -07:00
|
|
|
struct InjectionState {
|
|
|
|
mutable int32_t refCount;
|
|
|
|
|
|
|
|
int32_t injectorPid;
|
|
|
|
int32_t injectorUid;
|
|
|
|
int32_t injectionResult; // initially INPUT_EVENT_INJECTION_PENDING
|
|
|
|
bool injectionIsAsync; // set to true if injection is not waiting for the result
|
|
|
|
int32_t pendingForegroundDispatches; // the number of foreground dispatches in progress
|
2011-07-20 15:19:50 -07:00
|
|
|
|
|
|
|
InjectionState(int32_t injectorPid, int32_t injectorUid);
|
|
|
|
void release();
|
|
|
|
|
|
|
|
private:
|
|
|
|
~InjectionState();
|
2010-09-26 22:20:12 -07:00
|
|
|
};
|
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
struct EventEntry : Link<EventEntry> {
|
|
|
|
enum {
|
|
|
|
TYPE_CONFIGURATION_CHANGED,
|
2011-08-18 11:20:58 -07:00
|
|
|
TYPE_DEVICE_RESET,
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
TYPE_KEY,
|
|
|
|
TYPE_MOTION
|
|
|
|
};
|
|
|
|
|
2010-09-26 22:20:12 -07:00
|
|
|
mutable int32_t refCount;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
int32_t type;
|
|
|
|
nsecs_t eventTime;
|
2010-10-08 22:31:17 -07:00
|
|
|
uint32_t policyFlags;
|
2010-09-26 22:20:12 -07:00
|
|
|
InjectionState* injectionState;
|
2010-06-17 20:52:56 -07:00
|
|
|
|
2010-06-15 01:31:58 -07:00
|
|
|
bool dispatchInProgress; // initially false, set to true while dispatching
|
2010-09-08 11:49:43 -07:00
|
|
|
|
2011-04-07 11:38:09 -07:00
|
|
|
inline bool isInjected() const { return injectionState != NULL; }
|
2011-07-20 15:19:50 -07:00
|
|
|
|
|
|
|
void release();
|
|
|
|
|
|
|
|
protected:
|
|
|
|
EventEntry(int32_t type, nsecs_t eventTime, uint32_t policyFlags);
|
|
|
|
virtual ~EventEntry();
|
|
|
|
void releaseInjectionState();
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
struct ConfigurationChangedEntry : EventEntry {
|
2011-07-20 15:19:50 -07:00
|
|
|
ConfigurationChangedEntry(nsecs_t eventTime);
|
|
|
|
|
|
|
|
protected:
|
|
|
|
virtual ~ConfigurationChangedEntry();
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
};
|
|
|
|
|
2011-08-18 11:20:58 -07:00
|
|
|
struct DeviceResetEntry : EventEntry {
|
|
|
|
int32_t deviceId;
|
|
|
|
|
|
|
|
DeviceResetEntry(nsecs_t eventTime, int32_t deviceId);
|
|
|
|
|
|
|
|
protected:
|
|
|
|
virtual ~DeviceResetEntry();
|
|
|
|
};
|
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
struct KeyEntry : EventEntry {
|
|
|
|
int32_t deviceId;
|
2011-01-25 16:02:22 -08:00
|
|
|
uint32_t source;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
int32_t action;
|
|
|
|
int32_t flags;
|
|
|
|
int32_t keyCode;
|
|
|
|
int32_t scanCode;
|
|
|
|
int32_t metaState;
|
|
|
|
int32_t repeatCount;
|
|
|
|
nsecs_t downTime;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
bool syntheticRepeat; // set to true for synthetic key repeats
|
|
|
|
|
|
|
|
enum InterceptKeyResult {
|
|
|
|
INTERCEPT_KEY_RESULT_UNKNOWN,
|
|
|
|
INTERCEPT_KEY_RESULT_SKIP,
|
|
|
|
INTERCEPT_KEY_RESULT_CONTINUE,
|
2011-10-12 13:57:59 -07:00
|
|
|
INTERCEPT_KEY_RESULT_TRY_AGAIN_LATER,
|
2010-09-08 11:49:43 -07:00
|
|
|
};
|
|
|
|
InterceptKeyResult interceptKeyResult; // set based on the interception result
|
2011-10-12 13:57:59 -07:00
|
|
|
nsecs_t interceptKeyWakeupTime; // used with INTERCEPT_KEY_RESULT_TRY_AGAIN_LATER
|
2011-07-20 15:19:50 -07:00
|
|
|
|
|
|
|
KeyEntry(nsecs_t eventTime,
|
|
|
|
int32_t deviceId, uint32_t source, uint32_t policyFlags, int32_t action,
|
|
|
|
int32_t flags, int32_t keyCode, int32_t scanCode, int32_t metaState,
|
|
|
|
int32_t repeatCount, nsecs_t downTime);
|
|
|
|
void recycle();
|
|
|
|
|
|
|
|
protected:
|
|
|
|
virtual ~KeyEntry();
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
struct MotionEntry : EventEntry {
|
2012-02-03 15:08:02 -08:00
|
|
|
nsecs_t eventTime;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
int32_t deviceId;
|
2011-01-25 16:02:22 -08:00
|
|
|
uint32_t source;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
int32_t action;
|
2010-09-01 17:01:00 -07:00
|
|
|
int32_t flags;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
int32_t metaState;
|
2011-05-06 18:20:01 -07:00
|
|
|
int32_t buttonState;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
int32_t edgeFlags;
|
|
|
|
float xPrecision;
|
|
|
|
float yPrecision;
|
|
|
|
nsecs_t downTime;
|
|
|
|
uint32_t pointerCount;
|
2011-05-06 18:20:01 -07:00
|
|
|
PointerProperties pointerProperties[MAX_POINTERS];
|
2012-02-03 15:08:02 -08:00
|
|
|
PointerCoords pointerCoords[MAX_POINTERS];
|
2010-08-18 15:51:08 -07:00
|
|
|
|
2011-07-20 15:19:50 -07:00
|
|
|
MotionEntry(nsecs_t eventTime,
|
|
|
|
int32_t deviceId, uint32_t source, uint32_t policyFlags, int32_t action,
|
|
|
|
int32_t flags, int32_t metaState, int32_t buttonState, int32_t edgeFlags,
|
|
|
|
float xPrecision, float yPrecision,
|
|
|
|
nsecs_t downTime, uint32_t pointerCount,
|
|
|
|
const PointerProperties* pointerProperties, const PointerCoords* pointerCoords);
|
|
|
|
|
|
|
|
protected:
|
|
|
|
virtual ~MotionEntry();
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
};
|
|
|
|
|
2010-06-15 01:31:58 -07:00
|
|
|
// Tracks the progress of dispatching a particular event to a particular connection.
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
struct DispatchEntry : Link<DispatchEntry> {
|
2012-02-07 14:46:57 -08:00
|
|
|
const uint32_t seq; // unique sequence number, never 0
|
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
EventEntry* eventEntry; // the event to dispatch
|
|
|
|
int32_t targetFlags;
|
|
|
|
float xOffset;
|
|
|
|
float yOffset;
|
Better compat mode part one: start scaling windows.
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
2011-04-27 18:52:56 -04:00
|
|
|
float scaleFactor;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2011-06-28 20:08:48 -07:00
|
|
|
// Set to the resolved action and flags when the event is enqueued.
|
|
|
|
int32_t resolvedAction;
|
|
|
|
int32_t resolvedFlags;
|
|
|
|
|
2011-07-20 15:19:50 -07:00
|
|
|
DispatchEntry(EventEntry* eventEntry,
|
|
|
|
int32_t targetFlags, float xOffset, float yOffset, float scaleFactor);
|
|
|
|
~DispatchEntry();
|
|
|
|
|
2010-09-15 15:18:56 -07:00
|
|
|
inline bool hasForegroundTarget() const {
|
|
|
|
return targetFlags & InputTarget::FLAG_FOREGROUND;
|
2010-09-08 11:49:43 -07:00
|
|
|
}
|
2010-09-26 22:20:12 -07:00
|
|
|
|
|
|
|
inline bool isSplit() const {
|
|
|
|
return targetFlags & InputTarget::FLAG_SPLIT;
|
|
|
|
}
|
2012-02-07 14:46:57 -08:00
|
|
|
|
|
|
|
private:
|
|
|
|
static volatile int32_t sNextSeqAtomic;
|
|
|
|
|
|
|
|
static uint32_t nextSeq();
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
};
|
|
|
|
|
2010-06-15 01:31:58 -07:00
|
|
|
// A command entry captures state and behavior for an action to be performed in the
|
|
|
|
// dispatch loop after the initial processing has taken place. It is essentially
|
|
|
|
// a kind of continuation used to postpone sensitive policy interactions to a point
|
|
|
|
// in the dispatch loop where it is safe to release the lock (generally after finishing
|
|
|
|
// the critical parts of the dispatch cycle).
|
|
|
|
//
|
|
|
|
// The special thing about commands is that they can voluntarily release and reacquire
|
|
|
|
// the dispatcher lock at will. Initially when the command starts running, the
|
|
|
|
// dispatcher lock is held. However, if the command needs to call into the policy to
|
|
|
|
// do some work, it can release the lock, do the work, then reacquire the lock again
|
|
|
|
// before returning.
|
|
|
|
//
|
|
|
|
// This mechanism is a bit clunky but it helps to preserve the invariant that the dispatch
|
|
|
|
// never calls into the policy while holding its lock.
|
|
|
|
//
|
|
|
|
// Commands are implicitly 'LockedInterruptible'.
|
|
|
|
struct CommandEntry;
|
|
|
|
typedef void (InputDispatcher::*Command)(CommandEntry* commandEntry);
|
|
|
|
|
2010-06-17 20:52:56 -07:00
|
|
|
class Connection;
|
2010-06-15 01:31:58 -07:00
|
|
|
struct CommandEntry : Link<CommandEntry> {
|
2011-07-20 15:19:50 -07:00
|
|
|
CommandEntry(Command command);
|
2010-06-15 01:31:58 -07:00
|
|
|
~CommandEntry();
|
|
|
|
|
|
|
|
Command command;
|
|
|
|
|
|
|
|
// parameters for the command (usage varies by command)
|
2010-06-17 20:52:56 -07:00
|
|
|
sp<Connection> connection;
|
2010-09-08 11:49:43 -07:00
|
|
|
nsecs_t eventTime;
|
|
|
|
KeyEntry* keyEntry;
|
|
|
|
sp<InputApplicationHandle> inputApplicationHandle;
|
2011-01-10 11:17:36 -08:00
|
|
|
sp<InputWindowHandle> inputWindowHandle;
|
2010-09-08 11:49:43 -07:00
|
|
|
int32_t userActivityEventType;
|
2012-02-07 14:46:57 -08:00
|
|
|
uint32_t seq;
|
2010-11-05 15:02:16 -07:00
|
|
|
bool handled;
|
2010-06-15 01:31:58 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
// Generic queue implementation.
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
template <typename T>
|
|
|
|
struct Queue {
|
2011-07-20 15:19:50 -07:00
|
|
|
T* head;
|
|
|
|
T* tail;
|
|
|
|
|
|
|
|
inline Queue() : head(NULL), tail(NULL) {
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
}
|
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
inline bool isEmpty() const {
|
2011-07-20 15:19:50 -07:00
|
|
|
return !head;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
inline void enqueueAtTail(T* entry) {
|
2011-07-20 15:19:50 -07:00
|
|
|
entry->prev = tail;
|
|
|
|
if (tail) {
|
|
|
|
tail->next = entry;
|
|
|
|
} else {
|
|
|
|
head = entry;
|
|
|
|
}
|
|
|
|
entry->next = NULL;
|
|
|
|
tail = entry;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
inline void enqueueAtHead(T* entry) {
|
2011-07-20 15:19:50 -07:00
|
|
|
entry->next = head;
|
|
|
|
if (head) {
|
|
|
|
head->prev = entry;
|
|
|
|
} else {
|
|
|
|
tail = entry;
|
|
|
|
}
|
|
|
|
entry->prev = NULL;
|
|
|
|
head = entry;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
inline void dequeue(T* entry) {
|
2011-07-20 15:19:50 -07:00
|
|
|
if (entry->prev) {
|
|
|
|
entry->prev->next = entry->next;
|
|
|
|
} else {
|
|
|
|
head = entry->next;
|
|
|
|
}
|
|
|
|
if (entry->next) {
|
|
|
|
entry->next->prev = entry->prev;
|
|
|
|
} else {
|
|
|
|
tail = entry->prev;
|
|
|
|
}
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
inline T* dequeueAtHead() {
|
2011-07-20 15:19:50 -07:00
|
|
|
T* entry = head;
|
|
|
|
head = entry->next;
|
|
|
|
if (head) {
|
|
|
|
head->prev = NULL;
|
|
|
|
} else {
|
|
|
|
tail = NULL;
|
|
|
|
}
|
|
|
|
return entry;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
}
|
2010-09-15 15:18:56 -07:00
|
|
|
|
|
|
|
uint32_t count() const;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
};
|
|
|
|
|
2011-03-29 15:11:34 -07:00
|
|
|
/* Specifies which events are to be canceled and why. */
|
|
|
|
struct CancelationOptions {
|
|
|
|
enum Mode {
|
2010-10-08 22:31:17 -07:00
|
|
|
CANCEL_ALL_EVENTS = 0,
|
|
|
|
CANCEL_POINTER_EVENTS = 1,
|
|
|
|
CANCEL_NON_POINTER_EVENTS = 2,
|
2010-12-06 17:13:33 -08:00
|
|
|
CANCEL_FALLBACK_EVENTS = 3,
|
2010-10-08 22:31:17 -07:00
|
|
|
};
|
|
|
|
|
2011-03-29 15:11:34 -07:00
|
|
|
// The criterion to use to determine which events should be canceled.
|
|
|
|
Mode mode;
|
|
|
|
|
|
|
|
// Descriptive reason for the cancelation.
|
|
|
|
const char* reason;
|
|
|
|
|
|
|
|
// The specific keycode of the key event to cancel, or -1 to cancel any key event.
|
|
|
|
int32_t keyCode;
|
|
|
|
|
2011-08-18 11:20:58 -07:00
|
|
|
// The specific device id of events to cancel, or -1 to cancel events from any device.
|
|
|
|
int32_t deviceId;
|
|
|
|
|
2011-03-29 15:11:34 -07:00
|
|
|
CancelationOptions(Mode mode, const char* reason) :
|
2011-08-18 11:20:58 -07:00
|
|
|
mode(mode), reason(reason), keyCode(-1), deviceId(-1) { }
|
2011-03-29 15:11:34 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Tracks dispatched key and motion event state so that cancelation events can be
|
|
|
|
* synthesized when events are dropped. */
|
|
|
|
class InputState {
|
|
|
|
public:
|
2010-09-08 11:49:43 -07:00
|
|
|
InputState();
|
|
|
|
~InputState();
|
|
|
|
|
|
|
|
// Returns true if there is no state to be canceled.
|
|
|
|
bool isNeutral() const;
|
|
|
|
|
2011-06-28 20:08:48 -07:00
|
|
|
// Returns true if the specified source is known to have received a hover enter
|
|
|
|
// motion event.
|
|
|
|
bool isHovering(int32_t deviceId, uint32_t source) const;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
// Records tracking information for a key event that has just been published.
|
2011-06-28 20:08:48 -07:00
|
|
|
// Returns true if the event should be delivered, false if it is inconsistent
|
|
|
|
// and should be skipped.
|
|
|
|
bool trackKey(const KeyEntry* entry, int32_t action, int32_t flags);
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
// Records tracking information for a motion event that has just been published.
|
2011-06-28 20:08:48 -07:00
|
|
|
// Returns true if the event should be delivered, false if it is inconsistent
|
|
|
|
// and should be skipped.
|
|
|
|
bool trackMotion(const MotionEntry* entry, int32_t action, int32_t flags);
|
2010-09-08 11:49:43 -07:00
|
|
|
|
2010-10-08 22:31:17 -07:00
|
|
|
// Synthesizes cancelation events for the current state and resets the tracked state.
|
2011-07-20 15:19:50 -07:00
|
|
|
void synthesizeCancelationEvents(nsecs_t currentTime,
|
2011-03-29 15:11:34 -07:00
|
|
|
Vector<EventEntry*>& outEvents, const CancelationOptions& options);
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
// Clears the current state.
|
|
|
|
void clear();
|
|
|
|
|
2010-10-11 18:32:20 -07:00
|
|
|
// Copies pointer-related parts of the input state to another instance.
|
|
|
|
void copyPointerStateTo(InputState& other) const;
|
|
|
|
|
2011-03-29 15:11:34 -07:00
|
|
|
// Gets the fallback key associated with a keycode.
|
|
|
|
// Returns -1 if none.
|
|
|
|
// Returns AKEYCODE_UNKNOWN if we are only dispatching the unhandled key to the policy.
|
|
|
|
int32_t getFallbackKey(int32_t originalKeyCode);
|
|
|
|
|
|
|
|
// Sets the fallback key for a particular keycode.
|
|
|
|
void setFallbackKey(int32_t originalKeyCode, int32_t fallbackKeyCode);
|
|
|
|
|
|
|
|
// Removes the fallback key for a particular keycode.
|
|
|
|
void removeFallbackKey(int32_t originalKeyCode);
|
|
|
|
|
|
|
|
inline const KeyedVector<int32_t, int32_t>& getFallbackKeys() const {
|
|
|
|
return mFallbackKeys;
|
|
|
|
}
|
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
private:
|
|
|
|
struct KeyMemento {
|
|
|
|
int32_t deviceId;
|
2011-01-25 16:02:22 -08:00
|
|
|
uint32_t source;
|
2010-09-08 11:49:43 -07:00
|
|
|
int32_t keyCode;
|
|
|
|
int32_t scanCode;
|
2010-12-06 17:13:33 -08:00
|
|
|
int32_t flags;
|
2010-09-08 11:49:43 -07:00
|
|
|
nsecs_t downTime;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct MotionMemento {
|
|
|
|
int32_t deviceId;
|
2011-01-25 16:02:22 -08:00
|
|
|
uint32_t source;
|
2011-06-28 20:08:48 -07:00
|
|
|
int32_t flags;
|
2010-09-08 11:49:43 -07:00
|
|
|
float xPrecision;
|
|
|
|
float yPrecision;
|
|
|
|
nsecs_t downTime;
|
|
|
|
uint32_t pointerCount;
|
2011-05-06 18:20:01 -07:00
|
|
|
PointerProperties pointerProperties[MAX_POINTERS];
|
2010-09-08 11:49:43 -07:00
|
|
|
PointerCoords pointerCoords[MAX_POINTERS];
|
2011-03-07 16:56:21 -08:00
|
|
|
bool hovering;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
void setPointers(const MotionEntry* entry);
|
|
|
|
};
|
|
|
|
|
|
|
|
Vector<KeyMemento> mKeyMementos;
|
|
|
|
Vector<MotionMemento> mMotionMementos;
|
2011-03-29 15:11:34 -07:00
|
|
|
KeyedVector<int32_t, int32_t> mFallbackKeys;
|
2010-10-08 22:31:17 -07:00
|
|
|
|
2011-06-28 20:08:48 -07:00
|
|
|
ssize_t findKeyMemento(const KeyEntry* entry) const;
|
|
|
|
ssize_t findMotionMemento(const MotionEntry* entry, bool hovering) const;
|
|
|
|
|
|
|
|
void addKeyMemento(const KeyEntry* entry, int32_t flags);
|
|
|
|
void addMotionMemento(const MotionEntry* entry, int32_t flags, bool hovering);
|
|
|
|
|
2010-12-06 17:13:33 -08:00
|
|
|
static bool shouldCancelKey(const KeyMemento& memento,
|
2011-03-29 15:11:34 -07:00
|
|
|
const CancelationOptions& options);
|
2010-12-06 17:13:33 -08:00
|
|
|
static bool shouldCancelMotion(const MotionMemento& memento,
|
2011-03-29 15:11:34 -07:00
|
|
|
const CancelationOptions& options);
|
2010-09-08 11:49:43 -07:00
|
|
|
};
|
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
/* Manages the dispatch state associated with a single input channel. */
|
|
|
|
class Connection : public RefBase {
|
|
|
|
protected:
|
|
|
|
virtual ~Connection();
|
|
|
|
|
|
|
|
public:
|
|
|
|
enum Status {
|
|
|
|
// Everything is peachy.
|
|
|
|
STATUS_NORMAL,
|
|
|
|
// An unrecoverable communication error has occurred.
|
|
|
|
STATUS_BROKEN,
|
|
|
|
// The input channel has been unregistered.
|
|
|
|
STATUS_ZOMBIE
|
|
|
|
};
|
|
|
|
|
|
|
|
Status status;
|
2011-01-10 11:17:36 -08:00
|
|
|
sp<InputChannel> inputChannel; // never null
|
|
|
|
sp<InputWindowHandle> inputWindowHandle; // may be null
|
2011-08-30 20:34:48 -07:00
|
|
|
bool monitor;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
InputPublisher inputPublisher;
|
2010-09-08 11:49:43 -07:00
|
|
|
InputState inputState;
|
2012-02-06 19:12:47 -08:00
|
|
|
|
|
|
|
// True if the socket is full and no further events can be published until
|
|
|
|
// the application consumes some of the input.
|
|
|
|
bool inputPublisherBlocked;
|
|
|
|
|
|
|
|
// Queue of events that need to be published to the connection.
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
Queue<DispatchEntry> outboundQueue;
|
|
|
|
|
2012-02-06 19:12:47 -08:00
|
|
|
// Queue of events that have been published to the connection but that have not
|
|
|
|
// yet received a "finished" response from the application.
|
|
|
|
Queue<DispatchEntry> waitQueue;
|
|
|
|
|
2011-01-10 11:17:36 -08:00
|
|
|
explicit Connection(const sp<InputChannel>& inputChannel,
|
2011-08-30 20:34:48 -07:00
|
|
|
const sp<InputWindowHandle>& inputWindowHandle, bool monitor);
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2010-06-15 01:31:58 -07:00
|
|
|
inline const char* getInputChannelName() const { return inputChannel->getName().string(); }
|
|
|
|
|
2012-03-09 14:41:15 -08:00
|
|
|
const char* getWindowName() const;
|
2010-06-15 01:31:58 -07:00
|
|
|
const char* getStatusLabel() const;
|
2012-02-07 14:46:57 -08:00
|
|
|
|
|
|
|
DispatchEntry* findWaitQueueEntry(uint32_t seq);
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
};
|
|
|
|
|
2010-10-08 22:31:17 -07:00
|
|
|
enum DropReason {
|
|
|
|
DROP_REASON_NOT_DROPPED = 0,
|
|
|
|
DROP_REASON_POLICY = 1,
|
|
|
|
DROP_REASON_APP_SWITCH = 2,
|
|
|
|
DROP_REASON_DISABLED = 3,
|
2011-01-10 11:17:36 -08:00
|
|
|
DROP_REASON_BLOCKED = 4,
|
|
|
|
DROP_REASON_STALE = 5,
|
2010-10-08 22:31:17 -07:00
|
|
|
};
|
|
|
|
|
2010-06-15 01:31:58 -07:00
|
|
|
sp<InputDispatcherPolicyInterface> mPolicy;
|
2011-05-26 19:17:02 -07:00
|
|
|
InputDispatcherConfiguration mConfig;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
|
|
|
Mutex mLock;
|
|
|
|
|
2012-01-27 17:32:06 -08:00
|
|
|
Condition mDispatcherIsAliveCondition;
|
|
|
|
|
2010-09-13 23:17:30 -07:00
|
|
|
sp<Looper> mLooper;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
EventEntry* mPendingEvent;
|
2010-06-15 01:31:58 -07:00
|
|
|
Queue<EventEntry> mInboundQueue;
|
|
|
|
Queue<CommandEntry> mCommandQueue;
|
|
|
|
|
2011-05-26 19:17:02 -07:00
|
|
|
void dispatchOnceInnerLocked(nsecs_t* nextWakeupTime);
|
2010-09-08 11:49:43 -07:00
|
|
|
|
2010-09-13 23:17:30 -07:00
|
|
|
// Enqueues an inbound event. Returns true if mLooper->wake() should be called.
|
2010-09-08 11:49:43 -07:00
|
|
|
bool enqueueInboundEventLocked(EventEntry* entry);
|
|
|
|
|
2010-10-08 22:31:17 -07:00
|
|
|
// Cleans up input state when dropping an inbound event.
|
|
|
|
void dropInboundEventLocked(EventEntry* entry, DropReason dropReason);
|
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
// App switch latency optimization.
|
2010-10-08 22:31:17 -07:00
|
|
|
bool mAppSwitchSawKeyDown;
|
2010-09-08 11:49:43 -07:00
|
|
|
nsecs_t mAppSwitchDueTime;
|
|
|
|
|
2010-10-08 22:31:17 -07:00
|
|
|
static bool isAppSwitchKeyCode(int32_t keyCode);
|
|
|
|
bool isAppSwitchKeyEventLocked(KeyEntry* keyEntry);
|
2010-09-08 11:49:43 -07:00
|
|
|
bool isAppSwitchPendingLocked();
|
|
|
|
void resetPendingAppSwitchLocked(bool handled);
|
|
|
|
|
2011-01-10 11:17:36 -08:00
|
|
|
// Stale event latency optimization.
|
|
|
|
static bool isStaleEventLocked(nsecs_t currentTime, EventEntry* entry);
|
|
|
|
|
|
|
|
// Blocked event latency optimization. Drops old events when the user intends
|
|
|
|
// to transfer focus to a new application.
|
|
|
|
EventEntry* mNextUnblockedEvent;
|
|
|
|
|
2011-07-13 22:51:29 -07:00
|
|
|
sp<InputWindowHandle> findTouchedWindowAtLocked(int32_t x, int32_t y);
|
2011-01-10 11:17:36 -08:00
|
|
|
|
2012-02-03 20:11:27 -08:00
|
|
|
// All registered connections mapped by channel file descriptor.
|
|
|
|
KeyedVector<int, sp<Connection> > mConnectionsByFd;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2010-09-15 15:18:56 -07:00
|
|
|
ssize_t getConnectionIndexLocked(const sp<InputChannel>& inputChannel);
|
2010-08-17 15:59:26 -07:00
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
// Input channels that will receive a copy of all input events.
|
|
|
|
Vector<sp<InputChannel> > mMonitoringChannels;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2010-06-17 20:52:56 -07:00
|
|
|
// Event injection and synchronization.
|
|
|
|
Condition mInjectionResultAvailableCondition;
|
2010-10-08 22:31:17 -07:00
|
|
|
bool hasInjectionPermission(int32_t injectorPid, int32_t injectorUid);
|
2010-06-17 20:52:56 -07:00
|
|
|
void setInjectionResultLocked(EventEntry* entry, int32_t injectionResult);
|
|
|
|
|
2010-07-28 15:48:59 -07:00
|
|
|
Condition mInjectionSyncFinishedCondition;
|
2010-09-26 22:20:12 -07:00
|
|
|
void incrementPendingForegroundDispatchesLocked(EventEntry* entry);
|
2010-09-15 15:18:56 -07:00
|
|
|
void decrementPendingForegroundDispatchesLocked(EventEntry* entry);
|
2010-07-28 15:48:59 -07:00
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
// Key repeat tracking.
|
|
|
|
struct KeyRepeatState {
|
|
|
|
KeyEntry* lastKeyEntry; // or null if no repeat
|
|
|
|
nsecs_t nextRepeatTime;
|
|
|
|
} mKeyRepeatState;
|
|
|
|
|
|
|
|
void resetKeyRepeatLocked();
|
2011-05-26 19:17:02 -07:00
|
|
|
KeyEntry* synthesizeKeyRepeatLocked(nsecs_t currentTime);
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2010-06-15 01:31:58 -07:00
|
|
|
// Deferred command processing.
|
|
|
|
bool runCommandsLockedInterruptible();
|
|
|
|
CommandEntry* postCommandLocked(Command command);
|
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
// Inbound event processing.
|
|
|
|
void drainInboundQueueLocked();
|
2010-09-16 14:07:33 -07:00
|
|
|
void releasePendingEventLocked();
|
|
|
|
void releaseInboundEventLocked(EventEntry* entry);
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
// Dispatch state.
|
|
|
|
bool mDispatchEnabled;
|
|
|
|
bool mDispatchFrozen;
|
2011-03-30 02:25:18 -07:00
|
|
|
bool mInputFilterEnabled;
|
2010-09-26 22:20:12 -07:00
|
|
|
|
2011-07-13 22:51:29 -07:00
|
|
|
Vector<sp<InputWindowHandle> > mWindowHandles;
|
2010-09-26 22:20:12 -07:00
|
|
|
|
2011-07-13 22:51:29 -07:00
|
|
|
sp<InputWindowHandle> getWindowHandleLocked(const sp<InputChannel>& inputChannel) const;
|
|
|
|
bool hasWindowHandleLocked(const sp<InputWindowHandle>& windowHandle) const;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
// Focus tracking for keys, trackball, etc.
|
2011-07-13 22:51:29 -07:00
|
|
|
sp<InputWindowHandle> mFocusedWindowHandle;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
// Focus tracking for touch.
|
2010-09-26 22:20:12 -07:00
|
|
|
struct TouchedWindow {
|
2011-07-13 22:51:29 -07:00
|
|
|
sp<InputWindowHandle> windowHandle;
|
2010-09-26 22:20:12 -07:00
|
|
|
int32_t targetFlags;
|
2010-11-10 16:53:45 -08:00
|
|
|
BitSet32 pointerIds; // zero unless target flag FLAG_SPLIT is set
|
2010-09-26 22:20:12 -07:00
|
|
|
};
|
|
|
|
struct TouchState {
|
|
|
|
bool down;
|
|
|
|
bool split;
|
2011-01-04 19:41:59 -08:00
|
|
|
int32_t deviceId; // id of the device that is currently down, others are rejected
|
2011-01-25 16:02:22 -08:00
|
|
|
uint32_t source; // source of the device that is current down, others are rejected
|
2010-09-26 22:20:12 -07:00
|
|
|
Vector<TouchedWindow> windows;
|
|
|
|
|
|
|
|
TouchState();
|
|
|
|
~TouchState();
|
|
|
|
void reset();
|
|
|
|
void copyFrom(const TouchState& other);
|
2011-07-13 22:51:29 -07:00
|
|
|
void addOrUpdateWindow(const sp<InputWindowHandle>& windowHandle,
|
|
|
|
int32_t targetFlags, BitSet32 pointerIds);
|
2011-03-07 16:56:21 -08:00
|
|
|
void filterNonAsIsTouchWindows();
|
2011-07-13 22:51:29 -07:00
|
|
|
sp<InputWindowHandle> getFirstForegroundWindowHandle() const;
|
2011-06-08 15:37:10 -07:00
|
|
|
bool isSlippery() const;
|
2010-09-08 11:49:43 -07:00
|
|
|
};
|
2010-09-26 22:20:12 -07:00
|
|
|
|
|
|
|
TouchState mTouchState;
|
|
|
|
TouchState mTempTouchState;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
// Focused application.
|
2011-07-13 22:51:29 -07:00
|
|
|
sp<InputApplicationHandle> mFocusedApplicationHandle;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
|
|
|
// Dispatch inbound events.
|
|
|
|
bool dispatchConfigurationChangedLocked(
|
2010-06-15 01:31:58 -07:00
|
|
|
nsecs_t currentTime, ConfigurationChangedEntry* entry);
|
2011-08-18 11:20:58 -07:00
|
|
|
bool dispatchDeviceResetLocked(
|
|
|
|
nsecs_t currentTime, DeviceResetEntry* entry);
|
2010-09-08 11:49:43 -07:00
|
|
|
bool dispatchKeyLocked(
|
2011-05-26 19:17:02 -07:00
|
|
|
nsecs_t currentTime, KeyEntry* entry,
|
2010-10-11 14:20:19 -07:00
|
|
|
DropReason* dropReason, nsecs_t* nextWakeupTime);
|
2010-09-08 11:49:43 -07:00
|
|
|
bool dispatchMotionLocked(
|
|
|
|
nsecs_t currentTime, MotionEntry* entry,
|
2010-10-11 14:20:19 -07:00
|
|
|
DropReason* dropReason, nsecs_t* nextWakeupTime);
|
2012-02-06 15:47:55 -08:00
|
|
|
void dispatchEventLocked(nsecs_t currentTime, EventEntry* entry,
|
|
|
|
const Vector<InputTarget>& inputTargets);
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
void logOutboundKeyDetailsLocked(const char* prefix, const KeyEntry* entry);
|
|
|
|
void logOutboundMotionDetailsLocked(const char* prefix, const MotionEntry* entry);
|
|
|
|
|
2012-02-06 15:47:55 -08:00
|
|
|
// Keeping track of ANR timeouts.
|
2010-09-08 11:49:43 -07:00
|
|
|
enum InputTargetWaitCause {
|
|
|
|
INPUT_TARGET_WAIT_CAUSE_NONE,
|
|
|
|
INPUT_TARGET_WAIT_CAUSE_SYSTEM_NOT_READY,
|
|
|
|
INPUT_TARGET_WAIT_CAUSE_APPLICATION_NOT_READY,
|
|
|
|
};
|
|
|
|
|
|
|
|
InputTargetWaitCause mInputTargetWaitCause;
|
|
|
|
nsecs_t mInputTargetWaitStartTime;
|
|
|
|
nsecs_t mInputTargetWaitTimeoutTime;
|
|
|
|
bool mInputTargetWaitTimeoutExpired;
|
2011-07-13 22:51:29 -07:00
|
|
|
sp<InputApplicationHandle> mInputTargetWaitApplicationHandle;
|
2010-09-08 11:49:43 -07:00
|
|
|
|
2011-03-07 16:56:21 -08:00
|
|
|
// Contains the last window which received a hover event.
|
2011-07-13 22:51:29 -07:00
|
|
|
sp<InputWindowHandle> mLastHoverWindowHandle;
|
2011-03-07 16:56:21 -08:00
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
// Finding targets for input events.
|
|
|
|
int32_t handleTargetsNotReadyLocked(nsecs_t currentTime, const EventEntry* entry,
|
2011-07-13 22:51:29 -07:00
|
|
|
const sp<InputApplicationHandle>& applicationHandle,
|
|
|
|
const sp<InputWindowHandle>& windowHandle,
|
2010-09-08 11:49:43 -07:00
|
|
|
nsecs_t* nextWakeupTime);
|
2010-09-15 15:18:56 -07:00
|
|
|
void resumeAfterTargetsNotReadyTimeoutLocked(nsecs_t newTimeout,
|
|
|
|
const sp<InputChannel>& inputChannel);
|
|
|
|
nsecs_t getTimeSpentWaitingForApplicationLocked(nsecs_t currentTime);
|
2010-09-08 11:49:43 -07:00
|
|
|
void resetANRTimeoutsLocked();
|
|
|
|
|
2010-09-26 22:20:12 -07:00
|
|
|
int32_t findFocusedWindowTargetsLocked(nsecs_t currentTime, const EventEntry* entry,
|
2012-02-06 15:47:55 -08:00
|
|
|
Vector<InputTarget>& inputTargets, nsecs_t* nextWakeupTime);
|
2010-09-26 22:20:12 -07:00
|
|
|
int32_t findTouchedWindowTargetsLocked(nsecs_t currentTime, const MotionEntry* entry,
|
2012-02-06 15:47:55 -08:00
|
|
|
Vector<InputTarget>& inputTargets, nsecs_t* nextWakeupTime,
|
|
|
|
bool* outConflictingPointerActions);
|
2010-09-08 11:49:43 -07:00
|
|
|
|
2011-07-13 22:51:29 -07:00
|
|
|
void addWindowTargetLocked(const sp<InputWindowHandle>& windowHandle,
|
2012-02-06 15:47:55 -08:00
|
|
|
int32_t targetFlags, BitSet32 pointerIds, Vector<InputTarget>& inputTargets);
|
|
|
|
void addMonitoringTargetsLocked(Vector<InputTarget>& inputTargets);
|
|
|
|
|
2010-10-18 13:21:23 -07:00
|
|
|
void pokeUserActivityLocked(const EventEntry* eventEntry);
|
2011-07-13 22:51:29 -07:00
|
|
|
bool checkInjectionPermission(const sp<InputWindowHandle>& windowHandle,
|
|
|
|
const InjectionState* injectionState);
|
|
|
|
bool isWindowObscuredAtPointLocked(const sp<InputWindowHandle>& windowHandle,
|
|
|
|
int32_t x, int32_t y) const;
|
2012-02-06 19:12:47 -08:00
|
|
|
bool isWindowReadyForMoreInputLocked(nsecs_t currentTime,
|
2012-02-13 13:48:59 -08:00
|
|
|
const sp<InputWindowHandle>& windowHandle, const EventEntry* eventEntry);
|
2011-07-13 22:51:29 -07:00
|
|
|
String8 getApplicationWindowLabelLocked(const sp<InputApplicationHandle>& applicationHandle,
|
|
|
|
const sp<InputWindowHandle>& windowHandle);
|
2010-09-08 11:49:43 -07:00
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
// Manage the dispatch cycle for a single connection.
|
2010-06-17 20:52:56 -07:00
|
|
|
// These methods are deliberately not Interruptible because doing all of the work
|
|
|
|
// with the mutex held makes it easier to ensure that connection invariants are maintained.
|
|
|
|
// If needed, the methods post commands to run later once the critical bits are done.
|
|
|
|
void prepareDispatchCycleLocked(nsecs_t currentTime, const sp<Connection>& connection,
|
2012-02-03 15:08:02 -08:00
|
|
|
EventEntry* eventEntry, const InputTarget* inputTarget);
|
2012-01-12 18:30:12 -08:00
|
|
|
void enqueueDispatchEntriesLocked(nsecs_t currentTime, const sp<Connection>& connection,
|
2012-02-03 15:08:02 -08:00
|
|
|
EventEntry* eventEntry, const InputTarget* inputTarget);
|
2011-03-07 16:56:21 -08:00
|
|
|
void enqueueDispatchEntryLocked(const sp<Connection>& connection,
|
2012-02-03 15:08:02 -08:00
|
|
|
EventEntry* eventEntry, const InputTarget* inputTarget, int32_t dispatchMode);
|
2010-09-15 15:18:56 -07:00
|
|
|
void startDispatchCycleLocked(nsecs_t currentTime, const sp<Connection>& connection);
|
2010-11-05 15:02:16 -07:00
|
|
|
void finishDispatchCycleLocked(nsecs_t currentTime, const sp<Connection>& connection,
|
2012-02-07 14:46:57 -08:00
|
|
|
uint32_t seq, bool handled);
|
2011-08-30 20:34:48 -07:00
|
|
|
void abortBrokenDispatchCycleLocked(nsecs_t currentTime, const sp<Connection>& connection,
|
|
|
|
bool notify);
|
2012-02-06 19:12:47 -08:00
|
|
|
void drainDispatchQueueLocked(Queue<DispatchEntry>* queue);
|
|
|
|
void releaseDispatchEntryLocked(DispatchEntry* dispatchEntry);
|
2012-02-03 20:11:27 -08:00
|
|
|
static int handleReceiveCallback(int fd, int events, void* data);
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
|
2010-10-08 22:31:17 -07:00
|
|
|
void synthesizeCancelationEventsForAllConnectionsLocked(
|
2011-03-29 15:11:34 -07:00
|
|
|
const CancelationOptions& options);
|
2010-10-08 22:31:17 -07:00
|
|
|
void synthesizeCancelationEventsForInputChannelLocked(const sp<InputChannel>& channel,
|
2011-03-29 15:11:34 -07:00
|
|
|
const CancelationOptions& options);
|
2010-10-08 22:31:17 -07:00
|
|
|
void synthesizeCancelationEventsForConnectionLocked(const sp<Connection>& connection,
|
2011-03-29 15:11:34 -07:00
|
|
|
const CancelationOptions& options);
|
2010-10-08 22:31:17 -07:00
|
|
|
|
2010-09-26 22:20:12 -07:00
|
|
|
// Splitting motion events across windows.
|
|
|
|
MotionEntry* splitMotionEvent(const MotionEntry* originalMotionEntry, BitSet32 pointerIds);
|
|
|
|
|
2010-10-27 18:43:51 -07:00
|
|
|
// Reset and drop everything the dispatcher is doing.
|
|
|
|
void resetAndDropEverythingLocked(const char* reason);
|
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
// Dump state.
|
|
|
|
void dumpDispatchStateLocked(String8& dump);
|
|
|
|
void logDispatchStateLocked();
|
|
|
|
|
2011-08-30 20:34:48 -07:00
|
|
|
// Registration.
|
|
|
|
void removeMonitorChannelLocked(const sp<InputChannel>& inputChannel);
|
|
|
|
status_t unregisterInputChannelLocked(const sp<InputChannel>& inputChannel, bool notify);
|
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
// Add or remove a connection to the mActiveConnections vector.
|
|
|
|
void activateConnectionLocked(Connection* connection);
|
|
|
|
void deactivateConnectionLocked(Connection* connection);
|
|
|
|
|
|
|
|
// Interesting events that we might like to log or tell the framework about.
|
2010-06-15 01:31:58 -07:00
|
|
|
void onDispatchCycleFinishedLocked(
|
2012-02-07 14:46:57 -08:00
|
|
|
nsecs_t currentTime, const sp<Connection>& connection, uint32_t seq, bool handled);
|
2010-06-15 01:31:58 -07:00
|
|
|
void onDispatchCycleBrokenLocked(
|
2010-06-17 20:52:56 -07:00
|
|
|
nsecs_t currentTime, const sp<Connection>& connection);
|
2010-09-15 15:18:56 -07:00
|
|
|
void onANRLocked(
|
2011-07-13 22:51:29 -07:00
|
|
|
nsecs_t currentTime, const sp<InputApplicationHandle>& applicationHandle,
|
|
|
|
const sp<InputWindowHandle>& windowHandle,
|
2010-09-15 15:18:56 -07:00
|
|
|
nsecs_t eventTime, nsecs_t waitStartTime);
|
2010-06-15 01:31:58 -07:00
|
|
|
|
2010-06-17 20:52:56 -07:00
|
|
|
// Outbound policy interactions.
|
2010-09-08 11:49:43 -07:00
|
|
|
void doNotifyConfigurationChangedInterruptible(CommandEntry* commandEntry);
|
2010-06-15 01:31:58 -07:00
|
|
|
void doNotifyInputChannelBrokenLockedInterruptible(CommandEntry* commandEntry);
|
2010-09-15 15:18:56 -07:00
|
|
|
void doNotifyANRLockedInterruptible(CommandEntry* commandEntry);
|
2010-09-08 11:49:43 -07:00
|
|
|
void doInterceptKeyBeforeDispatchingLockedInterruptible(CommandEntry* commandEntry);
|
2010-11-05 15:02:16 -07:00
|
|
|
void doDispatchCycleFinishedLockedInterruptible(CommandEntry* commandEntry);
|
2011-05-06 18:20:01 -07:00
|
|
|
bool afterKeyEventLockedInterruptible(const sp<Connection>& connection,
|
|
|
|
DispatchEntry* dispatchEntry, KeyEntry* keyEntry, bool handled);
|
|
|
|
bool afterMotionEventLockedInterruptible(const sp<Connection>& connection,
|
|
|
|
DispatchEntry* dispatchEntry, MotionEntry* motionEntry, bool handled);
|
2010-09-08 11:49:43 -07:00
|
|
|
void doPokeUserActivityLockedInterruptible(CommandEntry* commandEntry);
|
2010-11-05 15:02:16 -07:00
|
|
|
void initializeKeyEvent(KeyEvent* event, const KeyEntry* entry);
|
2010-09-15 15:18:56 -07:00
|
|
|
|
|
|
|
// Statistics gathering.
|
|
|
|
void updateDispatchStatisticsLocked(nsecs_t currentTime, const EventEntry* entry,
|
|
|
|
int32_t injectionResult, nsecs_t timeSpentWaitingForApplication);
|
2012-03-09 14:41:15 -08:00
|
|
|
void traceInboundQueueLengthLocked();
|
|
|
|
void traceOutboundQueueLengthLocked(const sp<Connection>& connection);
|
|
|
|
void traceWaitQueueLengthLocked(const sp<Connection>& connection);
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-22 18:58:52 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Enqueues and dispatches input events, endlessly. */
|
|
|
|
class InputDispatcherThread : public Thread {
|
|
|
|
public:
|
|
|
|
explicit InputDispatcherThread(const sp<InputDispatcherInterface>& dispatcher);
|
|
|
|
~InputDispatcherThread();
|
|
|
|
|
|
|
|
private:
|
|
|
|
virtual bool threadLoop();
|
|
|
|
|
|
|
|
sp<InputDispatcherInterface> mDispatcher;
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace android
|
|
|
|
|
2010-09-08 11:49:43 -07:00
|
|
|
#endif // _UI_INPUT_DISPATCHER_H
|