ADHOC/replicant-frameworks_native
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
12c9ce8bc4
replicant-frameworks_native/libs/ui/EventHub.cpp

924 lines
29 KiB
C++
Raw Normal View History

auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
//
// Copyright 2005 The Android Open Source Project
//
// Handle events, like key input and vsync.
//
// The goal is to provide an optimized solution for Linux, not an
// implementation that works well across all platforms. We expect
// events to arrive on file descriptors, so that we can use a select()
// select() call to sleep.
//
// We can't select() on anything but network sockets in Windows, so we
// provide an alternative implementation of waitEvent for that platform.
//
#define LOG_TAG "EventHub"
//#define LOG_NDEBUG 0
#include <ui/EventHub.h>
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
#include <ui/KeycodeLabels.h>
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
#include <hardware_legacy/power.h>
#include <cutils/properties.h>
#include <utils/Log.h>
#include <utils/Timers.h>
get rid of utils.h
2009-06-01 02:13:00 +00:00
#include <utils/threads.h>
#include <utils/Errors.h>
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <memory.h>
#include <errno.h>
#include <assert.h>
#include "KeyLayoutMap.h"
#include <string.h>
#include <stdint.h>
#include <dirent.h>
#ifdef HAVE_INOTIFY
# include <sys/inotify.h>
#endif
#ifdef HAVE_ANDROID_OS
# include <sys/limits.h> /* not part of Linux */
#endif
#include <sys/poll.h>
#include <sys/ioctl.h>
/* this macro is used to tell if "bit" is set in "array"
* it selects a byte from the array, and does a boolean AND
* operation with a byte that only has the relevant bit set.
* eg. to check for the 12th bit, we do (array[1] & 1<<4)
*/
#define test_bit(bit, array) (array[bit/8] & (1<<(bit%8)))
#define ID_MASK 0x0000ffff
#define SEQ_MASK 0x7fff0000
#define SEQ_SHIFT 16
#define id_to_index(id) ((id&ID_MASK)+1)
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
#ifndef ABS_MT_TOUCH_MAJOR
#define ABS_MT_TOUCH_MAJOR 0x30 /* Major axis of touching ellipse */
#endif
#ifndef ABS_MT_POSITION_X
#define ABS_MT_POSITION_X 0x35 /* Center X ellipse position */
#endif
#ifndef ABS_MT_POSITION_Y
#define ABS_MT_POSITION_Y 0x36 /* Center Y ellipse position */
#endif
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
namespace android {
static const char *WAKE_LOCK_ID = "KeyEvents";
static const char *device_path = "/dev/input";
/* return the larger integer */
static inline int max(int v1, int v2)
{
return (v1 > v2) ? v1 : v2;
}
EventHub: pass the name of each input device up to Java Signed-off-by: Iliyan Malchev <malchev@google.com>
2009-08-06 21:50:08 +00:00
EventHub::device_t::device_t(int32_t _id, const char* _path, const char* name)
: id(_id), path(_path), name(name), classes(0)
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
, keyBitmask(NULL), layoutMap(new KeyLayoutMap()), next(NULL) {
}
EventHub::device_t::~device_t() {
delete [] keyBitmask;
delete layoutMap;
}
EventHub::EventHub(void)
: mError(NO_INIT), mHaveFirstKeyboard(false), mFirstKeyboardId(0)
, mDevicesById(0), mNumDevicesById(0)
, mOpeningDevices(0), mClosingDevices(0)
EventHub: Add support for excluding devices from being opened by as a keyboard. This will be used to avoid unnecessarily listening to data from sensors that function as event devices. Signed-off-by: Mike Lockwood <lockwood@android.com>
2009-07-16 15:11:18 +00:00
, mDevices(0), mFDs(0), mFDCount(0), mOpened(false)
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
{
acquire_wake_lock(PARTIAL_WAKE_LOCK, WAKE_LOCK_ID);
#ifdef EV_SW
memset(mSwitches, 0, sizeof(mSwitches));
#endif
}
/*
* Clean up.
*/
EventHub::~EventHub(void)
{
release_wake_lock(WAKE_LOCK_ID);
// we should free stuff here...
}
status_t EventHub::errorCheck() const
{
return mError;
}
String8 EventHub::getDeviceName(int32_t deviceId) const
{
AutoMutex _l(mLock);
device_t* device = getDevice(deviceId);
if (device == NULL) return String8();
return device->name;
}
uint32_t EventHub::getDeviceClasses(int32_t deviceId) const
{
AutoMutex _l(mLock);
device_t* device = getDevice(deviceId);
if (device == NULL) return 0;
return device->classes;
}
int EventHub::getAbsoluteInfo(int32_t deviceId, int axis, int *outMinValue,
int* outMaxValue, int* outFlat, int* outFuzz) const
{
AutoMutex _l(mLock);
device_t* device = getDevice(deviceId);
if (device == NULL) return -1;
struct input_absinfo info;
if(ioctl(mFDs[id_to_index(device->id)].fd, EVIOCGABS(axis), &info)) {
LOGE("Error reading absolute controller %d for device %s fd %d\n",
axis, device->name.string(), mFDs[id_to_index(device->id)].fd);
return -1;
}
*outMinValue = info.minimum;
*outMaxValue = info.maximum;
*outFlat = info.flat;
*outFuzz = info.fuzz;
return 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
int32_t EventHub::getScanCodeState(int32_t deviceId, int32_t deviceClasses,
int32_t scanCode) const {
if (scanCode >= 0 && scanCode <= KEY_MAX) {
AutoMutex _l(mLock);
if (deviceId == -1) {
for (int i = 0; i < mNumDevicesById; i++) {
device_t* device = mDevicesById[i].device;
if (device != NULL && (device->classes & deviceClasses) != 0) {
int32_t result = getScanCodeStateLocked(device, scanCode);
if (result >= KEY_STATE_DOWN) {
return result;
}
}
}
return KEY_STATE_UP;
} else {
device_t* device = getDevice(deviceId);
if (device != NULL) {
return getScanCodeStateLocked(device, scanCode);
}
auto import from //depot/cupcake/@135843
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
return KEY_STATE_UNKNOWN;
auto import from //depot/cupcake/@135843
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 EventHub::getScanCodeStateLocked(device_t* device, int32_t scanCode) const {
uint8_t key_bitmask[(KEY_MAX + 7) / 8];
memset(key_bitmask, 0, sizeof(key_bitmask));
if (ioctl(mFDs[id_to_index(device->id)].fd,
EVIOCGKEY(sizeof(key_bitmask)), key_bitmask) >= 0) {
return test_bit(scanCode, key_bitmask) ? KEY_STATE_DOWN : KEY_STATE_UP;
auto import from //depot/cupcake/@135843
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
return KEY_STATE_UNKNOWN;
auto import from //depot/cupcake/@135843
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 EventHub::getKeyCodeState(int32_t deviceId, int32_t deviceClasses,
int32_t keyCode) const {
auto import from //depot/cupcake/@135843
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
if (deviceId == -1) {
for (int i = 0; i < mNumDevicesById; i++) {
device_t* device = mDevicesById[i].device;
if (device != NULL && (device->classes & deviceClasses) != 0) {
int32_t result = getKeyCodeStateLocked(device, keyCode);
if (result >= KEY_STATE_DOWN) {
return result;
}
}
}
return KEY_STATE_UP;
} else {
device_t* device = getDevice(deviceId);
if (device != NULL) {
return getKeyCodeStateLocked(device, keyCode);
auto import from //depot/cupcake/@135843
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
return KEY_STATE_UNKNOWN;
auto import from //depot/cupcake/@135843
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 EventHub::getKeyCodeStateLocked(device_t* device, int32_t keyCode) const {
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
Vector<int32_t> scanCodes;
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
device->layoutMap->findScancodes(keyCode, &scanCodes);
uint8_t key_bitmask[(KEY_MAX + 7) / 8];
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
memset(key_bitmask, 0, sizeof(key_bitmask));
if (ioctl(mFDs[id_to_index(device->id)].fd,
EVIOCGKEY(sizeof(key_bitmask)), key_bitmask) >= 0) {
#if 0
for (size_t i=0; i<=KEY_MAX; i++) {
LOGI("(Scan code %d: down=%d)", i, test_bit(i, key_bitmask));
}
#endif
const size_t N = scanCodes.size();
for (size_t i=0; i<N && i<=KEY_MAX; i++) {
int32_t sc = scanCodes.itemAt(i);
//LOGI("Code %d: down=%d", sc, test_bit(sc, key_bitmask));
if (sc >= 0 && sc <= KEY_MAX && test_bit(sc, key_bitmask)) {
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
return KEY_STATE_DOWN;
auto import from //depot/cupcake/@135843
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
return KEY_STATE_UP;
auto import from //depot/cupcake/@135843
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
return KEY_STATE_UNKNOWN;
}
int32_t EventHub::getSwitchState(int32_t deviceId, int32_t deviceClasses, int32_t sw) const {
#ifdef EV_SW
if (sw >= 0 && sw <= SW_MAX) {
AutoMutex _l(mLock);
if (deviceId == -1) {
deviceId = mSwitches[sw];
if (deviceId == 0) {
return KEY_STATE_UNKNOWN;
}
}
device_t* device = getDevice(deviceId);
if (device == NULL) {
return KEY_STATE_UNKNOWN;
}
return getSwitchStateLocked(device, sw);
}
#endif
return KEY_STATE_UNKNOWN;
}
int32_t EventHub::getSwitchStateLocked(device_t* device, int32_t sw) const {
uint8_t sw_bitmask[(SW_MAX + 7) / 8];
memset(sw_bitmask, 0, sizeof(sw_bitmask));
if (ioctl(mFDs[id_to_index(device->id)].fd,
EVIOCGSW(sizeof(sw_bitmask)), sw_bitmask) >= 0) {
return test_bit(sw, sw_bitmask) ? KEY_STATE_DOWN : KEY_STATE_UP;
}
return KEY_STATE_UNKNOWN;
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
}
Implement virtual button support. The kernel can now publish a property describing the layout of virtual hardware buttons on the touchscreen. These outside of the display area (outside of the absolute x and y controller range the driver reports), and when the user presses on them a key event will be generated rather than a touch event. This also includes a number of tweaks to the absolute controller processing to make things work better on the new screens. For example, we now reject down events outside of the display area. Still left to be done is the ability to cancel a key down event, so the user can slide up from the virtual keys to the touch screen without causing a virtual key to execute.
2009-07-14 19:06:54 +00:00
status_t EventHub::scancodeToKeycode(int32_t deviceId, int scancode,
int32_t* outKeycode, uint32_t* outFlags) const
{
AutoMutex _l(mLock);
device_t* device = getDevice(deviceId);
if (device != NULL && device->layoutMap != NULL) {
status_t err = device->layoutMap->map(scancode, outKeycode, outFlags);
if (err == NO_ERROR) {
return NO_ERROR;
}
}
if (mHaveFirstKeyboard) {
device = getDevice(mFirstKeyboardId);
if (device != NULL && device->layoutMap != NULL) {
status_t err = device->layoutMap->map(scancode, outKeycode, outFlags);
if (err == NO_ERROR) {
return NO_ERROR;
}
}
}
*outKeycode = 0;
*outFlags = 0;
return NAME_NOT_FOUND;
}
EventHub: Add support for excluding devices from being opened by as a keyboard. This will be used to avoid unnecessarily listening to data from sensors that function as event devices. Signed-off-by: Mike Lockwood <lockwood@android.com>
2009-07-16 15:11:18 +00:00
void EventHub::addExcludedDevice(const char* deviceName)
{
String8 name(deviceName);
mExcludedDevices.push_back(name);
}
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
EventHub::device_t* EventHub::getDevice(int32_t deviceId) const
{
if (deviceId == 0) deviceId = mFirstKeyboardId;
int32_t id = deviceId & ID_MASK;
if (id >= mNumDevicesById || id < 0) return NULL;
device_t* dev = mDevicesById[id].device;
Automated import from //branches/master/...@142771,142771
2009-03-25 23:21:55 +00:00
if (dev == NULL) return NULL;
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
if (dev->id == deviceId) {
return dev;
}
return NULL;
}
bool EventHub::getEvent(int32_t* outDeviceId, int32_t* outType,
int32_t* outScancode, int32_t* outKeycode, uint32_t *outFlags,
int32_t* outValue, nsecs_t* outWhen)
{
*outDeviceId = 0;
*outType = 0;
*outScancode = 0;
*outKeycode = 0;
*outFlags = 0;
*outValue = 0;
*outWhen = 0;
status_t err;
int i;
int res;
int pollres;
struct input_event iev;
// Note that we only allow one caller to getEvent(), so don't need
// to do locking here... only when adding/removing devices.
EventHub: Add support for excluding devices from being opened by as a keyboard. This will be used to avoid unnecessarily listening to data from sensors that function as event devices. Signed-off-by: Mike Lockwood <lockwood@android.com>
2009-07-16 15:11:18 +00:00
if (!mOpened) {
mError = openPlatformInput() ? NO_ERROR : UNKNOWN_ERROR;
mOpened = true;
}
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
while(1) {
// First, report any devices that had last been added/removed.
if (mClosingDevices != NULL) {
device_t* device = mClosingDevices;
LOGV("Reporting device closed: id=0x%x, name=%s\n",
device->id, device->path.string());
mClosingDevices = device->next;
*outDeviceId = device->id;
if (*outDeviceId == mFirstKeyboardId) *outDeviceId = 0;
*outType = DEVICE_REMOVED;
delete device;
return true;
}
if (mOpeningDevices != NULL) {
device_t* device = mOpeningDevices;
LOGV("Reporting device opened: id=0x%x, name=%s\n",
device->id, device->path.string());
mOpeningDevices = device->next;
*outDeviceId = device->id;
if (*outDeviceId == mFirstKeyboardId) *outDeviceId = 0;
*outType = DEVICE_ADDED;
return true;
}
release_wake_lock(WAKE_LOCK_ID);
pollres = poll(mFDs, mFDCount, -1);
acquire_wake_lock(PARTIAL_WAKE_LOCK, WAKE_LOCK_ID);
if (pollres <= 0) {
if (errno != EINTR) {
LOGW("select failed (errno=%d)\n", errno);
usleep(100000);
}
continue;
}
//printf("poll %d, returned %d\n", mFDCount, pollres);
// mFDs[0] is used for inotify, so process regular events starting at mFDs[1]
for(i = 1; i < mFDCount; i++) {
if(mFDs[i].revents) {
LOGV("revents for %d = 0x%08x", i, mFDs[i].revents);
if(mFDs[i].revents & POLLIN) {
res = read(mFDs[i].fd, &iev, sizeof(iev));
if (res == sizeof(iev)) {
LOGV("%s got: t0=%d, t1=%d, type=%d, code=%d, v=%d",
mDevices[i]->path.string(),
(int) iev.time.tv_sec, (int) iev.time.tv_usec,
iev.type, iev.code, iev.value);
*outDeviceId = mDevices[i]->id;
if (*outDeviceId == mFirstKeyboardId) *outDeviceId = 0;
*outType = iev.type;
*outScancode = iev.code;
if (iev.type == EV_KEY) {
err = mDevices[i]->layoutMap->map(iev.code, outKeycode, outFlags);
LOGV("iev.code=%d outKeycode=%d outFlags=0x%08x err=%d\n",
iev.code, *outKeycode, *outFlags, err);
if (err != 0) {
*outKeycode = 0;
*outFlags = 0;
}
} else {
*outKeycode = iev.code;
}
*outValue = iev.value;
*outWhen = s2ns(iev.time.tv_sec) + us2ns(iev.time.tv_usec);
return true;
} else {
if (res<0) {
LOGW("could not get event (errno=%d)", errno);
} else {
LOGE("could not get event (wrong size: %d)", res);
}
continue;
}
}
}
}
// read_notify() will modify mFDs and mFDCount, so this must be done after
// processing all other events.
if(mFDs[0].revents & POLLIN) {
read_notify(mFDs[0].fd);
}
}
}
/*
* Open the platform-specific input device.
*/
bool EventHub::openPlatformInput(void)
{
/*
* Open platform-specific input device(s).
*/
int res;
mFDCount = 1;
mFDs = (pollfd *)calloc(1, sizeof(mFDs[0]));
mDevices = (device_t **)calloc(1, sizeof(mDevices[0]));
mFDs[0].events = POLLIN;
mDevices[0] = NULL;
#ifdef HAVE_INOTIFY
mFDs[0].fd = inotify_init();
res = inotify_add_watch(mFDs[0].fd, device_path, IN_DELETE | IN_CREATE);
if(res < 0) {
LOGE("could not add watch for %s, %s\n", device_path, strerror(errno));
}
#else
/*
* The code in EventHub::getEvent assumes that mFDs[0] is an inotify fd.
* We allocate space for it and set it to something invalid.
*/
mFDs[0].fd = -1;
#endif
res = scan_dir(device_path);
if(res < 0) {
LOGE("scan dir failed for %s\n", device_path);
//open_device("/dev/input/event0");
}
return true;
}
/*
* Inspect the known devices to determine whether physical keys exist for the given
* framework-domain key codes.
*/
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
bool EventHub::hasKeys(size_t numCodes, const int32_t* keyCodes, uint8_t* outFlags) const {
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
for (size_t codeIndex = 0; codeIndex < numCodes; codeIndex++) {
outFlags[codeIndex] = 0;
// check each available hardware device for support for this keycode
Vector<int32_t> scanCodes;
for (int n = 0; (n < mFDCount) && (outFlags[codeIndex] == 0); n++) {
if (mDevices[n]) {
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
status_t err = mDevices[n]->layoutMap->findScancodes(
keyCodes[codeIndex], &scanCodes);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
if (!err) {
// check the possible scan codes identified by the layout map against the
// map of codes actually emitted by the driver
for (size_t sc = 0; sc < scanCodes.size(); sc++) {
if (test_bit(scanCodes[sc], mDevices[n]->keyBitmask)) {
outFlags[codeIndex] = 1;
break;
}
}
}
}
}
}
return true;
}
// ----------------------------------------------------------------------------
int EventHub::open_device(const char *deviceName)
{
int version;
int fd;
struct pollfd *new_mFDs;
device_t **new_devices;
char **new_device_names;
char name[80];
char location[80];
char idstr[80];
struct input_id id;
LOGV("Opening device: %s", deviceName);
AutoMutex _l(mLock);
Fix failure to open AVRCP input device due to EPERM. Sleep for 100us and try to open the input device again if it fails, with a maximum of 10 attempts. We need the retry logic because setting permissions on a new input device is racy. The init process watches for new input device (via uevent) and sets the permission on them in devices.c:make_device(). However at the same time EventHub.cpp watches for new input devices from the system_server process, and immediately tries to open them. I can't see a simple way to avoid this race condition. As best as I can tell this race condition has always exisited. There must have been some timing change that happened recently that causes us to hit this race condition much more often. See repro notes in referenced bug. Bug: 2375632
2010-01-21 03:36:49 +00:00
Revert "Fix failure to open AVRCP input device due to EPERM." This reverts commit e6b1bbd8acca3f6e174c24cf4eb23a66db2d08a2.
2010-01-26 18:27:15 +00:00
fd = open(deviceName, O_RDWR);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
if(fd < 0) {
LOGE("could not open %s, %s\n", deviceName, strerror(errno));
return -1;
}
if(ioctl(fd, EVIOCGVERSION, &version)) {
LOGE("could not get driver version for %s, %s\n", deviceName, strerror(errno));
return -1;
}
if(ioctl(fd, EVIOCGID, &id)) {
LOGE("could not get driver id for %s, %s\n", deviceName, strerror(errno));
return -1;
}
name[sizeof(name) - 1] = '\0';
location[sizeof(location) - 1] = '\0';
idstr[sizeof(idstr) - 1] = '\0';
if(ioctl(fd, EVIOCGNAME(sizeof(name) - 1), &name) < 1) {
//fprintf(stderr, "could not get device name for %s, %s\n", deviceName, strerror(errno));
name[0] = '\0';
}
EventHub: Add support for excluding devices from being opened by as a keyboard. This will be used to avoid unnecessarily listening to data from sensors that function as event devices. Signed-off-by: Mike Lockwood <lockwood@android.com>
2009-07-16 15:11:18 +00:00
// check to see if the device is on our excluded list
List<String8>::iterator iter = mExcludedDevices.begin();
List<String8>::iterator end = mExcludedDevices.end();
for ( ; iter != end; iter++) {
EventHub: Compare name instead of id when excluding event input devices. Signed-off-by: Mike Lockwood <lockwood@android.com>
2009-07-17 04:10:10 +00:00
const char* test = *iter;
if (strcmp(name, test) == 0) {
LOGI("ignoring event id %s driver %s\n", deviceName, test);
EventHub: Add support for excluding devices from being opened by as a keyboard. This will be used to avoid unnecessarily listening to data from sensors that function as event devices. Signed-off-by: Mike Lockwood <lockwood@android.com>
2009-07-16 15:11:18 +00:00
close(fd);
fd = -1;
return -1;
}
}
EventHub: Compare name instead of id when excluding event input devices. Signed-off-by: Mike Lockwood <lockwood@android.com>
2009-07-17 04:10:10 +00:00
if(ioctl(fd, EVIOCGPHYS(sizeof(location) - 1), &location) < 1) {
//fprintf(stderr, "could not get location for %s, %s\n", deviceName, strerror(errno));
location[0] = '\0';
}
if(ioctl(fd, EVIOCGUNIQ(sizeof(idstr) - 1), &idstr) < 1) {
//fprintf(stderr, "could not get idstring for %s, %s\n", deviceName, strerror(errno));
idstr[0] = '\0';
}
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
int devid = 0;
while (devid < mNumDevicesById) {
if (mDevicesById[devid].device == NULL) {
break;
}
devid++;
}
if (devid >= mNumDevicesById) {
device_ent* new_devids = (device_ent*)realloc(mDevicesById,
sizeof(mDevicesById[0]) * (devid + 1));
if (new_devids == NULL) {
LOGE("out of memory");
return -1;
}
mDevicesById = new_devids;
mNumDevicesById = devid+1;
mDevicesById[devid].device = NULL;
mDevicesById[devid].seq = 0;
}
mDevicesById[devid].seq = (mDevicesById[devid].seq+(1<<SEQ_SHIFT))&SEQ_MASK;
if (mDevicesById[devid].seq == 0) {
mDevicesById[devid].seq = 1<<SEQ_SHIFT;
}
new_mFDs = (pollfd*)realloc(mFDs, sizeof(mFDs[0]) * (mFDCount + 1));
new_devices = (device_t**)realloc(mDevices, sizeof(mDevices[0]) * (mFDCount + 1));
if (new_mFDs == NULL || new_devices == NULL) {
LOGE("out of memory");
return -1;
}
mFDs = new_mFDs;
mDevices = new_devices;
#if 0
LOGI("add device %d: %s\n", mFDCount, deviceName);
LOGI(" bus: %04x\n"
" vendor %04x\n"
" product %04x\n"
" version %04x\n",
id.bustype, id.vendor, id.product, id.version);
LOGI(" name: \"%s\"\n", name);
LOGI(" location: \"%s\"\n"
" id: \"%s\"\n", location, idstr);
LOGI(" version: %d.%d.%d\n",
version >> 16, (version >> 8) & 0xff, version & 0xff);
#endif
EventHub: pass the name of each input device up to Java Signed-off-by: Iliyan Malchev <malchev@google.com>
2009-08-06 21:50:08 +00:00
device_t* device = new device_t(devid|mDevicesById[devid].seq, deviceName, name);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
if (device == NULL) {
LOGE("out of memory");
return -1;
}
mFDs[mFDCount].fd = fd;
mFDs[mFDCount].events = POLLIN;
// figure out the kinds of events the device reports
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
Maybe fix issue #2482201: Paired bluetooth device looks like a qwerty keyboard We now only consider a device to be a default keyboard if its name has "-keypad". A hack, but whatever. Also add some debug logging for the input state to help identify such issues in the future.
2010-03-03 01:19:29 +00:00
// See if this is a keyboard, and classify it. Note that we only
// consider up through the function keys; we don't want to include
// ones after that (play cd etc) so we don't mistakenly consider a
// controller to be a keyboard.
Calculate bitmask array sizes correctly in the EventHub We've gotten lucky to date: the previous calculation of bitmask array sizes, (maxval+1)/8 only works properly when 'maxval' is one less than a multiple of 8. Fortunately, this has either been the case for us, or there has been sufficient 'unused' space at the end of the defined max value range that we haven't wound up overreading/overwriting the allocated buffers. Change-Id: I563a93a86644ab9f19489565e06c28e06bb53abc
2010-03-05 00:26:06 +00:00
uint8_t key_bitmask[(KEY_MAX+7)/8];
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
memset(key_bitmask, 0, sizeof(key_bitmask));
LOGV("Getting keys...");
if (ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(key_bitmask)), key_bitmask) >= 0) {
//LOGI("MAP\n");
Calculate bitmask array sizes correctly in the EventHub We've gotten lucky to date: the previous calculation of bitmask array sizes, (maxval+1)/8 only works properly when 'maxval' is one less than a multiple of 8. Fortunately, this has either been the case for us, or there has been sufficient 'unused' space at the end of the defined max value range that we haven't wound up overreading/overwriting the allocated buffers. Change-Id: I563a93a86644ab9f19489565e06c28e06bb53abc
2010-03-05 00:26:06 +00:00
//for (int i=0; i<((KEY_MAX+7)/8); i++) {
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
// LOGI("%d: 0x%02x\n", i, key_bitmask[i]);
//}
for (int i=0; i<((BTN_MISC+7)/8); i++) {
if (key_bitmask[i] != 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
device->classes |= INPUT_DEVICE_CLASS_KEYBOARD;
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
break;
}
}
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
if ((device->classes & INPUT_DEVICE_CLASS_KEYBOARD) != 0) {
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
device->keyBitmask = new uint8_t[sizeof(key_bitmask)];
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
if (device->keyBitmask != NULL) {
memcpy(device->keyBitmask, key_bitmask, sizeof(key_bitmask));
} else {
delete device;
LOGE("out of memory allocating key bitmask");
return -1;
}
}
}
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
// See if this is a trackball.
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
if (test_bit(BTN_MOUSE, key_bitmask)) {
Calculate bitmask array sizes correctly in the EventHub We've gotten lucky to date: the previous calculation of bitmask array sizes, (maxval+1)/8 only works properly when 'maxval' is one less than a multiple of 8. Fortunately, this has either been the case for us, or there has been sufficient 'unused' space at the end of the defined max value range that we haven't wound up overreading/overwriting the allocated buffers. Change-Id: I563a93a86644ab9f19489565e06c28e06bb53abc
2010-03-05 00:26:06 +00:00
uint8_t rel_bitmask[(REL_MAX+7)/8];
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
memset(rel_bitmask, 0, sizeof(rel_bitmask));
LOGV("Getting relative controllers...");
if (ioctl(fd, EVIOCGBIT(EV_REL, sizeof(rel_bitmask)), rel_bitmask) >= 0)
{
if (test_bit(REL_X, rel_bitmask) && test_bit(REL_Y, rel_bitmask)) {
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
device->classes |= INPUT_DEVICE_CLASS_TRACKBALL;
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
}
}
}
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
Calculate bitmask array sizes correctly in the EventHub We've gotten lucky to date: the previous calculation of bitmask array sizes, (maxval+1)/8 only works properly when 'maxval' is one less than a multiple of 8. Fortunately, this has either been the case for us, or there has been sufficient 'unused' space at the end of the defined max value range that we haven't wound up overreading/overwriting the allocated buffers. Change-Id: I563a93a86644ab9f19489565e06c28e06bb53abc
2010-03-05 00:26:06 +00:00
uint8_t abs_bitmask[(ABS_MAX+7)/8];
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
memset(abs_bitmask, 0, sizeof(abs_bitmask));
LOGV("Getting absolute controllers...");
ioctl(fd, EVIOCGBIT(EV_ABS, sizeof(abs_bitmask)), abs_bitmask);
// Is this a new modern multi-touch driver?
if (test_bit(ABS_MT_TOUCH_MAJOR, abs_bitmask)
&& test_bit(ABS_MT_POSITION_X, abs_bitmask)
&& test_bit(ABS_MT_POSITION_Y, abs_bitmask)) {
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
device->classes |= INPUT_DEVICE_CLASS_TOUCHSCREEN | INPUT_DEVICE_CLASS_TOUCHSCREEN_MT;
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
// Is this an old style single-touch driver?
} else if (test_bit(BTN_TOUCH, key_bitmask)
&& test_bit(ABS_X, abs_bitmask) && test_bit(ABS_Y, abs_bitmask)) {
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
device->classes |= INPUT_DEVICE_CLASS_TOUCHSCREEN;
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
}
#ifdef EV_SW
// figure out the switches this device reports
Calculate bitmask array sizes correctly in the EventHub We've gotten lucky to date: the previous calculation of bitmask array sizes, (maxval+1)/8 only works properly when 'maxval' is one less than a multiple of 8. Fortunately, this has either been the case for us, or there has been sufficient 'unused' space at the end of the defined max value range that we haven't wound up overreading/overwriting the allocated buffers. Change-Id: I563a93a86644ab9f19489565e06c28e06bb53abc
2010-03-05 00:26:06 +00:00
uint8_t sw_bitmask[(SW_MAX+7)/8];
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
memset(sw_bitmask, 0, sizeof(sw_bitmask));
if (ioctl(fd, EVIOCGBIT(EV_SW, sizeof(sw_bitmask)), sw_bitmask) >= 0) {
for (int i=0; i<EV_SW; i++) {
//LOGI("Device 0x%x sw %d: has=%d", device->id, i, test_bit(i, sw_bitmask));
if (test_bit(i, sw_bitmask)) {
if (mSwitches[i] == 0) {
mSwitches[i] = device->id;
}
}
}
}
#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
if ((device->classes & INPUT_DEVICE_CLASS_KEYBOARD) != 0) {
EventHub: pass the name of each input device up to Java Signed-off-by: Iliyan Malchev <malchev@google.com>
2009-08-06 21:50:08 +00:00
char tmpfn[sizeof(name)];
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
char keylayoutFilename[300];
// a more descriptive name
EventHub: pass the name of each input device up to Java Signed-off-by: Iliyan Malchev <malchev@google.com>
2009-08-06 21:50:08 +00:00
device->name = name;
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
// replace all the spaces with underscores
EventHub: pass the name of each input device up to Java Signed-off-by: Iliyan Malchev <malchev@google.com>
2009-08-06 21:50:08 +00:00
strcpy(tmpfn, name);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
for (char *p = strchr(tmpfn, ' '); p && *p; p = strchr(tmpfn, ' '))
*p = '_';
// find the .kl file we need for this device
const char* root = getenv("ANDROID_ROOT");
snprintf(keylayoutFilename, sizeof(keylayoutFilename),
"%s/usr/keylayout/%s.kl", root, tmpfn);
bool defaultKeymap = false;
if (access(keylayoutFilename, R_OK)) {
snprintf(keylayoutFilename, sizeof(keylayoutFilename),
"%s/usr/keylayout/%s", root, "qwerty.kl");
defaultKeymap = true;
}
device->layoutMap->load(keylayoutFilename);
// tell the world about the devname (the descriptive name)
Maybe fix issue #2482201: Paired bluetooth device looks like a qwerty keyboard We now only consider a device to be a default keyboard if its name has "-keypad". A hack, but whatever. Also add some debug logging for the input state to help identify such issues in the future.
2010-03-03 01:19:29 +00:00
if (!mHaveFirstKeyboard && !defaultKeymap && strstr(name, "-keypad")) {
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
// the built-in keyboard has a well-known device ID of 0,
// this device better not go away.
mHaveFirstKeyboard = true;
mFirstKeyboardId = device->id;
Maybe fix issue #2482201: Paired bluetooth device looks like a qwerty keyboard We now only consider a device to be a default keyboard if its name has "-keypad". A hack, but whatever. Also add some debug logging for the input state to help identify such issues in the future.
2010-03-03 01:19:29 +00:00
property_set("hw.keyboards.0.devname", name);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
} else {
// ensure mFirstKeyboardId is set to -something-.
if (mFirstKeyboardId == 0) {
mFirstKeyboardId = device->id;
}
}
char propName[100];
Maybe fix issue #2482201: Paired bluetooth device looks like a qwerty keyboard We now only consider a device to be a default keyboard if its name has "-keypad". A hack, but whatever. Also add some debug logging for the input state to help identify such issues in the future.
2010-03-03 01:19:29 +00:00
sprintf(propName, "hw.keyboards.%u.devname", device->id);
EventHub: pass the name of each input device up to Java Signed-off-by: Iliyan Malchev <malchev@google.com>
2009-08-06 21:50:08 +00:00
property_set(propName, name);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
// 'Q' key support = cheap test of whether this is an alpha-capable kbd
if (hasKeycode(device, kKeyCodeQ)) {
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
device->classes |= INPUT_DEVICE_CLASS_ALPHAKEY;
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
}
// See if this has a DPAD.
if (hasKeycode(device, kKeyCodeDpadUp) &&
hasKeycode(device, kKeyCodeDpadDown) &&
hasKeycode(device, kKeyCodeDpadLeft) &&
hasKeycode(device, kKeyCodeDpadRight) &&
hasKeycode(device, kKeyCodeDpadCenter)) {
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
device->classes |= INPUT_DEVICE_CLASS_DPAD;
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
}
Maybe fix issue #2482201: Paired bluetooth device looks like a qwerty keyboard We now only consider a device to be a default keyboard if its name has "-keypad". A hack, but whatever. Also add some debug logging for the input state to help identify such issues in the future.
2010-03-03 01:19:29 +00:00
LOGI("New keyboard: device->id=0x%x devname='%s' propName='%s' keylayout='%s'\n",
device->id, name, propName, keylayoutFilename);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
}
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
LOGI("New device: path=%s name=%s id=0x%x (of 0x%x) index=%d fd=%d classes=0x%x\n",
deviceName, name, device->id, mNumDevicesById, mFDCount, fd, device->classes);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
LOGV("Adding device %s %p at %d, id = %d, classes = 0x%x\n",
deviceName, device, mFDCount, devid, device->classes);
mDevicesById[devid].device = device;
device->next = mOpeningDevices;
mOpeningDevices = device;
mDevices[mFDCount] = device;
mFDCount++;
return 0;
}
Finish implementation of multiple pointer support for MotionEvent. The major things going on here: - The MotionEvent API is now extended to included "pointer ID" information, for applications to keep track of individual fingers as they move up and down. PointerLocation has been updated to take advantage of this. - The input system now has logic to generate MotionEvents with the new ID information, synthesizing an identifier as new points are down and trying to keep pointer ids consistent across events by looking at the distance between the last and next set of pointers. - We now support the new multitouch driver protocol, and will use that instead of the old one if it is available. We do NOT use any finger id information coming from the driver, but always synthesize pointer ids in user space. (This is simply because we don't yet have a driver reporting this information from which to base an implementation on.) - Increase maximum number of fingers to 10. This code has only been used with a driver that reports up to 2, so no idea how more will actually work. - Oh and the input system can now detect and report physical DPAD devices.
2009-08-04 12:49:43 +00:00
bool EventHub::hasKeycode(device_t* device, int keycode) const
{
if (device->keyBitmask == NULL || device->layoutMap == NULL) {
return false;
}
Vector<int32_t> scanCodes;
device->layoutMap->findScancodes(keycode, &scanCodes);
const size_t N = scanCodes.size();
for (size_t i=0; i<N && i<=KEY_MAX; i++) {
int32_t sc = scanCodes.itemAt(i);
if (sc >= 0 && sc <= KEY_MAX && test_bit(sc, device->keyBitmask)) {
return true;
}
}
return false;
}
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
int EventHub::close_device(const char *deviceName)
{
AutoMutex _l(mLock);
int i;
for(i = 1; i < mFDCount; i++) {
if(strcmp(mDevices[i]->path.string(), deviceName) == 0) {
//LOGD("remove device %d: %s\n", i, deviceName);
device_t* device = mDevices[i];
Work on issue #2079167: Flickering issue across multiple UI This addresses a few parts of the bug: - There was a small issue in the window manager where we could show a window too early before the transition animation starts, which was introduced by the recent wallpaper work. This was the cause of the flicker when starting the dialer for the first time. - There was a much larger problem that has existing forever where moving an application token to the front or back was not synchronized with the application animation transaction. This was the cause of the flicker when hanging up (now that the in-call screen moves to the back instead of closing and we always have a wallpaper visible). The approach to solving this is to have the window manager go ahead and move the app tokens (it must in order to keep in sync with the activity manager), but to delay the actual window movement: perform the movement to front when the animation starts, and to back when it ends. Actually, when the animation ends, we just go and completely rebuild the window list to ensure it is correct, because there can be ways people can add windows while in this intermediate state where they could end up at the wrong place once we do the delayed movement to the front or back. And it is simply reasuring to know that every time we finish a full app transition, we re-evaluate the world and put everything in its proper place. Also included in this change are a few little tweaks to the input system, to perform better logging, and completely ignore input devices that do not have any of our input classes. There is also a little cleanup of evaluating configuration changes to not do more work than needed when an input devices appears or disappears, and to only log a config change message when the config is truly changing. Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
2009-09-02 02:01:50 +00:00
LOGI("Removed device: path=%s name=%s id=0x%x (of 0x%x) index=%d fd=%d classes=0x%x\n",
device->path.string(), device->name.string(), device->id,
mNumDevicesById, mFDCount, mFDs[i].fd, device->classes);
// Clear this device's entry.
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
int index = (device->id&ID_MASK);
mDevicesById[index].device = NULL;
Work on issue #2079167: Flickering issue across multiple UI This addresses a few parts of the bug: - There was a small issue in the window manager where we could show a window too early before the transition animation starts, which was introduced by the recent wallpaper work. This was the cause of the flicker when starting the dialer for the first time. - There was a much larger problem that has existing forever where moving an application token to the front or back was not synchronized with the application animation transaction. This was the cause of the flicker when hanging up (now that the in-call screen moves to the back instead of closing and we always have a wallpaper visible). The approach to solving this is to have the window manager go ahead and move the app tokens (it must in order to keep in sync with the activity manager), but to delay the actual window movement: perform the movement to front when the animation starts, and to back when it ends. Actually, when the animation ends, we just go and completely rebuild the window list to ensure it is correct, because there can be ways people can add windows while in this intermediate state where they could end up at the wrong place once we do the delayed movement to the front or back. And it is simply reasuring to know that every time we finish a full app transition, we re-evaluate the world and put everything in its proper place. Also included in this change are a few little tweaks to the input system, to perform better logging, and completely ignore input devices that do not have any of our input classes. There is also a little cleanup of evaluating configuration changes to not do more work than needed when an input devices appears or disappears, and to only log a config change message when the config is truly changing. Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
2009-09-02 02:01:50 +00:00
// Close the file descriptor and compact the fd array.
EventHub: Fix file descriptor leak. Signed-off-by: Mike Lockwood <lockwood@android.com>
2009-08-28 20:29:06 +00:00
close(mFDs[i].fd);
Work on issue #2079167: Flickering issue across multiple UI This addresses a few parts of the bug: - There was a small issue in the window manager where we could show a window too early before the transition animation starts, which was introduced by the recent wallpaper work. This was the cause of the flicker when starting the dialer for the first time. - There was a much larger problem that has existing forever where moving an application token to the front or back was not synchronized with the application animation transaction. This was the cause of the flicker when hanging up (now that the in-call screen moves to the back instead of closing and we always have a wallpaper visible). The approach to solving this is to have the window manager go ahead and move the app tokens (it must in order to keep in sync with the activity manager), but to delay the actual window movement: perform the movement to front when the animation starts, and to back when it ends. Actually, when the animation ends, we just go and completely rebuild the window list to ensure it is correct, because there can be ways people can add windows while in this intermediate state where they could end up at the wrong place once we do the delayed movement to the front or back. And it is simply reasuring to know that every time we finish a full app transition, we re-evaluate the world and put everything in its proper place. Also included in this change are a few little tweaks to the input system, to perform better logging, and completely ignore input devices that do not have any of our input classes. There is also a little cleanup of evaluating configuration changes to not do more work than needed when an input devices appears or disappears, and to only log a config change message when the config is truly changing. Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
2009-09-02 02:01:50 +00:00
int count = mFDCount - i - 1;
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
memmove(mDevices + i, mDevices + i + 1, sizeof(mDevices[0]) * count);
memmove(mFDs + i, mFDs + i + 1, sizeof(mFDs[0]) * count);
Work on issue #2079167: Flickering issue across multiple UI This addresses a few parts of the bug: - There was a small issue in the window manager where we could show a window too early before the transition animation starts, which was introduced by the recent wallpaper work. This was the cause of the flicker when starting the dialer for the first time. - There was a much larger problem that has existing forever where moving an application token to the front or back was not synchronized with the application animation transaction. This was the cause of the flicker when hanging up (now that the in-call screen moves to the back instead of closing and we always have a wallpaper visible). The approach to solving this is to have the window manager go ahead and move the app tokens (it must in order to keep in sync with the activity manager), but to delay the actual window movement: perform the movement to front when the animation starts, and to back when it ends. Actually, when the animation ends, we just go and completely rebuild the window list to ensure it is correct, because there can be ways people can add windows while in this intermediate state where they could end up at the wrong place once we do the delayed movement to the front or back. And it is simply reasuring to know that every time we finish a full app transition, we re-evaluate the world and put everything in its proper place. Also included in this change are a few little tweaks to the input system, to perform better logging, and completely ignore input devices that do not have any of our input classes. There is also a little cleanup of evaluating configuration changes to not do more work than needed when an input devices appears or disappears, and to only log a config change message when the config is truly changing. Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
2009-09-02 02:01:50 +00:00
mFDCount--;
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
#ifdef EV_SW
for (int j=0; j<EV_SW; j++) {
if (mSwitches[j] == device->id) {
mSwitches[j] = 0;
}
}
#endif
device->next = mClosingDevices;
mClosingDevices = device;
if (device->id == mFirstKeyboardId) {
LOGW("built-in keyboard device %s (id=%d) is closing! the apps will not like this",
device->path.string(), mFirstKeyboardId);
mFirstKeyboardId = 0;
Maybe fix issue #2482201: Paired bluetooth device looks like a qwerty keyboard We now only consider a device to be a default keyboard if its name has "-keypad". A hack, but whatever. Also add some debug logging for the input state to help identify such issues in the future.
2010-03-03 01:19:29 +00:00
property_set("hw.keyboards.0.devname", NULL);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
}
// clear the property
char propName[100];
Maybe fix issue #2482201: Paired bluetooth device looks like a qwerty keyboard We now only consider a device to be a default keyboard if its name has "-keypad". A hack, but whatever. Also add some debug logging for the input state to help identify such issues in the future.
2010-03-03 01:19:29 +00:00
sprintf(propName, "hw.keyboards.%u.devname", device->id);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
property_set(propName, NULL);
return 0;
}
}
Work on issue #2079167: Flickering issue across multiple UI This addresses a few parts of the bug: - There was a small issue in the window manager where we could show a window too early before the transition animation starts, which was introduced by the recent wallpaper work. This was the cause of the flicker when starting the dialer for the first time. - There was a much larger problem that has existing forever where moving an application token to the front or back was not synchronized with the application animation transaction. This was the cause of the flicker when hanging up (now that the in-call screen moves to the back instead of closing and we always have a wallpaper visible). The approach to solving this is to have the window manager go ahead and move the app tokens (it must in order to keep in sync with the activity manager), but to delay the actual window movement: perform the movement to front when the animation starts, and to back when it ends. Actually, when the animation ends, we just go and completely rebuild the window list to ensure it is correct, because there can be ways people can add windows while in this intermediate state where they could end up at the wrong place once we do the delayed movement to the front or back. And it is simply reasuring to know that every time we finish a full app transition, we re-evaluate the world and put everything in its proper place. Also included in this change are a few little tweaks to the input system, to perform better logging, and completely ignore input devices that do not have any of our input classes. There is also a little cleanup of evaluating configuration changes to not do more work than needed when an input devices appears or disappears, and to only log a config change message when the config is truly changing. Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
2009-09-02 02:01:50 +00:00
LOGE("remove device: %s not found\n", deviceName);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
return -1;
}
int EventHub::read_notify(int nfd)
{
#ifdef HAVE_INOTIFY
int res;
char devname[PATH_MAX];
char *filename;
char event_buf[512];
int event_size;
int event_pos = 0;
struct inotify_event *event;
Work on issue #2079167: Flickering issue across multiple UI This addresses a few parts of the bug: - There was a small issue in the window manager where we could show a window too early before the transition animation starts, which was introduced by the recent wallpaper work. This was the cause of the flicker when starting the dialer for the first time. - There was a much larger problem that has existing forever where moving an application token to the front or back was not synchronized with the application animation transaction. This was the cause of the flicker when hanging up (now that the in-call screen moves to the back instead of closing and we always have a wallpaper visible). The approach to solving this is to have the window manager go ahead and move the app tokens (it must in order to keep in sync with the activity manager), but to delay the actual window movement: perform the movement to front when the animation starts, and to back when it ends. Actually, when the animation ends, we just go and completely rebuild the window list to ensure it is correct, because there can be ways people can add windows while in this intermediate state where they could end up at the wrong place once we do the delayed movement to the front or back. And it is simply reasuring to know that every time we finish a full app transition, we re-evaluate the world and put everything in its proper place. Also included in this change are a few little tweaks to the input system, to perform better logging, and completely ignore input devices that do not have any of our input classes. There is also a little cleanup of evaluating configuration changes to not do more work than needed when an input devices appears or disappears, and to only log a config change message when the config is truly changing. Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
2009-09-02 02:01:50 +00:00
LOGV("EventHub::read_notify nfd: %d\n", nfd);
auto import from //depot/cupcake/@135843
2009-03-04 03:31:44 +00:00
res = read(nfd, event_buf, sizeof(event_buf));
if(res < (int)sizeof(*event)) {
if(errno == EINTR)
return 0;
LOGW("could not get event, %s\n", strerror(errno));
return 1;
}
//printf("got %d bytes of event information\n", res);
strcpy(devname, device_path);
filename = devname + strlen(devname);
*filename++ = '/';
while(res >= (int)sizeof(*event)) {
event = (struct inotify_event *)(event_buf + event_pos);
//printf("%d: %08x \"%s\"\n", event->wd, event->mask, event->len ? event->name : "");
if(event->len) {
strcpy(filename, event->name);
if(event->mask & IN_CREATE) {
open_device(devname);
}
else {
close_device(devname);
}
}
event_size = sizeof(*event) + event->len;
res -= event_size;
event_pos += event_size;
}
#endif
return 0;
}
int EventHub::scan_dir(const char *dirname)
{
char devname[PATH_MAX];
char *filename;
DIR *dir;
struct dirent *de;
dir = opendir(dirname);
if(dir == NULL)
return -1;
strcpy(devname, dirname);
filename = devname + strlen(devname);
*filename++ = '/';
while((de = readdir(dir))) {
if(de->d_name[0] == '.' &&
(de->d_name[1] == '\0' ||
(de->d_name[1] == '.' && de->d_name[2] == '\0')))
continue;
strcpy(filename, de->d_name);
open_device(devname);
}
closedir(dir);
return 0;
}
}; // namespace android
Reference in New Issue Copy Permalink