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-23 01:58:52 +00: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_H
|
|
|
|
#define _UI_INPUT_H
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Native input event structures.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <android/input.h>
|
|
|
|
#include <utils/Vector.h>
|
2010-07-24 04:28:06 +00:00
|
|
|
#include <utils/KeyedVector.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-23 01:58:52 +00:00
|
|
|
#include <utils/Timers.h>
|
2010-07-24 04:28:06 +00:00
|
|
|
#include <utils/RefBase.h>
|
|
|
|
#include <utils/String8.h>
|
2011-03-10 01:39:48 +00:00
|
|
|
#include <utils/BitSet.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-23 01:58:52 +00:00
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
#ifdef HAVE_ANDROID_OS
|
|
|
|
class SkMatrix;
|
|
|
|
#endif
|
|
|
|
|
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-23 01:58:52 +00:00
|
|
|
/*
|
|
|
|
* Additional private constants not defined in ndk/ui/input.h.
|
|
|
|
*/
|
|
|
|
enum {
|
2011-03-01 02:27:14 +00:00
|
|
|
/* Private control to determine when an app is tracking a key sequence. */
|
|
|
|
AKEY_EVENT_FLAG_START_TRACKING = 0x40000000,
|
|
|
|
|
|
|
|
/* Key event is inconsistent with previously sent key events. */
|
|
|
|
AKEY_EVENT_FLAG_TAINTED = 0x80000000,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
/* Motion event is inconsistent with previously sent motion events. */
|
|
|
|
AMOTION_EVENT_FLAG_TAINTED = 0x80000000,
|
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-23 01:58:52 +00:00
|
|
|
};
|
|
|
|
|
2011-01-20 02:41:38 +00:00
|
|
|
enum {
|
|
|
|
/*
|
|
|
|
* Indicates that an input device has switches.
|
|
|
|
* This input source flag is hidden from the API because switches are only used by the system
|
|
|
|
* and applications have no way to interact with them.
|
|
|
|
*/
|
|
|
|
AINPUT_SOURCE_SWITCH = 0x80000000,
|
|
|
|
};
|
|
|
|
|
2011-03-02 22:41:58 +00:00
|
|
|
/*
|
|
|
|
* SystemUiVisibility constants from View.
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
ASYSTEM_UI_VISIBILITY_STATUS_BAR_VISIBLE = 0,
|
|
|
|
ASYSTEM_UI_VISIBILITY_STATUS_BAR_HIDDEN = 0x00000001,
|
|
|
|
};
|
|
|
|
|
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-23 01:58:52 +00:00
|
|
|
/*
|
|
|
|
* Maximum number of pointers supported per motion event.
|
2010-09-27 05:20:12 +00:00
|
|
|
* Smallest number of pointers is 1.
|
2011-01-26 00:02:22 +00:00
|
|
|
* (We want at least 10 but some touch controllers obstensibly configured for 10 pointers
|
|
|
|
* will occasionally emit 11. There is not much harm making this constant bigger.)
|
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-23 01:58:52 +00:00
|
|
|
*/
|
2011-01-26 00:02:22 +00:00
|
|
|
#define MAX_POINTERS 16
|
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-23 01:58:52 +00:00
|
|
|
|
2010-09-27 05:20:12 +00:00
|
|
|
/*
|
|
|
|
* Maximum pointer id value supported in a motion event.
|
|
|
|
* Smallest pointer id is 0.
|
|
|
|
* (This is limited by our use of BitSet32 to track pointer assignments.)
|
|
|
|
*/
|
|
|
|
#define MAX_POINTER_ID 31
|
|
|
|
|
2010-06-19 01:09:33 +00:00
|
|
|
/*
|
|
|
|
* Declare a concrete type for the NDK's input event forward declaration.
|
|
|
|
*/
|
2010-07-14 00:48:30 +00:00
|
|
|
struct AInputEvent {
|
|
|
|
virtual ~AInputEvent() { }
|
|
|
|
};
|
2010-06-19 01:09:33 +00: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-23 01:58:52 +00:00
|
|
|
/*
|
2010-07-24 04:28:06 +00:00
|
|
|
* Declare a concrete type for the NDK's input device forward declaration.
|
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-23 01:58:52 +00:00
|
|
|
*/
|
2010-07-24 04:28:06 +00:00
|
|
|
struct AInputDevice {
|
|
|
|
virtual ~AInputDevice() { }
|
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-23 01:58:52 +00:00
|
|
|
};
|
|
|
|
|
2010-07-24 04:28:06 +00:00
|
|
|
|
|
|
|
namespace android {
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
#ifdef HAVE_ANDROID_OS
|
|
|
|
class Parcel;
|
|
|
|
#endif
|
|
|
|
|
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-23 01:58:52 +00:00
|
|
|
/*
|
|
|
|
* Flags that flow alongside events in the input dispatch system to help with certain
|
|
|
|
* policy decisions such as waking from device sleep.
|
2010-10-09 05:31:17 +00:00
|
|
|
*
|
|
|
|
* These flags are also defined in frameworks/base/core/java/android/view/WindowManagerPolicy.java.
|
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-23 01:58:52 +00:00
|
|
|
*/
|
|
|
|
enum {
|
2010-10-01 21:55:30 +00:00
|
|
|
/* These flags originate in RawEvents and are generally set in the key map.
|
2010-09-13 00:55:08 +00:00
|
|
|
* NOTE: If you edit these flags, also edit labels in KeycodeLabels.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-23 01:58:52 +00:00
|
|
|
|
|
|
|
POLICY_FLAG_WAKE = 0x00000001,
|
|
|
|
POLICY_FLAG_WAKE_DROPPED = 0x00000002,
|
|
|
|
POLICY_FLAG_SHIFT = 0x00000004,
|
|
|
|
POLICY_FLAG_CAPS_LOCK = 0x00000008,
|
|
|
|
POLICY_FLAG_ALT = 0x00000010,
|
|
|
|
POLICY_FLAG_ALT_GR = 0x00000020,
|
|
|
|
POLICY_FLAG_MENU = 0x00000040,
|
|
|
|
POLICY_FLAG_LAUNCHER = 0x00000080,
|
2010-10-01 21:55:30 +00:00
|
|
|
POLICY_FLAG_VIRTUAL = 0x00000100,
|
2010-09-13 00:55:08 +00:00
|
|
|
POLICY_FLAG_FUNCTION = 0x00000200,
|
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-23 01:58:52 +00:00
|
|
|
|
2010-06-18 03:52:56 +00:00
|
|
|
POLICY_FLAG_RAW_MASK = 0x0000ffff,
|
|
|
|
|
2010-09-02 00:01:00 +00:00
|
|
|
/* These flags are set by the input dispatcher. */
|
|
|
|
|
|
|
|
// Indicates that the input event was injected.
|
|
|
|
POLICY_FLAG_INJECTED = 0x01000000,
|
|
|
|
|
2010-10-11 21:20:19 +00:00
|
|
|
// Indicates that the input event is from a trusted source such as a directly attached
|
|
|
|
// input device or an application with system-wide event injection permission.
|
|
|
|
POLICY_FLAG_TRUSTED = 0x02000000,
|
|
|
|
|
2011-03-30 09:25:18 +00:00
|
|
|
// Indicates that the input event has passed through an input filter.
|
|
|
|
POLICY_FLAG_FILTERED = 0x04000000,
|
|
|
|
|
|
|
|
// Disables automatic key repeating behavior.
|
|
|
|
POLICY_FLAG_DISABLE_KEY_REPEAT = 0x08000000,
|
|
|
|
|
2010-06-15 08:31:58 +00:00
|
|
|
/* These flags are set by the input reader policy as it intercepts each event. */
|
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-23 01:58:52 +00:00
|
|
|
|
|
|
|
// Indicates that the screen was off when the event was received and the event
|
|
|
|
// should wake the device.
|
|
|
|
POLICY_FLAG_WOKE_HERE = 0x10000000,
|
|
|
|
|
|
|
|
// Indicates that the screen was dim when the event was received and the event
|
|
|
|
// should brighten the device.
|
|
|
|
POLICY_FLAG_BRIGHT_HERE = 0x20000000,
|
2010-10-09 05:31:17 +00:00
|
|
|
|
|
|
|
// Indicates that the event should be dispatched to applications.
|
|
|
|
// The input event should still be sent to the InputDispatcher so that it can see all
|
|
|
|
// input events received include those that it will not deliver.
|
|
|
|
POLICY_FLAG_PASS_TO_USER = 0x40000000,
|
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-23 01:58:52 +00:00
|
|
|
};
|
|
|
|
|
2011-03-08 23:13:06 +00:00
|
|
|
/*
|
|
|
|
* Button state.
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
// Primary button pressed (left mouse button).
|
|
|
|
BUTTON_STATE_PRIMARY = 1 << 0,
|
|
|
|
};
|
|
|
|
|
2010-06-15 08:31:58 +00:00
|
|
|
/*
|
|
|
|
* Describes the basic configuration of input devices that are present.
|
|
|
|
*/
|
|
|
|
struct InputConfiguration {
|
|
|
|
enum {
|
|
|
|
TOUCHSCREEN_UNDEFINED = 0,
|
|
|
|
TOUCHSCREEN_NOTOUCH = 1,
|
|
|
|
TOUCHSCREEN_STYLUS = 2,
|
|
|
|
TOUCHSCREEN_FINGER = 3
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
KEYBOARD_UNDEFINED = 0,
|
|
|
|
KEYBOARD_NOKEYS = 1,
|
|
|
|
KEYBOARD_QWERTY = 2,
|
|
|
|
KEYBOARD_12KEY = 3
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
NAVIGATION_UNDEFINED = 0,
|
|
|
|
NAVIGATION_NONAV = 1,
|
|
|
|
NAVIGATION_DPAD = 2,
|
|
|
|
NAVIGATION_TRACKBALL = 3,
|
|
|
|
NAVIGATION_WHEEL = 4
|
|
|
|
};
|
|
|
|
|
|
|
|
int32_t touchScreen;
|
|
|
|
int32_t keyboard;
|
|
|
|
int32_t navigation;
|
|
|
|
};
|
|
|
|
|
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-23 01:58:52 +00:00
|
|
|
/*
|
|
|
|
* Pointer coordinate data.
|
|
|
|
*/
|
|
|
|
struct PointerCoords {
|
2011-02-19 09:08:02 +00:00
|
|
|
enum { MAX_AXES = 14 }; // 14 so that sizeof(PointerCoords) == 64
|
2011-02-15 01:03:18 +00:00
|
|
|
|
|
|
|
// Bitfield of axes that are present in this structure.
|
2011-02-19 09:08:02 +00:00
|
|
|
uint64_t bits;
|
2011-02-15 01:03:18 +00:00
|
|
|
|
|
|
|
// Values of axes that are stored in this structure packed in order by axis id
|
|
|
|
// for each axis that is present in the structure according to 'bits'.
|
|
|
|
float values[MAX_AXES];
|
|
|
|
|
|
|
|
inline void clear() {
|
|
|
|
bits = 0;
|
|
|
|
}
|
|
|
|
|
2011-02-19 09:08:02 +00:00
|
|
|
float getAxisValue(int32_t axis) const;
|
|
|
|
status_t setAxisValue(int32_t axis, float value);
|
|
|
|
float* editAxisValue(int32_t axis);
|
2011-02-15 01:03:18 +00:00
|
|
|
|
|
|
|
#ifdef HAVE_ANDROID_OS
|
|
|
|
status_t readFromParcel(Parcel* parcel);
|
|
|
|
status_t writeToParcel(Parcel* parcel) const;
|
|
|
|
#endif
|
|
|
|
|
2011-03-10 01:39:48 +00:00
|
|
|
bool operator==(const PointerCoords& other) const;
|
|
|
|
inline bool operator!=(const PointerCoords& other) const {
|
|
|
|
return !(*this == other);
|
|
|
|
}
|
|
|
|
|
|
|
|
void copyFrom(const PointerCoords& other);
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
private:
|
|
|
|
void tooManyAxes(int axis);
|
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-23 01:58:52 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Input events.
|
|
|
|
*/
|
2010-06-28 22:27:30 +00:00
|
|
|
class InputEvent : public AInputEvent {
|
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-23 01:58:52 +00:00
|
|
|
public:
|
|
|
|
virtual ~InputEvent() { }
|
|
|
|
|
|
|
|
virtual int32_t getType() const = 0;
|
|
|
|
|
|
|
|
inline int32_t getDeviceId() const { return mDeviceId; }
|
|
|
|
|
2010-07-15 01:48:53 +00:00
|
|
|
inline int32_t getSource() const { return mSource; }
|
2011-02-15 01:03:18 +00:00
|
|
|
|
|
|
|
inline void setSource(int32_t source) { mSource = 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-23 01:58:52 +00:00
|
|
|
protected:
|
2010-07-15 01:48:53 +00:00
|
|
|
void initialize(int32_t deviceId, int32_t source);
|
2010-07-16 00:44:53 +00:00
|
|
|
void initialize(const InputEvent& from);
|
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-23 01:58:52 +00:00
|
|
|
|
|
|
|
int32_t mDeviceId;
|
2010-07-15 01:48:53 +00:00
|
|
|
int32_t mSource;
|
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-23 01:58:52 +00:00
|
|
|
};
|
|
|
|
|
2010-06-16 08:53:36 +00:00
|
|
|
/*
|
|
|
|
* Key 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-23 01:58:52 +00:00
|
|
|
class KeyEvent : public InputEvent {
|
|
|
|
public:
|
|
|
|
virtual ~KeyEvent() { }
|
|
|
|
|
2010-07-15 01:48:53 +00:00
|
|
|
virtual int32_t getType() const { return AINPUT_EVENT_TYPE_KEY; }
|
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-23 01:58:52 +00:00
|
|
|
|
|
|
|
inline int32_t getAction() const { return mAction; }
|
|
|
|
|
|
|
|
inline int32_t getFlags() const { return mFlags; }
|
|
|
|
|
|
|
|
inline int32_t getKeyCode() const { return mKeyCode; }
|
|
|
|
|
|
|
|
inline int32_t getScanCode() const { return mScanCode; }
|
|
|
|
|
|
|
|
inline int32_t getMetaState() const { return mMetaState; }
|
|
|
|
|
|
|
|
inline int32_t getRepeatCount() const { return mRepeatCount; }
|
|
|
|
|
|
|
|
inline nsecs_t getDownTime() const { return mDownTime; }
|
|
|
|
|
|
|
|
inline nsecs_t getEventTime() const { return mEventTime; }
|
|
|
|
|
2010-06-30 02:20:40 +00:00
|
|
|
// Return true if this event may have a default action implementation.
|
|
|
|
static bool hasDefaultAction(int32_t keyCode);
|
|
|
|
bool hasDefaultAction() const;
|
|
|
|
|
|
|
|
// Return true if this event represents a system key.
|
|
|
|
static bool isSystemKey(int32_t keyCode);
|
|
|
|
bool isSystemKey() 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-23 01:58:52 +00:00
|
|
|
void initialize(
|
|
|
|
int32_t deviceId,
|
2010-07-15 01:48:53 +00:00
|
|
|
int32_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-23 01:58:52 +00:00
|
|
|
int32_t action,
|
|
|
|
int32_t flags,
|
|
|
|
int32_t keyCode,
|
|
|
|
int32_t scanCode,
|
|
|
|
int32_t metaState,
|
|
|
|
int32_t repeatCount,
|
|
|
|
nsecs_t downTime,
|
|
|
|
nsecs_t eventTime);
|
2010-07-16 00:44:53 +00:00
|
|
|
void initialize(const KeyEvent& from);
|
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-23 01:58:52 +00:00
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
protected:
|
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-23 01:58:52 +00:00
|
|
|
int32_t mAction;
|
|
|
|
int32_t mFlags;
|
|
|
|
int32_t mKeyCode;
|
|
|
|
int32_t mScanCode;
|
|
|
|
int32_t mMetaState;
|
|
|
|
int32_t mRepeatCount;
|
|
|
|
nsecs_t mDownTime;
|
|
|
|
nsecs_t mEventTime;
|
|
|
|
};
|
|
|
|
|
2010-06-16 08:53:36 +00:00
|
|
|
/*
|
|
|
|
* Motion 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-23 01:58:52 +00:00
|
|
|
class MotionEvent : public InputEvent {
|
|
|
|
public:
|
|
|
|
virtual ~MotionEvent() { }
|
|
|
|
|
2010-07-15 01:48:53 +00:00
|
|
|
virtual int32_t getType() const { return AINPUT_EVENT_TYPE_MOTION; }
|
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-23 01:58:52 +00:00
|
|
|
|
|
|
|
inline int32_t getAction() const { return mAction; }
|
|
|
|
|
2011-03-15 02:39:54 +00:00
|
|
|
inline int32_t getActionMasked() const { return mAction & AMOTION_EVENT_ACTION_MASK; }
|
|
|
|
|
|
|
|
inline int32_t getActionIndex() const {
|
|
|
|
return (mAction & AMOTION_EVENT_ACTION_POINTER_INDEX_MASK)
|
|
|
|
>> AMOTION_EVENT_ACTION_POINTER_INDEX_SHIFT;
|
|
|
|
}
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
inline void setAction(int32_t action) { mAction = action; }
|
|
|
|
|
2010-09-02 00:01:00 +00:00
|
|
|
inline int32_t getFlags() const { return mFlags; }
|
|
|
|
|
2011-03-01 02:27:14 +00:00
|
|
|
inline void setFlags(int32_t flags) { mFlags = 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-23 01:58:52 +00:00
|
|
|
inline int32_t getEdgeFlags() const { return mEdgeFlags; }
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
inline void setEdgeFlags(int32_t edgeFlags) { mEdgeFlags = edgeFlags; }
|
|
|
|
|
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-23 01:58:52 +00:00
|
|
|
inline int32_t getMetaState() const { return mMetaState; }
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
inline void setMetaState(int32_t metaState) { mMetaState = metaState; }
|
|
|
|
|
2010-06-16 08:53:36 +00:00
|
|
|
inline float getXOffset() const { return mXOffset; }
|
|
|
|
|
|
|
|
inline float getYOffset() const { return mYOffset; }
|
|
|
|
|
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-23 01:58:52 +00:00
|
|
|
inline float getXPrecision() const { return mXPrecision; }
|
|
|
|
|
|
|
|
inline float getYPrecision() const { return mYPrecision; }
|
|
|
|
|
|
|
|
inline nsecs_t getDownTime() const { return mDownTime; }
|
|
|
|
|
|
|
|
inline size_t getPointerCount() const { return mPointerIds.size(); }
|
|
|
|
|
|
|
|
inline int32_t getPointerId(size_t pointerIndex) const { return mPointerIds[pointerIndex]; }
|
|
|
|
|
|
|
|
inline nsecs_t getEventTime() const { return mSampleEventTimes[getHistorySize()]; }
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
const PointerCoords* getRawPointerCoords(size_t pointerIndex) const;
|
|
|
|
|
|
|
|
float getRawAxisValue(int32_t axis, size_t pointerIndex) const;
|
|
|
|
|
2010-06-16 08:53:36 +00:00
|
|
|
inline float getRawX(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getRawAxisValue(AMOTION_EVENT_AXIS_X, pointerIndex);
|
2010-06-16 08:53:36 +00: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-23 01:58:52 +00:00
|
|
|
|
2010-06-16 08:53:36 +00:00
|
|
|
inline float getRawY(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getRawAxisValue(AMOTION_EVENT_AXIS_Y, pointerIndex);
|
2010-06-16 08:53:36 +00: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-23 01:58:52 +00:00
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
float getAxisValue(int32_t axis, size_t pointerIndex) 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-23 01:58:52 +00:00
|
|
|
inline float getX(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getAxisValue(AMOTION_EVENT_AXIS_X, pointerIndex);
|
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-23 01:58:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getY(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getAxisValue(AMOTION_EVENT_AXIS_Y, pointerIndex);
|
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-23 01:58:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getPressure(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getAxisValue(AMOTION_EVENT_AXIS_PRESSURE, pointerIndex);
|
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-23 01:58:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getSize(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getAxisValue(AMOTION_EVENT_AXIS_SIZE, pointerIndex);
|
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-23 01:58:52 +00:00
|
|
|
}
|
|
|
|
|
2010-07-15 01:48:53 +00:00
|
|
|
inline float getTouchMajor(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getAxisValue(AMOTION_EVENT_AXIS_TOUCH_MAJOR, pointerIndex);
|
2010-07-15 01:48:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getTouchMinor(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getAxisValue(AMOTION_EVENT_AXIS_TOUCH_MINOR, pointerIndex);
|
2010-07-15 01:48:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getToolMajor(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getAxisValue(AMOTION_EVENT_AXIS_TOOL_MAJOR, pointerIndex);
|
2010-07-15 01:48:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getToolMinor(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getAxisValue(AMOTION_EVENT_AXIS_TOOL_MINOR, pointerIndex);
|
2010-07-15 01:48:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getOrientation(size_t pointerIndex) const {
|
2011-02-17 21:01:34 +00:00
|
|
|
return getAxisValue(AMOTION_EVENT_AXIS_ORIENTATION, pointerIndex);
|
2010-07-15 01:48:53 +00: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-23 01:58:52 +00:00
|
|
|
inline size_t getHistorySize() const { return mSampleEventTimes.size() - 1; }
|
|
|
|
|
|
|
|
inline nsecs_t getHistoricalEventTime(size_t historicalIndex) const {
|
|
|
|
return mSampleEventTimes[historicalIndex];
|
|
|
|
}
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
const PointerCoords* getHistoricalRawPointerCoords(
|
|
|
|
size_t pointerIndex, size_t historicalIndex) const;
|
|
|
|
|
|
|
|
float getHistoricalRawAxisValue(int32_t axis, size_t pointerIndex,
|
|
|
|
size_t historicalIndex) const;
|
|
|
|
|
2010-06-16 08:53:36 +00:00
|
|
|
inline float getHistoricalRawX(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalRawAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_X, pointerIndex, historicalIndex);
|
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-23 01:58:52 +00:00
|
|
|
}
|
|
|
|
|
2010-06-16 08:53:36 +00:00
|
|
|
inline float getHistoricalRawY(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalRawAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_Y, pointerIndex, historicalIndex);
|
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-23 01:58:52 +00:00
|
|
|
}
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
float getHistoricalAxisValue(int32_t axis, size_t pointerIndex, size_t historicalIndex) const;
|
|
|
|
|
2010-06-16 08:53:36 +00:00
|
|
|
inline float getHistoricalX(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_X, pointerIndex, historicalIndex);
|
2010-06-16 08:53:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getHistoricalY(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_Y, pointerIndex, historicalIndex);
|
2010-06-16 08:53:36 +00: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-23 01:58:52 +00:00
|
|
|
inline float getHistoricalPressure(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_PRESSURE, pointerIndex, historicalIndex);
|
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-23 01:58:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getHistoricalSize(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_SIZE, pointerIndex, historicalIndex);
|
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-23 01:58:52 +00:00
|
|
|
}
|
|
|
|
|
2010-07-15 01:48:53 +00:00
|
|
|
inline float getHistoricalTouchMajor(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_TOUCH_MAJOR, pointerIndex, historicalIndex);
|
2010-07-15 01:48:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getHistoricalTouchMinor(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_TOUCH_MINOR, pointerIndex, historicalIndex);
|
2010-07-15 01:48:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getHistoricalToolMajor(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_TOOL_MAJOR, pointerIndex, historicalIndex);
|
2010-07-15 01:48:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getHistoricalToolMinor(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_TOOL_MINOR, pointerIndex, historicalIndex);
|
2010-07-15 01:48:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline float getHistoricalOrientation(size_t pointerIndex, size_t historicalIndex) const {
|
2011-02-15 01:03:18 +00:00
|
|
|
return getHistoricalAxisValue(
|
2011-02-17 21:01:34 +00:00
|
|
|
AMOTION_EVENT_AXIS_ORIENTATION, pointerIndex, historicalIndex);
|
2010-07-15 01:48:53 +00:00
|
|
|
}
|
|
|
|
|
2011-03-15 02:39:54 +00:00
|
|
|
ssize_t findPointerIndex(int32_t pointerId) 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-23 01:58:52 +00:00
|
|
|
void initialize(
|
|
|
|
int32_t deviceId,
|
2010-07-15 01:48:53 +00:00
|
|
|
int32_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-23 01:58:52 +00:00
|
|
|
int32_t action,
|
2010-09-02 00:01:00 +00: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-23 01:58:52 +00:00
|
|
|
int32_t edgeFlags,
|
|
|
|
int32_t metaState,
|
2010-06-16 08:53:36 +00:00
|
|
|
float xOffset,
|
|
|
|
float yOffset,
|
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-23 01:58:52 +00:00
|
|
|
float xPrecision,
|
|
|
|
float yPrecision,
|
|
|
|
nsecs_t downTime,
|
|
|
|
nsecs_t eventTime,
|
|
|
|
size_t pointerCount,
|
|
|
|
const int32_t* pointerIds,
|
|
|
|
const PointerCoords* pointerCoords);
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
void copyFrom(const MotionEvent* other, bool keepHistory);
|
|
|
|
|
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-23 01:58:52 +00:00
|
|
|
void addSample(
|
|
|
|
nsecs_t eventTime,
|
|
|
|
const PointerCoords* pointerCoords);
|
|
|
|
|
|
|
|
void offsetLocation(float xOffset, float yOffset);
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
void scale(float scaleFactor);
|
|
|
|
|
|
|
|
#ifdef HAVE_ANDROID_OS
|
|
|
|
void transform(const SkMatrix* matrix);
|
|
|
|
|
|
|
|
status_t readFromParcel(Parcel* parcel);
|
|
|
|
status_t writeToParcel(Parcel* parcel) const;
|
|
|
|
#endif
|
|
|
|
|
2011-03-03 03:23:13 +00:00
|
|
|
static bool isTouchEvent(int32_t source, int32_t action);
|
|
|
|
inline bool isTouchEvent() const {
|
|
|
|
return isTouchEvent(mSource, mAction);
|
|
|
|
}
|
|
|
|
|
2010-06-16 08:53:36 +00:00
|
|
|
// Low-level accessors.
|
|
|
|
inline const int32_t* getPointerIds() const { return mPointerIds.array(); }
|
|
|
|
inline const nsecs_t* getSampleEventTimes() const { return mSampleEventTimes.array(); }
|
|
|
|
inline const PointerCoords* getSamplePointerCoords() const {
|
|
|
|
return mSamplePointerCoords.array();
|
|
|
|
}
|
|
|
|
|
2011-02-15 01:03:18 +00:00
|
|
|
protected:
|
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-23 01:58:52 +00:00
|
|
|
int32_t mAction;
|
2010-09-02 00:01:00 +00:00
|
|
|
int32_t mFlags;
|
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-23 01:58:52 +00:00
|
|
|
int32_t mEdgeFlags;
|
|
|
|
int32_t mMetaState;
|
2010-06-16 08:53:36 +00:00
|
|
|
float mXOffset;
|
|
|
|
float mYOffset;
|
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-23 01:58:52 +00:00
|
|
|
float mXPrecision;
|
|
|
|
float mYPrecision;
|
|
|
|
nsecs_t mDownTime;
|
|
|
|
Vector<int32_t> mPointerIds;
|
|
|
|
Vector<nsecs_t> mSampleEventTimes;
|
|
|
|
Vector<PointerCoords> mSamplePointerCoords;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Input event factory.
|
|
|
|
*/
|
|
|
|
class InputEventFactoryInterface {
|
|
|
|
protected:
|
|
|
|
virtual ~InputEventFactoryInterface() { }
|
|
|
|
|
|
|
|
public:
|
|
|
|
InputEventFactoryInterface() { }
|
|
|
|
|
|
|
|
virtual KeyEvent* createKeyEvent() = 0;
|
|
|
|
virtual MotionEvent* createMotionEvent() = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A simple input event factory implementation that uses a single preallocated instance
|
|
|
|
* of each type of input event that are reused for each request.
|
|
|
|
*/
|
|
|
|
class PreallocatedInputEventFactory : public InputEventFactoryInterface {
|
|
|
|
public:
|
|
|
|
PreallocatedInputEventFactory() { }
|
|
|
|
virtual ~PreallocatedInputEventFactory() { }
|
|
|
|
|
|
|
|
virtual KeyEvent* createKeyEvent() { return & mKeyEvent; }
|
|
|
|
virtual MotionEvent* createMotionEvent() { return & mMotionEvent; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
KeyEvent mKeyEvent;
|
|
|
|
MotionEvent mMotionEvent;
|
|
|
|
};
|
|
|
|
|
2011-03-10 01:39:48 +00:00
|
|
|
/*
|
2011-03-15 02:39:54 +00:00
|
|
|
* Calculates the velocity of pointer movements over time.
|
2011-03-10 01:39:48 +00:00
|
|
|
*/
|
|
|
|
class VelocityTracker {
|
|
|
|
public:
|
|
|
|
struct Position {
|
|
|
|
float x, y;
|
|
|
|
};
|
|
|
|
|
|
|
|
VelocityTracker();
|
|
|
|
|
|
|
|
// Resets the velocity tracker state.
|
|
|
|
void clear();
|
|
|
|
|
2011-03-15 02:39:54 +00:00
|
|
|
// Resets the velocity tracker state for specific pointers.
|
|
|
|
// Call this method when some pointers have changed and may be reusing
|
|
|
|
// an id that was assigned to a different pointer earlier.
|
|
|
|
void clearPointers(BitSet32 idBits);
|
|
|
|
|
2011-03-10 01:39:48 +00:00
|
|
|
// Adds movement information for a set of pointers.
|
|
|
|
// The idBits bitfield specifies the pointer ids of the pointers whose positions
|
|
|
|
// are included in the movement.
|
|
|
|
// The positions array contains position information for each pointer in order by
|
|
|
|
// increasing id. Its size should be equal to the number of one bits in idBits.
|
|
|
|
void addMovement(nsecs_t eventTime, BitSet32 idBits, const Position* positions);
|
|
|
|
|
2011-03-15 02:39:54 +00:00
|
|
|
// Adds movement information for all pointers in a MotionEvent, including historical samples.
|
|
|
|
void addMovement(const MotionEvent* event);
|
|
|
|
|
2011-03-10 01:39:48 +00:00
|
|
|
// Gets the velocity of the specified pointer id in position units per second.
|
|
|
|
// Returns false and sets the velocity components to zero if there is no movement
|
|
|
|
// information for the pointer.
|
|
|
|
bool getVelocity(uint32_t id, float* outVx, float* outVy) const;
|
|
|
|
|
2011-03-15 02:39:54 +00:00
|
|
|
// Gets the active pointer id, or -1 if none.
|
|
|
|
inline int32_t getActivePointerId() const { return mActivePointerId; }
|
|
|
|
|
|
|
|
// Gets a bitset containing all pointer ids from the most recent movement.
|
|
|
|
inline BitSet32 getCurrentPointerIdBits() const { return mMovements[mIndex].idBits; }
|
|
|
|
|
2011-03-10 01:39:48 +00:00
|
|
|
private:
|
|
|
|
// Number of samples to keep.
|
|
|
|
static const uint32_t HISTORY_SIZE = 10;
|
|
|
|
|
|
|
|
// Oldest sample to consider when calculating the velocity.
|
|
|
|
static const nsecs_t MAX_AGE = 200 * 1000000; // 200 ms
|
|
|
|
|
2011-04-13 05:39:53 +00:00
|
|
|
// When the total duration of the window of samples being averaged is less
|
|
|
|
// than the window size, the resulting velocity is scaled to reduce the impact
|
|
|
|
// of overestimation in short traces.
|
|
|
|
static const nsecs_t MIN_WINDOW = 100 * 1000000; // 100 ms
|
|
|
|
|
2011-03-10 01:39:48 +00:00
|
|
|
// The minimum duration between samples when estimating velocity.
|
2011-03-15 02:39:54 +00:00
|
|
|
static const nsecs_t MIN_DURATION = 10 * 1000000; // 10 ms
|
2011-03-10 01:39:48 +00:00
|
|
|
|
|
|
|
struct Movement {
|
|
|
|
nsecs_t eventTime;
|
|
|
|
BitSet32 idBits;
|
|
|
|
Position positions[MAX_POINTERS];
|
|
|
|
};
|
|
|
|
|
|
|
|
uint32_t mIndex;
|
|
|
|
Movement mMovements[HISTORY_SIZE];
|
2011-03-15 02:39:54 +00:00
|
|
|
int32_t mActivePointerId;
|
2011-03-10 01:39:48 +00:00
|
|
|
};
|
|
|
|
|
2010-07-24 04:28:06 +00:00
|
|
|
/*
|
|
|
|
* Describes the characteristics and capabilities of an input device.
|
|
|
|
*/
|
|
|
|
class InputDeviceInfo {
|
|
|
|
public:
|
|
|
|
InputDeviceInfo();
|
|
|
|
InputDeviceInfo(const InputDeviceInfo& other);
|
|
|
|
~InputDeviceInfo();
|
|
|
|
|
|
|
|
struct MotionRange {
|
2011-03-08 23:13:06 +00:00
|
|
|
int32_t axis;
|
|
|
|
uint32_t source;
|
2010-07-24 04:28:06 +00:00
|
|
|
float min;
|
|
|
|
float max;
|
|
|
|
float flat;
|
|
|
|
float fuzz;
|
|
|
|
};
|
|
|
|
|
|
|
|
void initialize(int32_t id, const String8& name);
|
|
|
|
|
|
|
|
inline int32_t getId() const { return mId; }
|
|
|
|
inline const String8 getName() const { return mName; }
|
|
|
|
inline uint32_t getSources() const { return mSources; }
|
|
|
|
|
2011-03-08 23:13:06 +00:00
|
|
|
const MotionRange* getMotionRange(int32_t axis, uint32_t source) const;
|
2010-07-24 04:28:06 +00:00
|
|
|
|
|
|
|
void addSource(uint32_t source);
|
2011-03-08 23:13:06 +00:00
|
|
|
void addMotionRange(int32_t axis, uint32_t source,
|
|
|
|
float min, float max, float flat, float fuzz);
|
|
|
|
void addMotionRange(const MotionRange& range);
|
2010-07-24 04:28:06 +00:00
|
|
|
|
|
|
|
inline void setKeyboardType(int32_t keyboardType) { mKeyboardType = keyboardType; }
|
|
|
|
inline int32_t getKeyboardType() const { return mKeyboardType; }
|
|
|
|
|
2011-03-08 23:13:06 +00:00
|
|
|
inline const Vector<MotionRange>& getMotionRanges() const {
|
2010-08-30 10:02:23 +00:00
|
|
|
return mMotionRanges;
|
|
|
|
}
|
|
|
|
|
2010-07-24 04:28:06 +00:00
|
|
|
private:
|
|
|
|
int32_t mId;
|
|
|
|
String8 mName;
|
|
|
|
uint32_t mSources;
|
|
|
|
int32_t mKeyboardType;
|
|
|
|
|
2011-03-08 23:13:06 +00:00
|
|
|
Vector<MotionRange> mMotionRanges;
|
2010-07-24 04:28:06 +00:00
|
|
|
};
|
|
|
|
|
2010-12-02 21:50:46 +00:00
|
|
|
/*
|
|
|
|
* Identifies a device.
|
|
|
|
*/
|
|
|
|
struct InputDeviceIdentifier {
|
|
|
|
inline InputDeviceIdentifier() :
|
|
|
|
bus(0), vendor(0), product(0), version(0) {
|
|
|
|
}
|
|
|
|
|
|
|
|
String8 name;
|
|
|
|
String8 location;
|
|
|
|
String8 uniqueId;
|
|
|
|
uint16_t bus;
|
|
|
|
uint16_t vendor;
|
|
|
|
uint16_t product;
|
|
|
|
uint16_t version;
|
|
|
|
};
|
|
|
|
|
2010-11-30 01:37:49 +00:00
|
|
|
/* Types of input device configuration files. */
|
|
|
|
enum InputDeviceConfigurationFileType {
|
|
|
|
INPUT_DEVICE_CONFIGURATION_FILE_TYPE_CONFIGURATION = 0, /* .idc file */
|
|
|
|
INPUT_DEVICE_CONFIGURATION_FILE_TYPE_KEY_LAYOUT = 1, /* .kl file */
|
|
|
|
INPUT_DEVICE_CONFIGURATION_FILE_TYPE_KEY_CHARACTER_MAP = 2, /* .kcm file */
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2010-12-02 21:50:46 +00:00
|
|
|
* Gets the path of an input device configuration file, if one is available.
|
|
|
|
* Considers both system provided and user installed configuration files.
|
|
|
|
*
|
|
|
|
* The device identifier is used to construct several default configuration file
|
|
|
|
* names to try based on the device name, vendor, product, and version.
|
|
|
|
*
|
|
|
|
* Returns an empty string if not found.
|
|
|
|
*/
|
|
|
|
extern String8 getInputDeviceConfigurationFilePathByDeviceIdentifier(
|
|
|
|
const InputDeviceIdentifier& deviceIdentifier,
|
|
|
|
InputDeviceConfigurationFileType type);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Gets the path of an input device configuration file, if one is available.
|
2010-11-19 04:53:46 +00:00
|
|
|
* Considers both system provided and user installed configuration files.
|
2010-11-30 01:37:49 +00:00
|
|
|
*
|
2010-12-02 21:50:46 +00:00
|
|
|
* The name is case-sensitive and is used to construct the filename to resolve.
|
|
|
|
* All characters except 'a'-'z', 'A'-'Z', '0'-'9', '-', and '_' are replaced by underscores.
|
|
|
|
*
|
2010-11-30 01:37:49 +00:00
|
|
|
* Returns an empty string if not found.
|
|
|
|
*/
|
2010-12-02 21:50:46 +00:00
|
|
|
extern String8 getInputDeviceConfigurationFilePathByName(
|
2010-11-30 01:37:49 +00:00
|
|
|
const String8& name, InputDeviceConfigurationFileType type);
|
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-23 01:58:52 +00:00
|
|
|
|
|
|
|
} // namespace android
|
|
|
|
|
|
|
|
#endif // _UI_INPUT_H
|