Query input device for initial slot index.
This fixes a problem where touches can get stuck because the
driver and the framework have different ideas of what the
initial slot index is. The framework assumed it was slot 0
but it could in principle be any slot, such as slot 1. When
that happened, the framework would start tracking the first
touch as slot 0, but it might never receive an "up" for that slot.
Change-Id: Idaffc4534b275d66b9d4360987b28dc2d0f63218
diff --git a/services/input/InputReader.cpp b/services/input/InputReader.cpp
index 82c3af3..79218a5 100644
--- a/services/input/InputReader.cpp
+++ b/services/input/InputReader.cpp
@@ -5394,7 +5394,6 @@
MultiTouchInputMapper::MultiTouchInputMapper(InputDevice* device) :
TouchInputMapper(device), mSlotCount(0), mUsingSlotsProtocol(false) {
- clearState();
}
MultiTouchInputMapper::~MultiTouchInputMapper() {
@@ -5404,6 +5403,24 @@
mAccumulator.clearSlots(mSlotCount);
mAccumulator.clearButtons();
mButtonState = 0;
+
+ if (mUsingSlotsProtocol) {
+ // Query the driver for the current slot index and use it as the initial slot
+ // before we start reading events from the device. It is possible that the
+ // current slot index will not be the same as it was when the first event was
+ // written into the evdev buffer, which means the input mapper could start
+ // out of sync with the initial state of the events in the evdev buffer.
+ // In the extremely unlikely case that this happens, the data from
+ // two slots will be confused until the next ABS_MT_SLOT event is received.
+ // This can cause the touch point to "jump", but at least there will be
+ // no stuck touches.
+ status_t status = getEventHub()->getAbsoluteAxisValue(getDeviceId(), ABS_MT_SLOT,
+ &mAccumulator.currentSlot);
+ if (status) {
+ LOGW("Could not retrieve current multitouch slot index. status=%d", status);
+ mAccumulator.currentSlot = -1;
+ }
+ }
}
void MultiTouchInputMapper::reset() {
@@ -5682,6 +5699,8 @@
}
mAccumulator.allocateSlots(mSlotCount);
+
+ clearState();
}