Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-23 01:58:52 +00:00
|
|
|
//
|
|
|
|
// Copyright 2010 The Android Open Source Project
|
|
|
|
//
|
|
|
|
// A select loop implementation.
|
|
|
|
//
|
|
|
|
#define LOG_TAG "PollLoop"
|
|
|
|
|
|
|
|
//#define LOG_NDEBUG 0
|
|
|
|
|
|
|
|
// Debugs poll and wake interactions.
|
|
|
|
#define DEBUG_POLL_AND_WAKE 0
|
|
|
|
|
|
|
|
// Debugs callback registration and invocation.
|
2010-06-16 08:53:36 +00:00
|
|
|
#define DEBUG_CALLBACKS 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
|
|
|
|
|
|
|
#include <cutils/log.h>
|
|
|
|
#include <utils/PollLoop.h>
|
|
|
|
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <fcntl.h>
|
|
|
|
|
|
|
|
namespace android {
|
|
|
|
|
2010-07-03 01:52:01 +00:00
|
|
|
static pthread_mutex_t gTLSMutex = PTHREAD_MUTEX_INITIALIZER;
|
|
|
|
static bool gHaveTLS = false;
|
|
|
|
static pthread_key_t gTLS = 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
|
|
|
PollLoop::PollLoop() :
|
2010-06-16 08:53:36 +00:00
|
|
|
mPolling(false), mWaiters(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
|
|
|
openWakePipe();
|
|
|
|
}
|
|
|
|
|
|
|
|
PollLoop::~PollLoop() {
|
|
|
|
closeWakePipe();
|
|
|
|
}
|
|
|
|
|
2010-07-03 01:52:01 +00:00
|
|
|
void PollLoop::threadDestructor(void *st) {
|
|
|
|
PollLoop* const self = static_cast<PollLoop*>(st);
|
|
|
|
if (self != NULL) {
|
|
|
|
self->decStrong((void*)threadDestructor);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void PollLoop::setForThread(const sp<PollLoop>& pollLoop) {
|
|
|
|
sp<PollLoop> old = getForThread();
|
|
|
|
|
|
|
|
if (pollLoop != NULL) {
|
|
|
|
pollLoop->incStrong((void*)threadDestructor);
|
|
|
|
}
|
|
|
|
|
|
|
|
pthread_setspecific(gTLS, pollLoop.get());
|
|
|
|
|
|
|
|
if (old != NULL) {
|
|
|
|
old->decStrong((void*)threadDestructor);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
sp<PollLoop> PollLoop::getForThread() {
|
|
|
|
if (!gHaveTLS) {
|
|
|
|
pthread_mutex_lock(&gTLSMutex);
|
|
|
|
if (pthread_key_create(&gTLS, threadDestructor) != 0) {
|
|
|
|
pthread_mutex_unlock(&gTLSMutex);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
gHaveTLS = true;
|
|
|
|
pthread_mutex_unlock(&gTLSMutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (PollLoop*)pthread_getspecific(gTLS);
|
|
|
|
}
|
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-23 01:58:52 +00:00
|
|
|
void PollLoop::openWakePipe() {
|
|
|
|
int wakeFds[2];
|
|
|
|
int result = pipe(wakeFds);
|
|
|
|
LOG_ALWAYS_FATAL_IF(result != 0, "Could not create wake pipe. errno=%d", errno);
|
|
|
|
|
|
|
|
mWakeReadPipeFd = wakeFds[0];
|
|
|
|
mWakeWritePipeFd = wakeFds[1];
|
|
|
|
|
|
|
|
result = fcntl(mWakeReadPipeFd, F_SETFL, O_NONBLOCK);
|
|
|
|
LOG_ALWAYS_FATAL_IF(result != 0, "Could not make wake read pipe non-blocking. errno=%d",
|
|
|
|
errno);
|
|
|
|
|
|
|
|
result = fcntl(mWakeWritePipeFd, F_SETFL, O_NONBLOCK);
|
|
|
|
LOG_ALWAYS_FATAL_IF(result != 0, "Could not make wake write pipe non-blocking. errno=%d",
|
|
|
|
errno);
|
|
|
|
|
|
|
|
// Add the wake pipe to the head of the request list with a null callback.
|
|
|
|
struct pollfd requestedFd;
|
|
|
|
requestedFd.fd = mWakeReadPipeFd;
|
|
|
|
requestedFd.events = POLLIN;
|
|
|
|
mRequestedFds.insertAt(requestedFd, 0);
|
|
|
|
|
|
|
|
RequestedCallback requestedCallback;
|
|
|
|
requestedCallback.callback = NULL;
|
2010-07-03 01:52:01 +00:00
|
|
|
requestedCallback.looperCallback = NULL;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-23 01:58:52 +00:00
|
|
|
requestedCallback.data = NULL;
|
|
|
|
mRequestedCallbacks.insertAt(requestedCallback, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void PollLoop::closeWakePipe() {
|
|
|
|
close(mWakeReadPipeFd);
|
|
|
|
close(mWakeWritePipeFd);
|
|
|
|
|
|
|
|
// Note: We don't need to remove the poll structure or callback entry because this
|
|
|
|
// method is currently only called by the destructor.
|
|
|
|
}
|
|
|
|
|
|
|
|
bool PollLoop::pollOnce(int timeoutMillis) {
|
|
|
|
mLock.lock();
|
2010-06-16 08:53:36 +00:00
|
|
|
while (mWaiters != 0) {
|
|
|
|
mResume.wait(mLock);
|
|
|
|
}
|
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
|
|
|
mPolling = true;
|
|
|
|
mLock.unlock();
|
|
|
|
|
|
|
|
bool result;
|
|
|
|
size_t requestedCount = mRequestedFds.size();
|
|
|
|
|
|
|
|
#if DEBUG_POLL_AND_WAKE
|
|
|
|
LOGD("%p ~ pollOnce - waiting on %d fds", this, requestedCount);
|
|
|
|
for (size_t i = 0; i < requestedCount; i++) {
|
|
|
|
LOGD(" fd %d - events %d", mRequestedFds[i].fd, mRequestedFds[i].events);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
int respondedCount = poll(mRequestedFds.editArray(), requestedCount, timeoutMillis);
|
|
|
|
|
|
|
|
if (respondedCount == 0) {
|
|
|
|
// Timeout
|
|
|
|
#if DEBUG_POLL_AND_WAKE
|
|
|
|
LOGD("%p ~ pollOnce - timeout", this);
|
|
|
|
#endif
|
|
|
|
result = false;
|
|
|
|
goto Done;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (respondedCount < 0) {
|
|
|
|
// Error
|
|
|
|
#if DEBUG_POLL_AND_WAKE
|
|
|
|
LOGD("%p ~ pollOnce - error, errno=%d", this, errno);
|
|
|
|
#endif
|
|
|
|
if (errno != EINTR) {
|
|
|
|
LOGW("Poll failed with an unexpected error, errno=%d", errno);
|
|
|
|
}
|
|
|
|
result = false;
|
|
|
|
goto Done;
|
|
|
|
}
|
|
|
|
|
|
|
|
#if DEBUG_POLL_AND_WAKE
|
|
|
|
LOGD("%p ~ pollOnce - handling responses from %d fds", this, respondedCount);
|
|
|
|
for (size_t i = 0; i < requestedCount; i++) {
|
|
|
|
LOGD(" fd %d - events %d, revents %d", mRequestedFds[i].fd, mRequestedFds[i].events,
|
|
|
|
mRequestedFds[i].revents);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
mPendingCallbacks.clear();
|
|
|
|
for (size_t i = 0; i < requestedCount; i++) {
|
|
|
|
const struct pollfd& requestedFd = mRequestedFds.itemAt(i);
|
|
|
|
|
|
|
|
short revents = requestedFd.revents;
|
|
|
|
if (revents) {
|
|
|
|
const RequestedCallback& requestedCallback = mRequestedCallbacks.itemAt(i);
|
|
|
|
Callback callback = requestedCallback.callback;
|
2010-07-03 01:52:01 +00:00
|
|
|
ALooper_callbackFunc* looperCallback = requestedCallback.looperCallback;
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-23 01:58:52 +00:00
|
|
|
|
2010-07-03 01:52:01 +00:00
|
|
|
if (callback || looperCallback) {
|
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
|
|
|
PendingCallback pendingCallback;
|
|
|
|
pendingCallback.fd = requestedFd.fd;
|
|
|
|
pendingCallback.events = requestedFd.revents;
|
|
|
|
pendingCallback.callback = callback;
|
2010-07-03 01:52:01 +00:00
|
|
|
pendingCallback.looperCallback = looperCallback;
|
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
|
|
|
pendingCallback.data = requestedCallback.data;
|
|
|
|
mPendingCallbacks.push(pendingCallback);
|
|
|
|
} else {
|
|
|
|
if (requestedFd.fd == mWakeReadPipeFd) {
|
|
|
|
#if DEBUG_POLL_AND_WAKE
|
|
|
|
LOGD("%p ~ pollOnce - awoken", this);
|
|
|
|
#endif
|
|
|
|
char buffer[16];
|
|
|
|
ssize_t nRead;
|
|
|
|
do {
|
|
|
|
nRead = read(mWakeReadPipeFd, buffer, sizeof(buffer));
|
|
|
|
} while (nRead == sizeof(buffer));
|
|
|
|
} else {
|
|
|
|
#if DEBUG_POLL_AND_WAKE || DEBUG_CALLBACKS
|
|
|
|
LOGD("%p ~ pollOnce - fd %d has no callback!", this, requestedFd.fd);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
respondedCount -= 1;
|
|
|
|
if (respondedCount == 0) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
result = true;
|
|
|
|
|
|
|
|
Done:
|
|
|
|
mLock.lock();
|
|
|
|
mPolling = false;
|
2010-06-16 08:53:36 +00:00
|
|
|
if (mWaiters != 0) {
|
|
|
|
mAwake.broadcast();
|
|
|
|
}
|
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
|
|
|
mLock.unlock();
|
|
|
|
|
|
|
|
if (result) {
|
|
|
|
size_t pendingCount = mPendingCallbacks.size();
|
|
|
|
for (size_t i = 0; i < pendingCount; i++) {
|
|
|
|
const PendingCallback& pendingCallback = mPendingCallbacks.itemAt(i);
|
|
|
|
#if DEBUG_POLL_AND_WAKE || DEBUG_CALLBACKS
|
|
|
|
LOGD("%p ~ pollOnce - invoking callback for fd %d", this, pendingCallback.fd);
|
|
|
|
#endif
|
|
|
|
|
2010-07-03 01:52:01 +00:00
|
|
|
bool keep = true;
|
|
|
|
if (pendingCallback.callback != NULL) {
|
|
|
|
keep = pendingCallback.callback(pendingCallback.fd, pendingCallback.events,
|
|
|
|
pendingCallback.data);
|
|
|
|
} else {
|
|
|
|
keep = pendingCallback.looperCallback(pendingCallback.fd, pendingCallback.events,
|
|
|
|
pendingCallback.data) != 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
|
|
|
if (! keep) {
|
|
|
|
removeCallback(pendingCallback.fd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#if DEBUG_POLL_AND_WAKE
|
|
|
|
LOGD("%p ~ pollOnce - done", this);
|
|
|
|
#endif
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
void PollLoop::wake() {
|
|
|
|
#if DEBUG_POLL_AND_WAKE
|
|
|
|
LOGD("%p ~ wake", this);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
ssize_t nWrite = write(mWakeWritePipeFd, "W", 1);
|
|
|
|
if (nWrite != 1) {
|
|
|
|
if (errno != EAGAIN) {
|
|
|
|
LOGW("Could not write wake signal, errno=%d", errno);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void PollLoop::setCallback(int fd, int events, Callback callback, void* data) {
|
2010-07-03 01:52:01 +00:00
|
|
|
setCallbackCommon(fd, events, callback, NULL, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
void PollLoop::setLooperCallback(int fd, int events, ALooper_callbackFunc* callback,
|
|
|
|
void* data) {
|
|
|
|
setCallbackCommon(fd, events, NULL, callback, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
void PollLoop::setCallbackCommon(int fd, int events, Callback callback,
|
|
|
|
ALooper_callbackFunc* looperCallback, void* data) {
|
|
|
|
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-23 01:58:52 +00:00
|
|
|
#if DEBUG_CALLBACKS
|
|
|
|
LOGD("%p ~ setCallback - fd=%d, events=%d", this, fd, events);
|
|
|
|
#endif
|
|
|
|
|
2010-07-03 01:52:01 +00:00
|
|
|
if (! events || (! callback && ! looperCallback)) {
|
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
|
|
|
LOGE("Invalid attempt to set a callback with no selected poll events or no callback.");
|
|
|
|
removeCallback(fd);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
wakeAndLock();
|
|
|
|
|
|
|
|
struct pollfd requestedFd;
|
|
|
|
requestedFd.fd = fd;
|
|
|
|
requestedFd.events = events;
|
|
|
|
|
|
|
|
RequestedCallback requestedCallback;
|
|
|
|
requestedCallback.callback = callback;
|
2010-07-03 01:52:01 +00:00
|
|
|
requestedCallback.looperCallback = looperCallback;
|
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
|
|
|
requestedCallback.data = data;
|
|
|
|
|
|
|
|
ssize_t index = getRequestIndexLocked(fd);
|
|
|
|
if (index < 0) {
|
|
|
|
mRequestedFds.push(requestedFd);
|
|
|
|
mRequestedCallbacks.push(requestedCallback);
|
|
|
|
} else {
|
|
|
|
mRequestedFds.replaceAt(requestedFd, size_t(index));
|
|
|
|
mRequestedCallbacks.replaceAt(requestedCallback, size_t(index));
|
|
|
|
}
|
|
|
|
|
|
|
|
mLock.unlock();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool PollLoop::removeCallback(int fd) {
|
|
|
|
#if DEBUG_CALLBACKS
|
|
|
|
LOGD("%p ~ removeCallback - fd=%d", this, fd);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
wakeAndLock();
|
|
|
|
|
|
|
|
ssize_t index = getRequestIndexLocked(fd);
|
|
|
|
if (index >= 0) {
|
|
|
|
mRequestedFds.removeAt(size_t(index));
|
|
|
|
mRequestedCallbacks.removeAt(size_t(index));
|
|
|
|
}
|
|
|
|
|
|
|
|
mLock.unlock();
|
|
|
|
return index >= 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
ssize_t PollLoop::getRequestIndexLocked(int fd) {
|
|
|
|
size_t requestCount = mRequestedFds.size();
|
|
|
|
|
|
|
|
for (size_t i = 0; i < requestCount; i++) {
|
|
|
|
if (mRequestedFds.itemAt(i).fd == fd) {
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
void PollLoop::wakeAndLock() {
|
|
|
|
mLock.lock();
|
2010-06-16 08:53:36 +00:00
|
|
|
mWaiters += 1;
|
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
|
|
|
while (mPolling) {
|
|
|
|
wake();
|
|
|
|
mAwake.wait(mLock);
|
|
|
|
}
|
2010-06-16 08:53:36 +00:00
|
|
|
mWaiters -= 1;
|
|
|
|
if (mWaiters == 0) {
|
|
|
|
mResume.signal();
|
|
|
|
}
|
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
2010-04-23 01:58:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace android
|