Devices which do not use MT_SLOTS protocol can create invalid touch states
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Triaged
|
Medium
|
Unassigned | ||
mir (Ubuntu) |
Triaged
|
Medium
|
Unassigned |
Bug Description
"Certain devices" do not use the MT_SLOTS protocol for their touchscreen. In such cases (and perhaps in particular...when they omit certain 'redundant' tracking ID's) invalid touch states may be produced.
On "such a device" you could run mir_demo_
observe strange movement to 0,0...further investigation, i.e. ANDROID_
The strange movement to 0,0 is caused, when detecting that the pointerCount hasn't changed but an input frame is being processesed, the stack infers it must be processing a motion event but of course there are no coordinates in the current pointer data.
Related branches
Changed in mir: | |
assignee: | nobody → Robert Carr (robertcarr) |
tags: | added: input |
Changed in mir: | |
status: | New → In Progress |
milestone: | none → 0.8.0 |
Changed in mir: | |
milestone: | 0.8.0 → 0.9.0 |
Changed in mir: | |
milestone: | 0.9.0 → 0.10.0 |
Changed in mir: | |
milestone: | 0.10.0 → none |
milestone: | none → 0.11.0 |
Changed in mir: | |
milestone: | 0.11.0 → none |
status: | In Progress → Triaged |
importance: | Undecided → Medium |
Changed in mir: | |
assignee: | Robert Carr (robertcarr) → nobody |
Part of the difficulty in understanding this had been a lack of another device using the Type A multi touch protocol (as opposed to the modern Type B slots protocol). Luckily I found the kernel documentation:
https:/ /www.kernel. org/doc/ Documentation/ input/multi- touch-protocol. txt
You can find the example of the type A protocol (protocol example A). The problem is clear now: Following the input frame in which the driver reports pressure 0, touch_major 0, btn touch up, etc....the driver is required to report an empty frame containing only SYN_MT_REPORT SYN_REPORT. This empty frame indicates that the contacts have really dissapeared, on the other hand pressure 0, etc...only indicates that the contact has become a hover! The whole tracking id business is a mild device quirk which I think ultimately was a red herring. The branch "fix-pointer- assignment- without- mt-slots" seems to fix things for the device in question however it could potentially break devices which actually support hover and have the same quirk of not reporting tracking ID's for the last active touchpoint.
a stroke of luck lead me to: /source. android. com/devices/ tech/input/ touch-devices. html
https:/
>> As of Android Ice Cream Sandwich 4.0, touch screen drivers may need to be changed to comply with the Linux input protocol >>specification.
>>The following changes may be required:
>>When a tool becomes inactive (finger goes "up"), it should stop appearing in subsequent multi-touch sync reports. When all >>tools become inactive (all fingers go "up"), the driver should send an empty sync report packet, such as SYN_MT_REPORT >>followed by SYN_REPORT.
>>Previous versions of Android expected "up" events to be reported by sending a pressure value of 0. The old behavior was >>incompatible with the Linux input protocol specification and is no longer supported.
It seems as if the driver in question has not yet been updated to this new required behavior. Given that updating has been the android suggestion since ICS I suggest we update the driver rather than attempt to work around the behavior in mir.