Skip to contentSkip to conversation

Patch "HID: multitouch: fix input mode switching on some Elan panels" has been added to the 4.3-stable tree

PATCH [email protected] 1 participant 1 message Feb 15, 2016

Subsystems (2)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

HID: multitouch: fix input mode switching on some Elan panels

to the 4.3-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
hid-multitouch-fix-input-mode-switching-on-some-elan-panels.patch
and it can be found in the queue-4.3 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From 73e7d63efb4d774883a338997943bfa59e127085 Mon Sep 17 00:00:00 2001

From: Benjamin Tissoires <[email protected]>
Date: Tue, 1 Dec 2015 12:41:38 +0100
Subject: HID: multitouch: fix input mode switching on some Elan panels

From: Benjamin Tissoires <[email protected]>

commit 73e7d63efb4d774883a338997943bfa59e127085 upstream.

as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481

This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") as the origin of the problem but this commit actually masked 2 firmware bugs that are annihilating each other:

The report descriptor declares two features in reports 3 and 5:

0x05, 0x0d,                    // Usage Page (Digitizers)             318
0x09, 0x0e,                    // Usage (Device Configuration)        320
0xa1, 0x01,                    // Collection (Application)            322
0x85, 0x03,                    //  Report ID (3)                      324
0x09, 0x22,                    //  Usage (Finger)                     326
0xa1, 0x00,                    //  Collection (Physical)              328
0x09, 0x52,                    //   Usage (Inputmode)                 330
0x15, 0x00,                    //   Logical Minimum (0)               332
0x25, 0x0a,                    //   Logical Maximum (10)              334
0x75, 0x08,                    //   Report Size (8)                   336
0x95, 0x02,                    //   Report Count (2)                  338
0xb1, 0x02,                    //   Feature (Data,Var,Abs)            340
0xc0,                          //  End Collection                     342
0x09, 0x22,                    //  Usage (Finger)                     343
0xa1, 0x00,                    //  Collection (Physical)              345
0x85, 0x05,                    //   Report ID (5)                     347
0x09, 0x57,                    //   Usage (Surface Switch)            349
0x09, 0x58,                    //   Usage (Button Switch)             351
0x15, 0x00,                    //   Logical Minimum (0)               353
0x75, 0x01,                    //   Report Size (1)                   355
0x95, 0x02,                    //   Report Count (2)                  357
0x25, 0x03,                    //   Logical Maximum (3)               359
0xb1, 0x02,                    //   Feature (Data,Var,Abs)            361
0x95, 0x0e,                    //   Report Count (14)                 363
0xb1, 0x03,                    //   Feature (Cnst,Var,Abs)            365
0xc0,                          //  End Collection                     367

The report ID 3 presents 2 input mode features, while only the first one is handled by the device. Given that we did not checked if one was previously assigned, we were dealing with the ignored featured and we should never have been able to switch this panel into the multitouch mode.

However, the firmware presents an other bugs which allowed 6d4f5440 to counteract the faulty report descriptor. When we request the values of the feature 5, the firmware answers "03 03 00". The fields are correct but the report id is wrong. Before 6d4f5440, we retrieved all the features and injected them in the system. So when we called report 5, we injected in the system the report 3 with the values "03 00".
Setting the second input mode to 03 in this report changed it to "03 03" and the touchpad switched to the mt mode. We could have set anything in the second field because the actual value (the first 03 in this report) was given by the query of report ID 5.

To sum up: 2 bugs in the firmware were hiding that we were accessing the wrong feature.

---
 drivers/hid/hid-multitouch.c |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/hid/hid-multitouch.c +13 -2
@@ -357,8 +357,19 @@ static void mt_feature_mapping(struct hi
 			break;
 		}
 
-		td->inputmode = field->report->id;
-		td->inputmode_index = usage->usage_index;
+		if (td->inputmode < 0) {
+			td->inputmode = field->report->id;
+			td->inputmode_index = usage->usage_index;
+		} else {
+			/*
+			 * Some elan panels wrongly declare 2 input mode
+			 * features, and silently ignore when we set the
+			 * value in the second field. Skip the second feature
+			 * and hope for the best.
+			 */
+			dev_info(&hdev->dev,
+				 "Ignoring the extra HID_DG_INPUTMODE\n");
+		}
 
 		break;
 	case HID_DG_CONTACTMAX:

Patches currently in stable-queue which might be from [email protected] are

queue-4.3/hid-multitouch-fix-input-mode-switching-on-some-elan-panels.patch queue-4.3/hid-multitouch-fetch-feature-reports-on-demand-for-win8-devices.patch