[HACK] Input: mms114: don't report 0 pressure while still tracking contact(s)

In the middle of a sliding gesture, we manage to have events
that look like that:
    Event: time 1571859641.595517, -------------- SYN_REPORT ------------
    Event: time 1571859641.606593, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 1193
    Event: time 1571859641.606593, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 21
    Event: time 1571859641.606593, type 3 (EV_ABS), code 58 (ABS_MT_PRESSURE), value 0
    Event: time 1571859641.606593, type 3 (EV_ABS), code 1 (ABS_Y), value 1193
    Event: time 1571859641.606593, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 0
    Event: time 1571859641.606593, -------------- SYN_REPORT ------------

In such cases, we still have a valid ABS_MT_TRACKING_ID along
with an ABS_MT_TOUCH_MAJOR that is > 0, which both indicates
that the sliding is still in progress.

However in Documentation/input/multi-touch-protocol.rst, we
have:
    ABS_MT_PRESSURE
        The pressure, in arbitrary units, on the contact
        area. May be used instead of TOUCH and WIDTH for
        pressure-based devices or any device with a spatial
        signal intensity distribution.

Because of that userspace may consider an ABS_MT_PRESSURE
of 0 as an indication that the sliding stopped. This has
side effects such as making it difficult to unlock the
screen under Android.

However while sending this patch upstream, I got the following
explanation by Peter Hutterer :
> libinput uses ABS_MT_PRESSURE with some defaults based on the pressure range
> unless a (libinput) quirk tells it to use the ABS_MT_TOUCH_MAJOR axis
> ranges. git grep for the AttrTouchSizeRange, AttrThumbSizeThreshold and
> AttrPalmSizeThreshold and that'll get you there.
>
> Given the recording, i'm assuming pressure is not reliable on this device so
> you will have to add the quirk.
[...]
> yes, it's up to userspace. there's some documentation in the kernel
> regarding the major/minor axis ranges but not a lot of devices use it that
> way. Hence libinput requiring a quirk for this. Not 100% what other input
> stacks do though.

So ideally this should be fixed in userspace instead. Until that's done,
we need to keep this patch though.

This fix was tested on the following devices:
- GT-I9300 with a glass screen protection
- GT-I9300 without any screen protection
- GT-N7105 with a glass screen protection

Reported-by: Javi Ferrer <javi.f.o@gmail.com>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

1 files changed, 4 insertions, 1 deletions

diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
index 1f96657310b7..1e2c0fe44e5e 100644
--- a/drivers/input/touchscreen/mms114.c
+++ b/drivers/input/touchscreen/mms114.c
@@ -184,7 +184,10 @@ static void mms114_process_mt(struct mms114_data *data, struct mms114_touch *tou
 	if (touch->pressed) {
 		touchscreen_report_pos(input_dev, &data->props, x, y, true);
 		input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, touch->width);
-		input_report_abs(input_dev, ABS_MT_PRESSURE, touch->strength);
+		if (touch->strength) {
+			input_report_abs(input_dev, ABS_MT_PRESSURE,
+					 touch->strength);
+		}
 	}
 }