Lines Matching defs:events
43 // Log debug messages about hover events.
70 // Amount of time to allow for all pending events to be processed when an app switch
71 // key is on the way. This is used to preempt input dispatch and drop input events
79 // Amount of time to allow touch events to be streamed out to a connection before requiring
82 // queue of waiting unfinished events, then ANRs will similarly be delayed by one second.
88 // Number of recent events to keep for debugging purposes.
265 // If dispatching is frozen, do not process timeouts or try to deliver any new events.
275 // been pressed. When it expires, we preempt dispatch and drop all other pending events.
323 // All events are eventually dequeued and processed this way, even if we intend to drop them.
416 // If the application takes too long to catch up then we drop all events preceding
439 // If the application takes too long to catch up then we drop all events preceding
1244 // New window does not support splitting but we have already split events.
1430 // engine only supports touch events. We would need to add a mechanism similar
1431 // to View.onGenericMotionEvent to enable wallpapers to handle these events.
1693 // If the event is a key event, then we must wait for all previous events to
1694 // complete before delivering it because previous events may have the
1702 // To obtain this behavior, we must serialize key events with respect to all
1703 // prior input events.
1706 "finished processing all of the input events that were previously "
1711 // Touch events can always be sent to a window immediately because the user intended
1716 // Generic motion events, such as trackball or joystick events are a little trickier.
1717 // Like key events, generic motion events are delivered to the focused window.
1718 // Unlike key events, generic motion events don't tend to transfer focus to other
1720 // generic motion events as soon as possible to improve efficiency and reduce lag
1724 // up with lots of events because the application is not responding.
1730 "finished processing certain input events that were delivered to it over "
1811 // We don't want to enqueue additional outbound events if the connection is broken.
2052 // Pipe is full and we are waiting for the app to finish process some events
2053 // before sending more events to it.
2134 int InputDispatcher::handleReceiveCallback(int fd, int events, void* data) {
2143 "fd=%d, events=0x%x", fd, events);
2149 if (!(events & (ALOOPER_EVENT_ERROR | ALOOPER_EVENT_HANGUP))) {
2150 if (!(events & ALOOPER_EVENT_INPUT)) {
2152 "events=0x%x", connection->getInputChannelName(), events);
2188 "events=0x%x", connection->getInputChannelName(), events);
2236 ALOGD("channel '%s' ~ Synthesized %d cancelation events to bring channel back in sync "
2306 // Most likely this indicates that we received an ACTION_MOVE events that has
2308 // or ACTION_POINTER_DOWN events that caused us to decide to split the pointers
2429 // In order to maintain a consistent stream of up and down events, check to see if the key
2431 // even if the modifier was released between the down and the up events.
2559 // TODO: support sending secondary display events to input filter
3117 ALOGD("Resetting and dropping all events (%s).", reason);
3232 // Dump recently dispatched or dropped events from oldest to newest.
3256 // Dump inbound events from oldest to newest.
4085 * So for now, allow inconsistent key up events to be dispatched.
4143 // Trackballs can send MOVE events with a corresponding DOWN or UP. There's no need to
4144 // generate cancellation events for these since they're based in relative rather than
4152 // Joysticks can send MOVE events without a corresponding DOWN or UP. Since all
4154 // other value and we need to track the motion so we can send cancellation events for
4155 // anything generating fallback events (e.g. DPad keys for joystick movements).
4167 // Joysticks and trackballs can send MOVE events without corresponding DOWN or UP.