Ooops. The API said that the pointer down and up actions contained
the pointer id, but it is actually the index. Actually it makes
much more sense for it to be the index, and those ACTION_POINTER_1_DOWN
etc. constants were stupid.
This introduces some hacks in the framework to try to clean up the
data we are getting from the touch screen. There are two main things
being done here:
1. Look for changes in position that are unreasonably large, and
ignore them. This is intended to eliminate the spurious jumps that
often happen when releasing.
2. Add some simple adaptive averaging of the touch data. If the
difference between the last and next point is large enough, we
disable the averaging; otherwise we average up to the last 5 points.
The goal is to get rid of the noise of small movements so that things
like taps don't look like short flings, while still responding quickly
to rapid movement.
For averaging pressure, we also weight each averaged coordinate by
the reported pressure at that point. This is intended to keep the
coordinates closer together during a release, when the pressure is
going down and the accuracy decreasing. It may also result in some
other interesting artifacts, but hopefully nothing problematic.
Change-Id: I1369e9ab015c406946a45c2d72547da9c604178f
This was a problem with not dealing well with how the driver was
reporting data in the old touch protocol.
Also fixed issue with not correctly rotating non-primary touches.
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.
The platform now knows how to deal with a platform key, which at this
point is "just like end call, but don't end a call."
Also improve the handling of virtual keys, to allow for canceling when
sliding off into the display and providing haptic feedback.
Finally fixes a bug where the raw x and y in motion event were not
always set which caused the status bar to not work.
The MotionEvent API should be fairly solid, but there is still a lot of
work to do in the input device code. In particular, right now we are
really stupid about watching how fingers change -- we just take whatever
the driver reports as down and dump that directly into the motion event.
The big remaning work is to assign pointer IDs so that applications have
help in determine which fingers go up and down, and adding support for
the official multi-touch driver protocol.
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.
