2009-03-04 03:31:44 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2005 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 _RUNTIME_EVENT_HUB_H
|
|
|
|
#define _RUNTIME_EVENT_HUB_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 <android/input.h>
|
2009-03-04 03:31:44 +00:00
|
|
|
#include <utils/String8.h>
|
|
|
|
#include <utils/threads.h>
|
2009-06-01 02:13:00 +00:00
|
|
|
#include <utils/Log.h>
|
|
|
|
#include <utils/threads.h>
|
|
|
|
#include <utils/List.h>
|
|
|
|
#include <utils/Errors.h>
|
2009-03-04 03:31:44 +00:00
|
|
|
|
|
|
|
#include <linux/input.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
|
|
|
/* These constants are not defined in linux/input.h but they are part of the multitouch
|
|
|
|
* input protocol. */
|
|
|
|
|
|
|
|
#define ABS_MT_TOUCH_MAJOR 0x30 /* Major axis of touching ellipse */
|
|
|
|
#define ABS_MT_TOUCH_MINOR 0x31 /* Minor axis (omit if circular) */
|
|
|
|
#define ABS_MT_WIDTH_MAJOR 0x32 /* Major axis of approaching ellipse */
|
|
|
|
#define ABS_MT_WIDTH_MINOR 0x33 /* Minor axis (omit if circular) */
|
|
|
|
#define ABS_MT_ORIENTATION 0x34 /* Ellipse orientation */
|
|
|
|
#define ABS_MT_POSITION_X 0x35 /* Center X ellipse position */
|
|
|
|
#define ABS_MT_POSITION_Y 0x36 /* Center Y ellipse position */
|
|
|
|
#define ABS_MT_TOOL_TYPE 0x37 /* Type of touching device (finger, pen, ...) */
|
|
|
|
#define ABS_MT_BLOB_ID 0x38 /* Group a set of packets as a blob */
|
|
|
|
#define ABS_MT_TRACKING_ID 0x39 /* Unique ID of initiated contact */
|
|
|
|
#define ABS_MT_PRESSURE 0x3a /* Pressure on contact area */
|
|
|
|
|
|
|
|
#define MT_TOOL_FINGER 0 /* Identifies a finger */
|
|
|
|
#define MT_TOOL_PEN 1 /* Identifies a pen */
|
|
|
|
|
|
|
|
#define SYN_MT_REPORT 2
|
|
|
|
|
|
|
|
/* Convenience constants. */
|
|
|
|
|
|
|
|
#define BTN_FIRST 0x100 // first button scancode
|
|
|
|
#define BTN_LAST 0x15f // last button scancode
|
|
|
|
|
2009-03-04 03:31:44 +00:00
|
|
|
struct pollfd;
|
|
|
|
|
|
|
|
namespace android {
|
|
|
|
|
|
|
|
class KeyLayoutMap;
|
|
|
|
|
2010-07-24 04:28:06 +00:00
|
|
|
/*
|
|
|
|
* A raw event as retrieved from the EventHub.
|
|
|
|
*/
|
|
|
|
struct RawEvent {
|
|
|
|
nsecs_t when;
|
|
|
|
int32_t deviceId;
|
|
|
|
int32_t type;
|
|
|
|
int32_t scanCode;
|
|
|
|
int32_t keyCode;
|
|
|
|
int32_t value;
|
|
|
|
uint32_t flags;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Describes an absolute axis. */
|
|
|
|
struct RawAbsoluteAxisInfo {
|
|
|
|
bool valid; // true if the information is valid, false otherwise
|
|
|
|
|
|
|
|
int32_t minValue; // minimum value
|
|
|
|
int32_t maxValue; // maximum value
|
|
|
|
int32_t flat; // center flat position, eg. flat == 8 means center is between -8 and 8
|
|
|
|
int32_t fuzz; // error tolerance, eg. fuzz == 4 means value is +/- 4 due to noise
|
|
|
|
|
|
|
|
inline int32_t getRange() { return maxValue - minValue; }
|
|
|
|
};
|
|
|
|
|
2010-07-15 01:48:53 +00:00
|
|
|
/*
|
|
|
|
* Input device classes.
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
/* The input device is a keyboard. */
|
|
|
|
INPUT_DEVICE_CLASS_KEYBOARD = 0x00000001,
|
|
|
|
|
|
|
|
/* The input device is an alpha-numeric keyboard (not just a dial pad). */
|
|
|
|
INPUT_DEVICE_CLASS_ALPHAKEY = 0x00000002,
|
|
|
|
|
|
|
|
/* The input device is a touchscreen (either single-touch or multi-touch). */
|
|
|
|
INPUT_DEVICE_CLASS_TOUCHSCREEN = 0x00000004,
|
|
|
|
|
|
|
|
/* The input device is a trackball. */
|
|
|
|
INPUT_DEVICE_CLASS_TRACKBALL = 0x00000008,
|
|
|
|
|
|
|
|
/* The input device is a multi-touch touchscreen. */
|
|
|
|
INPUT_DEVICE_CLASS_TOUCHSCREEN_MT= 0x00000010,
|
|
|
|
|
|
|
|
/* The input device is a directional pad. */
|
|
|
|
INPUT_DEVICE_CLASS_DPAD = 0x00000020,
|
|
|
|
|
|
|
|
/* The input device is a gamepad (implies keyboard). */
|
2010-07-24 04:28:06 +00:00
|
|
|
INPUT_DEVICE_CLASS_GAMEPAD = 0x00000040,
|
|
|
|
|
|
|
|
/* The input device has switches. */
|
|
|
|
INPUT_DEVICE_CLASS_SWITCH = 0x00000080,
|
2010-07-15 01:48:53 +00:00
|
|
|
};
|
|
|
|
|
2009-03-04 03:31:44 +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
|
|
|
* Grand Central Station for events.
|
2009-03-04 03:31:44 +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
|
|
|
* The event hub aggregates input events received across all known input
|
|
|
|
* devices on the system, including devices that may be emulated by the simulator
|
|
|
|
* environment. In addition, the event hub generates fake input events to indicate
|
|
|
|
* when devices are added or removed.
|
|
|
|
*
|
|
|
|
* The event hub provies a stream of input events (via the getEvent function).
|
|
|
|
* It also supports querying the current actual state of input devices such as identifying
|
|
|
|
* which keys are currently down. Finally, the event hub keeps track of the capabilities of
|
|
|
|
* individual input devices, such as their class and the set of key codes that they support.
|
2009-03-04 03:31:44 +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
|
|
|
class EventHubInterface : public virtual RefBase {
|
|
|
|
protected:
|
|
|
|
EventHubInterface() { }
|
|
|
|
virtual ~EventHubInterface() { }
|
|
|
|
|
|
|
|
public:
|
|
|
|
// Synthetic raw event type codes produced when devices are added or removed.
|
|
|
|
enum {
|
|
|
|
DEVICE_ADDED = 0x10000000,
|
|
|
|
DEVICE_REMOVED = 0x20000000
|
|
|
|
};
|
|
|
|
|
|
|
|
virtual uint32_t getDeviceClasses(int32_t deviceId) const = 0;
|
|
|
|
|
|
|
|
virtual String8 getDeviceName(int32_t deviceId) const = 0;
|
|
|
|
|
2010-07-24 04:28:06 +00:00
|
|
|
virtual status_t getAbsoluteAxisInfo(int32_t deviceId, int axis,
|
|
|
|
RawAbsoluteAxisInfo* outAxisInfo) const = 0;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-23 01:58:52 +00:00
|
|
|
|
|
|
|
virtual status_t scancodeToKeycode(int32_t deviceId, int scancode,
|
|
|
|
int32_t* outKeycode, uint32_t* outFlags) const = 0;
|
|
|
|
|
|
|
|
// exclude a particular device from opening
|
|
|
|
// this can be used to ignore input devices for sensors
|
|
|
|
virtual void addExcludedDevice(const char* deviceName) = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait for the next event to become available and return it.
|
|
|
|
* After returning, the EventHub holds onto a wake lock until the next call to getEvent.
|
|
|
|
* This ensures that the device will not go to sleep while the event is being processed.
|
|
|
|
* If the device needs to remain awake longer than that, then the caller is responsible
|
|
|
|
* for taking care of it (say, by poking the power manager user activity timer).
|
|
|
|
*/
|
2010-07-24 04:28:06 +00:00
|
|
|
virtual bool getEvent(RawEvent* outEvent) = 0;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-23 01:58:52 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Query current input state.
|
|
|
|
*/
|
2010-07-24 04:28:06 +00:00
|
|
|
virtual int32_t getScanCodeState(int32_t deviceId, int32_t scanCode) const = 0;
|
|
|
|
virtual int32_t getKeyCodeState(int32_t deviceId, int32_t keyCode) const = 0;
|
|
|
|
virtual int32_t getSwitchState(int32_t deviceId, int32_t sw) const = 0;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-23 01:58:52 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Examine key input devices for specific framework keycode support
|
|
|
|
*/
|
2010-07-24 04:28:06 +00:00
|
|
|
virtual bool markSupportedKeyCodes(int32_t deviceId, size_t numCodes, const int32_t* keyCodes,
|
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
|
|
|
uint8_t* outFlags) const = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
class EventHub : public EventHubInterface
|
2009-03-04 03:31:44 +00:00
|
|
|
{
|
|
|
|
public:
|
|
|
|
EventHub();
|
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
|
|
|
|
2009-03-04 03:31:44 +00:00
|
|
|
status_t errorCheck() 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
|
|
|
|
|
|
|
virtual uint32_t getDeviceClasses(int32_t deviceId) const;
|
2009-03-04 03:31:44 +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
|
|
|
virtual String8 getDeviceName(int32_t deviceId) const;
|
2009-03-04 03:31:44 +00:00
|
|
|
|
2010-07-24 04:28:06 +00:00
|
|
|
virtual status_t getAbsoluteAxisInfo(int32_t deviceId, int axis,
|
|
|
|
RawAbsoluteAxisInfo* outAxisInfo) 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
|
|
|
virtual status_t scancodeToKeycode(int32_t deviceId, int scancode,
|
2009-07-14 19:06:54 +00:00
|
|
|
int32_t* outKeycode, uint32_t* outFlags) const;
|
2009-07-16 15:11:18 +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
|
|
|
virtual void addExcludedDevice(const char* deviceName);
|
2009-07-16 15:11:18 +00:00
|
|
|
|
2010-07-24 04:28:06 +00:00
|
|
|
virtual int32_t getScanCodeState(int32_t deviceId, int32_t scanCode) const;
|
|
|
|
virtual int32_t getKeyCodeState(int32_t deviceId, int32_t keyCode) const;
|
|
|
|
virtual int32_t getSwitchState(int32_t deviceId, int32_t sw) 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
|
|
|
|
2010-07-24 04:28:06 +00:00
|
|
|
virtual bool markSupportedKeyCodes(int32_t deviceId, size_t numCodes,
|
|
|
|
const int32_t* keyCodes, uint8_t* outFlags) const;
|
2009-03-04 03:31:44 +00:00
|
|
|
|
2010-07-24 04:28:06 +00:00
|
|
|
virtual bool getEvent(RawEvent* outEvent);
|
2009-07-16 15:11:18 +00:00
|
|
|
|
2009-03-04 03:31:44 +00:00
|
|
|
protected:
|
|
|
|
virtual ~EventHub();
|
|
|
|
|
|
|
|
private:
|
|
|
|
bool openPlatformInput(void);
|
|
|
|
|
|
|
|
int open_device(const char *device);
|
|
|
|
int close_device(const char *device);
|
|
|
|
int scan_dir(const char *dirname);
|
|
|
|
int read_notify(int nfd);
|
|
|
|
|
|
|
|
status_t mError;
|
|
|
|
|
|
|
|
struct device_t {
|
|
|
|
const int32_t id;
|
|
|
|
const String8 path;
|
|
|
|
String8 name;
|
|
|
|
uint32_t classes;
|
|
|
|
uint8_t* keyBitmask;
|
|
|
|
KeyLayoutMap* layoutMap;
|
|
|
|
String8 keylayoutFilename;
|
|
|
|
device_t* next;
|
|
|
|
|
2009-08-06 21:50:08 +00:00
|
|
|
device_t(int32_t _id, const char* _path, const char* name);
|
2009-03-04 03:31:44 +00:00
|
|
|
~device_t();
|
|
|
|
};
|
|
|
|
|
|
|
|
device_t* getDevice(int32_t deviceId) const;
|
2009-08-04 12:49:43 +00:00
|
|
|
bool hasKeycode(device_t* device, int keycode) const;
|
2009-03-04 03:31:44 +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
|
|
|
int32_t getScanCodeStateLocked(device_t* device, int32_t scanCode) const;
|
|
|
|
int32_t getKeyCodeStateLocked(device_t* device, int32_t keyCode) const;
|
|
|
|
int32_t getSwitchStateLocked(device_t* device, int32_t sw) const;
|
2010-07-24 04:28:06 +00:00
|
|
|
bool markSupportedKeyCodesLocked(device_t* device, size_t numCodes,
|
|
|
|
const int32_t* keyCodes, uint8_t* outFlags) 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
|
|
|
|
2009-03-04 03:31:44 +00:00
|
|
|
// Protect all internal state.
|
|
|
|
mutable Mutex mLock;
|
|
|
|
|
|
|
|
bool mHaveFirstKeyboard;
|
2009-07-14 19:06:54 +00:00
|
|
|
int32_t mFirstKeyboardId; // the API is that the built-in keyboard is id 0, so map it
|
2009-03-04 03:31:44 +00:00
|
|
|
|
|
|
|
struct device_ent {
|
|
|
|
device_t* device;
|
|
|
|
uint32_t seq;
|
|
|
|
};
|
|
|
|
device_ent *mDevicesById;
|
|
|
|
int mNumDevicesById;
|
|
|
|
|
|
|
|
device_t *mOpeningDevices;
|
|
|
|
device_t *mClosingDevices;
|
|
|
|
|
|
|
|
device_t **mDevices;
|
|
|
|
struct pollfd *mFDs;
|
|
|
|
int mFDCount;
|
2009-07-16 15:11:18 +00:00
|
|
|
|
|
|
|
bool mOpened;
|
|
|
|
List<String8> mExcludedDevices;
|
|
|
|
|
2009-03-04 03:31:44 +00:00
|
|
|
// device ids that report particular switches.
|
|
|
|
#ifdef EV_SW
|
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 mSwitches[SW_MAX + 1];
|
2009-03-04 03:31:44 +00:00
|
|
|
#endif
|
2010-08-17 23:48:25 +00:00
|
|
|
|
|
|
|
static const int INPUT_BUFFER_SIZE = 64;
|
|
|
|
struct input_event mInputBufferData[INPUT_BUFFER_SIZE];
|
|
|
|
int32_t mInputBufferIndex;
|
|
|
|
int32_t mInputBufferCount;
|
|
|
|
int32_t mInputDeviceIndex;
|
2009-03-04 03:31:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
}; // namespace android
|
|
|
|
|
|
|
|
#endif // _RUNTIME_EVENT_HUB_H
|