Mir

Devices which do not use MT_SLOTS protocol can create invalid touch states

Bug #1367490 reported by Robert Carr
6
This bug affects 1 person
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_standalone_input_filter and tap once...

observe strange movement to 0,0...further investigation, i.e. ANDROID_LOG_TAGS=*:v MIR_SERVER_LEGACY_INPUT_REPORT=log would reveal pointerCount becomes frozen at 1.

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.

Tags: input
Changed in mir:
assignee: nobody → Robert Carr (robertcarr)
tags: added: input
Changed in mir:
status: New → In Progress
milestone: none → 0.8.0
Revision history for this message
Robert Carr (robertcarr) wrote :

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:
https://source.android.com/devices/tech/input/touch-devices.html

>> 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.

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
Revision history for this message
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.