* [PATCH v2 06/10] Input: elantech/SMBus - export all capabilities from the PS/2 node
From: Benjamin Tissoires @ 2019-05-21 13:27 UTC (permalink / raw)
To: Dmitry Torokhov, KT Liao, Rob Herring, Aaron Ma, Hans de Goede
Cc: linux-input, linux-kernel, devicetree, Benjamin Tissoires
In-Reply-To: <20190521132712.2818-1-benjamin.tissoires@redhat.com>
The recent touchpads might not have all the information regarding the
characteristics through the I2C port.
On some Lenovo t480s, this results in the touchpad not being detected
as a clickpad, and on the Lenovo P52, this results in a failure while
fetching the resolution through I2C.
We need to imitate the Windows behavior: fetch the data under PS/2, and
limit the querries under I2C.
This patch prepares this by exporting the info from PS/2.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
--
changes in v2:
- updated according to the 2 previous patches
---
drivers/input/mouse/elantech.c | 47 ++++++++++++++++++++++++++++++----
drivers/input/mouse/elantech.h | 2 ++
2 files changed, 44 insertions(+), 5 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 057a3cf01eec..ca10fd97d9d5 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1736,6 +1736,15 @@ static int elantech_query_info(struct psmouse *psmouse,
return -EINVAL;
info->width = info->x_max / (traces - 1);
+
+ /* column number of traces */
+ info->x_traces = traces;
+
+ /* row number of traces */
+ traces = info->capabilities[2];
+ if ((traces >= 2) && (traces <= info->y_max))
+ info->y_traces = traces;
+
break;
}
@@ -1781,17 +1790,45 @@ static int elantech_create_smbus(struct psmouse *psmouse,
struct elantech_device_info *info,
bool leave_breadcrumbs)
{
- const struct property_entry i2c_properties[] = {
- PROPERTY_ENTRY_BOOL("elan,trackpoint"),
- { },
- };
+ struct property_entry i2c_props[11] = {};
struct i2c_board_info smbus_board = {
I2C_BOARD_INFO("elan_i2c", 0x15),
.flags = I2C_CLIENT_HOST_NOTIFY,
};
+ unsigned int idx = 0;
+
+ smbus_board.properties = i2c_props;
+
+ i2c_props[idx++] = PROPERTY_ENTRY_U32("touchscreen-size-x",
+ info->x_max + 1);
+ i2c_props[idx++] = PROPERTY_ENTRY_U32("touchscreen-size-y",
+ info->y_max + 1);
+ i2c_props[idx++] = PROPERTY_ENTRY_U32("touchscreen-min-x",
+ info->x_min);
+ i2c_props[idx++] = PROPERTY_ENTRY_U32("touchscreen-min-y",
+ info->y_min);
+ if (info->x_res)
+ i2c_props[idx++] = PROPERTY_ENTRY_U32("touchscreen-x-mm",
+ (info->x_max + 1) / info->x_res);
+ if (info->y_res)
+ i2c_props[idx++] = PROPERTY_ENTRY_U32("touchscreen-y-mm",
+ (info->y_max + 1) / info->y_res);
if (info->has_trackpoint)
- smbus_board.properties = i2c_properties;
+ i2c_props[idx++] = PROPERTY_ENTRY_BOOL("elan,trackpoint");
+
+ if (info->has_middle_button)
+ i2c_props[idx++] = PROPERTY_ENTRY_BOOL("elan,middle-button");
+
+ if (info->x_traces)
+ i2c_props[idx++] = PROPERTY_ENTRY_U32("elan,x_traces",
+ info->x_traces);
+ if (info->y_traces)
+ i2c_props[idx++] = PROPERTY_ENTRY_U32("elan,y_traces",
+ info->y_traces);
+
+ if (elantech_is_buttonpad(info))
+ i2c_props[idx++] = PROPERTY_ENTRY_BOOL("elan,clickpad");
return psmouse_smbus_init(psmouse, &smbus_board, NULL, 0, false,
leave_breadcrumbs);
diff --git a/drivers/input/mouse/elantech.h b/drivers/input/mouse/elantech.h
index 16174b54ffc3..a7eaa62af6a0 100644
--- a/drivers/input/mouse/elantech.h
+++ b/drivers/input/mouse/elantech.h
@@ -150,6 +150,8 @@ struct elantech_device_info {
unsigned int y_max;
unsigned int x_res;
unsigned int y_res;
+ unsigned int x_traces;
+ unsigned int y_traces;
unsigned int width;
unsigned int bus;
bool paritycheck;
--
2.21.0
^ permalink raw reply related
* [PATCH v2 05/10] Input: elan_i2c - do not query the info if they are provided
From: Benjamin Tissoires @ 2019-05-21 13:27 UTC (permalink / raw)
To: Dmitry Torokhov, KT Liao, Rob Herring, Aaron Ma, Hans de Goede
Cc: linux-input, linux-kernel, devicetree, Benjamin Tissoires
In-Reply-To: <20190521132712.2818-1-benjamin.tissoires@redhat.com>
See the previous patch for a long explanation.
TL;DR: the P52 and the t480s from Lenovo can't rely on I2C to fetch
the information, so we need it from PS/2.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
--
changes in v2:
- updated accroding to previous patch
---
drivers/input/mouse/elan_i2c_core.c | 56 ++++++++++++++++++++++-------
1 file changed, 44 insertions(+), 12 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index f9525d6f0bfe..53cac610ba33 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -366,27 +366,59 @@ static unsigned int elan_convert_resolution(u8 val)
static int elan_query_device_parameters(struct elan_tp_data *data)
{
+ struct i2c_client *client = data->client;
unsigned int x_traces, y_traces;
+ u32 x_mm, y_mm;
u8 hw_x_res, hw_y_res;
int error;
- error = data->ops->get_max(data->client, &data->max_x, &data->max_y);
- if (error)
- return error;
-
- error = data->ops->get_num_traces(data->client, &x_traces, &y_traces);
- if (error)
- return error;
+ if (device_property_read_u32(&client->dev,
+ "touchscreen-size-x", &data->max_x) ||
+ device_property_read_u32(&client->dev,
+ "touchscreen-size-y", &data->max_y)) {
+ error = data->ops->get_max(data->client,
+ &data->max_x,
+ &data->max_y);
+ if (error)
+ return error;
+ } else {
+ /* size is the maximum + 1 */
+ --data->max_x;
+ --data->max_y;
+ }
+ if (device_property_read_u32(&client->dev,
+ "elan,x_traces",
+ &x_traces) ||
+ device_property_read_u32(&client->dev,
+ "elan,y_traces",
+ &y_traces)) {
+ error = data->ops->get_num_traces(data->client,
+ &x_traces, &y_traces);
+ if (error)
+ return error;
+ }
data->width_x = data->max_x / x_traces;
data->width_y = data->max_y / y_traces;
- error = data->ops->get_resolution(data->client, &hw_x_res, &hw_y_res);
- if (error)
- return error;
+ if (device_property_read_u32(&client->dev,
+ "touchscreen-x-mm", &x_mm) ||
+ device_property_read_u32(&client->dev,
+ "touchscreen-y-mm", &y_mm)) {
+ error = data->ops->get_resolution(data->client,
+ &hw_x_res, &hw_y_res);
+ if (error)
+ return error;
+
+ data->x_res = elan_convert_resolution(hw_x_res);
+ data->y_res = elan_convert_resolution(hw_y_res);
+ } else {
+ data->x_res = (data->max_x + 1) / x_mm;
+ data->y_res = (data->max_y + 1) / y_mm;
+ }
- data->x_res = elan_convert_resolution(hw_x_res);
- data->y_res = elan_convert_resolution(hw_y_res);
+ if (device_property_read_bool(&client->dev, "elan,clickpad"))
+ data->clickpad = 1;
return 0;
}
--
2.21.0
^ permalink raw reply related
* [PATCH v2 04/10] dt-bindings: add more optional properties for elan_i2c touchpads
From: Benjamin Tissoires @ 2019-05-21 13:27 UTC (permalink / raw)
To: Dmitry Torokhov, KT Liao, Rob Herring, Aaron Ma, Hans de Goede
Cc: linux-input, linux-kernel, devicetree, Benjamin Tissoires
In-Reply-To: <20190521132712.2818-1-benjamin.tissoires@redhat.com>
Some new touchpads IC are connected through PS/2 and I2C. On some of these
new IC, the I2C part doesn't have all of the information available.
We need to be able to forward the touchpad parameters from PS/2 and
thus, we need those new optional properties.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
--
changes in v2:
- Use of generic touchscreen properties for min/max and resolutions
- add elan,middle-button
- add elan,*_traces
---
Documentation/devicetree/bindings/input/elan_i2c.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/elan_i2c.txt b/Documentation/devicetree/bindings/input/elan_i2c.txt
index 797607460735..9963247706f2 100644
--- a/Documentation/devicetree/bindings/input/elan_i2c.txt
+++ b/Documentation/devicetree/bindings/input/elan_i2c.txt
@@ -13,9 +13,20 @@ Optional properties:
pinctrl binding [1]).
- vcc-supply: a phandle for the regulator supplying 3.3V power.
- elan,trackpoint: touchpad can support a trackpoint (boolean)
+- elan,clickpad: touchpad is a clickpad (the entire surface is a button)
+- elan,middle-button: touchpad has a physical middle button
+- elan,x_traces: number of antennas on the x axis
+- elan,y_traces: number of antennas on the y axis
+- some generic touchscreen properties [2]:
+ * touchscreen-size-x
+ * touchscreen-size-y
+ * touchscreen-x-mm
+ * touchscreen-y-mm
+
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Example:
&i2c1 {
--
2.21.0
^ permalink raw reply related
* [PATCH v2 03/10] Input: elantech - detect middle button based on firmware version
From: Benjamin Tissoires @ 2019-05-21 13:27 UTC (permalink / raw)
To: Dmitry Torokhov, KT Liao, Rob Herring, Aaron Ma, Hans de Goede
Cc: linux-input, linux-kernel, devicetree, Benjamin Tissoires
In-Reply-To: <20190521132712.2818-1-benjamin.tissoires@redhat.com>
Looks like the new generation of Lenovo machine also need to
be added to the PnPID whitelist. This is definitively not going
to scale, as there is nothing that tells us currently if a
touchpad supports a true physical middle button.
Consider that all new touchpads that are not clickpads
(so matching ETP_NEW_IC_SMBUS_HOST_NOTIFY) are handling 3 physical
buttons.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
--
new in v2
---
drivers/input/mouse/elantech.c | 16 ++++++----------
drivers/input/mouse/elantech.h | 1 +
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 34b96b96fc96..057a3cf01eec 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1107,14 +1107,6 @@ static const struct dmi_system_id elantech_dmi_has_middle_button[] = {
{ }
};
-static const char * const middle_button_pnp_ids[] = {
- "LEN2131", /* ThinkPad P52 w/ NFC */
- "LEN2132", /* ThinkPad P52 */
- "LEN2133", /* ThinkPad P72 w/ NFC */
- "LEN2134", /* ThinkPad P72 */
- NULL
-};
-
/*
* Set the appropriate event bits for the input subsystem
*/
@@ -1133,8 +1125,7 @@ static int elantech_set_input_params(struct psmouse *psmouse)
__clear_bit(EV_REL, dev->evbit);
__set_bit(BTN_LEFT, dev->keybit);
- if (dmi_check_system(elantech_dmi_has_middle_button) ||
- psmouse_matches_pnp_id(psmouse, middle_button_pnp_ids))
+ if (info->has_middle_button)
__set_bit(BTN_MIDDLE, dev->keybit);
__set_bit(BTN_RIGHT, dev->keybit);
@@ -1748,6 +1739,11 @@ static int elantech_query_info(struct psmouse *psmouse,
break;
}
+ /* check for the middle button: DMI matching or new v4 firmwares */
+ info->has_middle_button = dmi_check_system(elantech_dmi_has_middle_button) ||
+ (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version) &&
+ !elantech_is_buttonpad(info));
+
return 0;
}
diff --git a/drivers/input/mouse/elantech.h b/drivers/input/mouse/elantech.h
index 194503ed59c5..16174b54ffc3 100644
--- a/drivers/input/mouse/elantech.h
+++ b/drivers/input/mouse/elantech.h
@@ -158,6 +158,7 @@ struct elantech_device_info {
bool crc_enabled;
bool set_hw_resolution;
bool has_trackpoint;
+ bool has_middle_button;
int (*send_cmd)(struct psmouse *psmouse, unsigned char c,
unsigned char *param);
};
--
2.21.0
^ permalink raw reply related
* [PATCH v2 02/10] Input: elantech - add helper function elantech_is_buttonpad()
From: Benjamin Tissoires @ 2019-05-21 13:27 UTC (permalink / raw)
To: Dmitry Torokhov, KT Liao, Rob Herring, Aaron Ma, Hans de Goede
Cc: linux-input, linux-kernel, devicetree, Benjamin Tissoires
In-Reply-To: <20190521132712.2818-1-benjamin.tissoires@redhat.com>
We check for this bit all over the code, better have it defined once
for all.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
--
changes in v2:
- updated with latest upstream
---
drivers/input/mouse/elantech.c | 93 ++++++++++++++++++----------------
1 file changed, 49 insertions(+), 44 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 5953c21774d7..34b96b96fc96 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -229,6 +229,52 @@ static void elantech_packet_dump(struct psmouse *psmouse)
psmouse->pktsize, psmouse->packet);
}
+/*
+ * Advertise INPUT_PROP_BUTTONPAD for clickpads. The testing of bit 12 in
+ * fw_version for this is based on the following fw_version & caps table:
+ *
+ * Laptop-model: fw_version: caps: buttons:
+ * Acer S3 0x461f00 10, 13, 0e clickpad
+ * Acer S7-392 0x581f01 50, 17, 0d clickpad
+ * Acer V5-131 0x461f02 01, 16, 0c clickpad
+ * Acer V5-551 0x461f00 ? clickpad
+ * Asus K53SV 0x450f01 78, 15, 0c 2 hw buttons
+ * Asus G46VW 0x460f02 00, 18, 0c 2 hw buttons
+ * Asus G750JX 0x360f00 00, 16, 0c 2 hw buttons
+ * Asus TP500LN 0x381f17 10, 14, 0e clickpad
+ * Asus X750JN 0x381f17 10, 14, 0e clickpad
+ * Asus UX31 0x361f00 20, 15, 0e clickpad
+ * Asus UX32VD 0x361f02 00, 15, 0e clickpad
+ * Avatar AVIU-145A2 0x361f00 ? clickpad
+ * Fujitsu CELSIUS H760 0x570f02 40, 14, 0c 3 hw buttons (**)
+ * Fujitsu CELSIUS H780 0x5d0f02 41, 16, 0d 3 hw buttons (**)
+ * Fujitsu LIFEBOOK E544 0x470f00 d0, 12, 09 2 hw buttons
+ * Fujitsu LIFEBOOK E546 0x470f00 50, 12, 09 2 hw buttons
+ * Fujitsu LIFEBOOK E547 0x470f00 50, 12, 09 2 hw buttons
+ * Fujitsu LIFEBOOK E554 0x570f01 40, 14, 0c 2 hw buttons
+ * Fujitsu LIFEBOOK E557 0x570f01 40, 14, 0c 2 hw buttons
+ * Fujitsu T725 0x470f01 05, 12, 09 2 hw buttons
+ * Fujitsu H730 0x570f00 c0, 14, 0c 3 hw buttons (**)
+ * Gigabyte U2442 0x450f01 58, 17, 0c 2 hw buttons
+ * Lenovo L430 0x350f02 b9, 15, 0c 2 hw buttons (*)
+ * Lenovo L530 0x350f02 b9, 15, 0c 2 hw buttons (*)
+ * Samsung NF210 0x150b00 78, 14, 0a 2 hw buttons
+ * Samsung NP770Z5E 0x575f01 10, 15, 0f clickpad
+ * Samsung NP700Z5B 0x361f06 21, 15, 0f clickpad
+ * Samsung NP900X3E-A02 0x575f03 ? clickpad
+ * Samsung NP-QX410 0x851b00 19, 14, 0c clickpad
+ * Samsung RC512 0x450f00 08, 15, 0c 2 hw buttons
+ * Samsung RF710 0x450f00 ? 2 hw buttons
+ * System76 Pangolin 0x250f01 ? 2 hw buttons
+ * (*) + 3 trackpoint buttons
+ * (**) + 0 trackpoint buttons
+ * Note: Lenovo L430 and Lenovo L530 have the same fw_version/caps
+ */
+static inline int elantech_is_buttonpad(struct elantech_device_info *info)
+{
+ return info->fw_version & 0x001000;
+}
+
/*
* Interpret complete data packets and report absolute mode input events for
* hardware version 1. (4 byte packets)
@@ -526,7 +572,7 @@ static void elantech_report_absolute_v3(struct psmouse *psmouse,
input_report_key(dev, BTN_TOOL_TRIPLETAP, fingers == 3);
/* For clickpads map both buttons to BTN_LEFT */
- if (etd->info.fw_version & 0x001000)
+ if (elantech_is_buttonpad(&etd->info))
input_report_key(dev, BTN_LEFT, packet[0] & 0x03);
else
psmouse_report_standard_buttons(dev, packet[0]);
@@ -544,7 +590,7 @@ static void elantech_input_sync_v4(struct psmouse *psmouse)
unsigned char *packet = psmouse->packet;
/* For clickpads map both buttons to BTN_LEFT */
- if (etd->info.fw_version & 0x001000)
+ if (elantech_is_buttonpad(&etd->info))
input_report_key(dev, BTN_LEFT, packet[0] & 0x03);
else
psmouse_report_standard_buttons(dev, packet[0]);
@@ -1020,53 +1066,12 @@ static int elantech_get_resolution_v4(struct psmouse *psmouse,
return 0;
}
-/*
- * Advertise INPUT_PROP_BUTTONPAD for clickpads. The testing of bit 12 in
- * fw_version for this is based on the following fw_version & caps table:
- *
- * Laptop-model: fw_version: caps: buttons:
- * Acer S3 0x461f00 10, 13, 0e clickpad
- * Acer S7-392 0x581f01 50, 17, 0d clickpad
- * Acer V5-131 0x461f02 01, 16, 0c clickpad
- * Acer V5-551 0x461f00 ? clickpad
- * Asus K53SV 0x450f01 78, 15, 0c 2 hw buttons
- * Asus G46VW 0x460f02 00, 18, 0c 2 hw buttons
- * Asus G750JX 0x360f00 00, 16, 0c 2 hw buttons
- * Asus TP500LN 0x381f17 10, 14, 0e clickpad
- * Asus X750JN 0x381f17 10, 14, 0e clickpad
- * Asus UX31 0x361f00 20, 15, 0e clickpad
- * Asus UX32VD 0x361f02 00, 15, 0e clickpad
- * Avatar AVIU-145A2 0x361f00 ? clickpad
- * Fujitsu CELSIUS H760 0x570f02 40, 14, 0c 3 hw buttons (**)
- * Fujitsu CELSIUS H780 0x5d0f02 41, 16, 0d 3 hw buttons (**)
- * Fujitsu LIFEBOOK E544 0x470f00 d0, 12, 09 2 hw buttons
- * Fujitsu LIFEBOOK E546 0x470f00 50, 12, 09 2 hw buttons
- * Fujitsu LIFEBOOK E547 0x470f00 50, 12, 09 2 hw buttons
- * Fujitsu LIFEBOOK E554 0x570f01 40, 14, 0c 2 hw buttons
- * Fujitsu LIFEBOOK E557 0x570f01 40, 14, 0c 2 hw buttons
- * Fujitsu T725 0x470f01 05, 12, 09 2 hw buttons
- * Fujitsu H730 0x570f00 c0, 14, 0c 3 hw buttons (**)
- * Gigabyte U2442 0x450f01 58, 17, 0c 2 hw buttons
- * Lenovo L430 0x350f02 b9, 15, 0c 2 hw buttons (*)
- * Lenovo L530 0x350f02 b9, 15, 0c 2 hw buttons (*)
- * Samsung NF210 0x150b00 78, 14, 0a 2 hw buttons
- * Samsung NP770Z5E 0x575f01 10, 15, 0f clickpad
- * Samsung NP700Z5B 0x361f06 21, 15, 0f clickpad
- * Samsung NP900X3E-A02 0x575f03 ? clickpad
- * Samsung NP-QX410 0x851b00 19, 14, 0c clickpad
- * Samsung RC512 0x450f00 08, 15, 0c 2 hw buttons
- * Samsung RF710 0x450f00 ? 2 hw buttons
- * System76 Pangolin 0x250f01 ? 2 hw buttons
- * (*) + 3 trackpoint buttons
- * (**) + 0 trackpoint buttons
- * Note: Lenovo L430 and Lenovo L530 have the same fw_version/caps
- */
static void elantech_set_buttonpad_prop(struct psmouse *psmouse)
{
struct input_dev *dev = psmouse->dev;
struct elantech_data *etd = psmouse->private;
- if (etd->info.fw_version & 0x001000) {
+ if (elantech_is_buttonpad(&etd->info)) {
__set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
__clear_bit(BTN_RIGHT, dev->keybit);
}
--
2.21.0
^ permalink raw reply related
* [PATCH v2 01/10] Input: elantech - query the min/max information beforehand too
From: Benjamin Tissoires @ 2019-05-21 13:27 UTC (permalink / raw)
To: Dmitry Torokhov, KT Liao, Rob Herring, Aaron Ma, Hans de Goede
Cc: linux-input, linux-kernel, devicetree, Benjamin Tissoires
In-Reply-To: <20190521132712.2818-1-benjamin.tissoires@redhat.com>
For the latest generation of Elantech touchpads, we need to forward
the min/max information from PS/2 to SMBus. Prepare this work
by fetching the information before creating the SMBus companion
device.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
--
no changes in v2
---
drivers/input/mouse/elantech.c | 160 +++++++++++++++------------------
drivers/input/mouse/elantech.h | 5 ++
2 files changed, 79 insertions(+), 86 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index a7f8b1614559..5953c21774d7 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -994,88 +994,6 @@ static int elantech_set_absolute_mode(struct psmouse *psmouse)
return rc;
}
-static int elantech_set_range(struct psmouse *psmouse,
- unsigned int *x_min, unsigned int *y_min,
- unsigned int *x_max, unsigned int *y_max,
- unsigned int *width)
-{
- struct elantech_data *etd = psmouse->private;
- struct elantech_device_info *info = &etd->info;
- unsigned char param[3];
- unsigned char traces;
-
- switch (info->hw_version) {
- case 1:
- *x_min = ETP_XMIN_V1;
- *y_min = ETP_YMIN_V1;
- *x_max = ETP_XMAX_V1;
- *y_max = ETP_YMAX_V1;
- break;
-
- case 2:
- if (info->fw_version == 0x020800 ||
- info->fw_version == 0x020b00 ||
- info->fw_version == 0x020030) {
- *x_min = ETP_XMIN_V2;
- *y_min = ETP_YMIN_V2;
- *x_max = ETP_XMAX_V2;
- *y_max = ETP_YMAX_V2;
- } else {
- int i;
- int fixed_dpi;
-
- i = (info->fw_version > 0x020800 &&
- info->fw_version < 0x020900) ? 1 : 2;
-
- if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
- return -1;
-
- fixed_dpi = param[1] & 0x10;
-
- if (((info->fw_version >> 16) == 0x14) && fixed_dpi) {
- if (info->send_cmd(psmouse, ETP_SAMPLE_QUERY, param))
- return -1;
-
- *x_max = (info->capabilities[1] - i) * param[1] / 2;
- *y_max = (info->capabilities[2] - i) * param[2] / 2;
- } else if (info->fw_version == 0x040216) {
- *x_max = 819;
- *y_max = 405;
- } else if (info->fw_version == 0x040219 || info->fw_version == 0x040215) {
- *x_max = 900;
- *y_max = 500;
- } else {
- *x_max = (info->capabilities[1] - i) * 64;
- *y_max = (info->capabilities[2] - i) * 64;
- }
- }
- break;
-
- case 3:
- if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
- return -1;
-
- *x_max = (0x0f & param[0]) << 8 | param[1];
- *y_max = (0xf0 & param[0]) << 4 | param[2];
- break;
-
- case 4:
- if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
- return -1;
-
- *x_max = (0x0f & param[0]) << 8 | param[1];
- *y_max = (0xf0 & param[0]) << 4 | param[2];
- traces = info->capabilities[1];
- if ((traces < 2) || (traces > *x_max))
- return -1;
-
- *width = *x_max / (traces - 1);
- break;
- }
-
- return 0;
-}
-
/*
* (value from firmware) * 10 + 790 = dpi
* we also have to convert dpi to dots/mm (*10/254 to avoid floating point)
@@ -1200,10 +1118,9 @@ static int elantech_set_input_params(struct psmouse *psmouse)
struct input_dev *dev = psmouse->dev;
struct elantech_data *etd = psmouse->private;
struct elantech_device_info *info = &etd->info;
- unsigned int x_min = 0, y_min = 0, x_max = 0, y_max = 0, width = 0;
-
- if (elantech_set_range(psmouse, &x_min, &y_min, &x_max, &y_max, &width))
- return -1;
+ unsigned int x_min = info->x_min, y_min = info->y_min,
+ x_max = info->x_max, y_max = info->y_max,
+ width = info->width;
__set_bit(INPUT_PROP_POINTER, dev->propbit);
__set_bit(EV_KEY, dev->evbit);
@@ -1687,6 +1604,7 @@ static int elantech_query_info(struct psmouse *psmouse,
struct elantech_device_info *info)
{
unsigned char param[3];
+ unsigned char traces;
memset(info, 0, sizeof(*info));
@@ -1755,6 +1673,76 @@ static int elantech_query_info(struct psmouse *psmouse,
}
}
+ /* query range information */
+ switch (info->hw_version) {
+ case 1:
+ info->x_min = ETP_XMIN_V1;
+ info->y_min = ETP_YMIN_V1;
+ info->x_max = ETP_XMAX_V1;
+ info->y_max = ETP_YMAX_V1;
+ break;
+
+ case 2:
+ if (info->fw_version == 0x020800 ||
+ info->fw_version == 0x020b00 ||
+ info->fw_version == 0x020030) {
+ info->x_min = ETP_XMIN_V2;
+ info->y_min = ETP_YMIN_V2;
+ info->x_max = ETP_XMAX_V2;
+ info->y_max = ETP_YMAX_V2;
+ } else {
+ int i;
+ int fixed_dpi;
+
+ i = (info->fw_version > 0x020800 &&
+ info->fw_version < 0x020900) ? 1 : 2;
+
+ if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
+ return -EINVAL;
+
+ fixed_dpi = param[1] & 0x10;
+
+ if (((info->fw_version >> 16) == 0x14) && fixed_dpi) {
+ if (info->send_cmd(psmouse, ETP_SAMPLE_QUERY, param))
+ return -EINVAL;
+
+ info->x_max = (info->capabilities[1] - i) * param[1] / 2;
+ info->y_max = (info->capabilities[2] - i) * param[2] / 2;
+ } else if (info->fw_version == 0x040216) {
+ info->x_max = 819;
+ info->y_max = 405;
+ } else if (info->fw_version == 0x040219 || info->fw_version == 0x040215) {
+ info->x_max = 900;
+ info->y_max = 500;
+ } else {
+ info->x_max = (info->capabilities[1] - i) * 64;
+ info->y_max = (info->capabilities[2] - i) * 64;
+ }
+ }
+ break;
+
+ case 3:
+ if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
+ return -EINVAL;
+
+ info->x_max = (0x0f & param[0]) << 8 | param[1];
+ info->y_max = (0xf0 & param[0]) << 4 | param[2];
+ break;
+
+ case 4:
+ if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
+ return -EINVAL;
+
+ info->x_max = (0x0f & param[0]) << 8 | param[1];
+ info->y_max = (0xf0 & param[0]) << 4 | param[2];
+ traces = info->capabilities[1];
+ if ((traces < 2) || (traces > info->x_max))
+ return -EINVAL;
+
+ info->width = info->x_max / (traces - 1);
+ break;
+ }
+
return 0;
}
diff --git a/drivers/input/mouse/elantech.h b/drivers/input/mouse/elantech.h
index 119727085a60..194503ed59c5 100644
--- a/drivers/input/mouse/elantech.h
+++ b/drivers/input/mouse/elantech.h
@@ -144,8 +144,13 @@ struct elantech_device_info {
unsigned char debug;
unsigned char hw_version;
unsigned int fw_version;
+ unsigned int x_min;
+ unsigned int y_min;
+ unsigned int x_max;
+ unsigned int y_max;
unsigned int x_res;
unsigned int y_res;
+ unsigned int width;
unsigned int bus;
bool paritycheck;
bool jumpy_cursor;
--
2.21.0
^ permalink raw reply related
* [PATCH v2 00/10] Fix Elan I2C touchpads in latest generation from Lenovo
From: Benjamin Tissoires @ 2019-05-21 13:27 UTC (permalink / raw)
To: Dmitry Torokhov, KT Liao, Rob Herring, Aaron Ma, Hans de Goede
Cc: linux-input, linux-kernel, devicetree, Benjamin Tissoires
Hi,
This is the v2 from https://lkml.org/lkml/2018/10/12/633
So I initially thought it would be easy to integrate the suggested changes
in the v1, but it turns our that the changes to have the touchscreen-width
and height parameters were quite hard to do.
I finally postponed the issue by blacklisting the 2 laptops we knew were
not working and tried to devote more time to understand both drivers more.
But it s the time where Lenovo is preparing the new models, and guess what,
they suffer from the same symptoms.
So I took a few time to work on this and finally got my head around the
width and height problem. Once I got it, it was simple clear, but this also
means we can not really rely on a device tree property for that.
So in the elan* drivers, the "traces" are simply how many antennas there
are on each axis. Which means that if a trace of 4 is reported in the
events, it means it is simply seen by 4 antennas. So the computation of the
width/height is the following: we take how many antennas there are, we
subtract one to have the number of holes between the antennas, and we
divide the number of unit we have in the axis by the value we just
computed.
This gives a rough 4mm on the P52, in both directions.
And once you get that, you can just realize that the unit of the width and
height are just the same than the X and Y coordinates, so we can apply the
same resolution.
So, in the end, that means that elan_i2c needs the information, or it will
not be able to convert the number of crossed antennas into a size, but this
is something specific to this touchpad.
So here come, 7 months later the v2 on the subject.
Cheers,
Benjamin
Benjamin Tissoires (10):
Input: elantech - query the min/max information beforehand too
Input: elantech - add helper function elantech_is_buttonpad()
Input: elantech - detect middle button based on firmware version
dt-bindings: add more optional properties for elan_i2c touchpads
Input: elan_i2c - do not query the info if they are provided
Input: elantech/SMBus - export all capabilities from the PS/2 node
Input: elan_i2c - handle physical middle button
Input: elan_i2c - export true width/height
Input: elan_i2c - correct the width/size base value
Input: elantech: remove P52 from SMBus blacklist
.../devicetree/bindings/input/elan_i2c.txt | 11 +
drivers/input/mouse/elan_i2c_core.c | 85 +++--
drivers/input/mouse/elantech.c | 318 ++++++++++--------
drivers/input/mouse/elantech.h | 8 +
4 files changed, 251 insertions(+), 171 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Pali Rohár @ 2019-05-21 9:46 UTC (permalink / raw)
To: Hui Wang
Cc: Xiaoxiao Liu, XiaoXiao Liu, dmitry.torokhov@gmail.com,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <345b62e1-407e-7a03-9b03-486bbf5a0a8e@canonical.com>
Hello!
On Tuesday 21 May 2019 10:26:47 Hui Wang wrote:
> Tested-by: Hui Wang <hui.wang@canonical.com>
>
> On 2019/5/21 上午9:07, Xiaoxiao Liu wrote:
> > Add Pali Rohár.
> >
> > -----邮件原件-----
> > 发件人: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
> > 发送时间: Monday, May 20, 2019 7:02 PM
> > 收件人: dmitry.torokhov@gmail.com
> > 抄送: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; hui.wang@canonical.com; 曹 曉建 Xiaojian Cao <xiaojian.cao@cn.alps.com>; zhangfp1@lenovo.com; 劉 曉曉 Xiaoxiao Liu <xiaoxiao.liu-1@cn.alps.com>; XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
> > 主题: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
> >
> > when the alps trackpoint is detected and using the alps_v8_protocol_data procotol,
> > the alps driver will not report the input data.
Why it does not report input data?
> > solution: use standard mouse driver instead of alps driver when the specail trackpoint was detected.
This looks like an (undocumented) hack or workaround. Not a solution.
> > Signed-off-by: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
> > ---
> > drivers/input/mouse/alps.c | 23 ++++++++++++++++++++++-
> > 1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c index 0a6f7ca883e7..516ae1d0eb17 100644
> > --- a/drivers/input/mouse/alps.c
> > +++ b/drivers/input/mouse/alps.c
> > @@ -24,7 +24,7 @@
> > #include "psmouse.h"
> > #include "alps.h"
> > -
> > +#include "trackpoint.h"
> > /*
> > * Definitions for ALPS version 3 and 4 command mode protocol
> > */
> > @@ -2864,6 +2864,22 @@ static const struct alps_protocol_info *alps_match_table(unsigned char *e7,
> > return NULL;
> > }
> > +int alps_check_is_trackpoint(struct psmouse *psmouse) {
> > + u8 param[2] = { 0 };
> > + int error;
> > +
> > + error = ps2_command(&psmouse->ps2dev,
> > + param, MAKE_PS2_CMD(0, 2, TP_READ_ID));
> > + if (error)
> > + return error;
> > +
> > + if (param[0] == TP_VARIANT_ALPS)
> > + return 0;
> > + psmouse_warn(psmouse, "It is not alps trackpoint.\n");
> > + return -ENODEV;
> > +}
So, this function returns 0 when detected ALPS trackpoint and -ENODEV
when not.
> > +
> > static int alps_identify(struct psmouse *psmouse, struct alps_data *priv) {
> > const struct alps_protocol_info *protocol; @@ -2912,6 +2928,11 @@ static int alps_identify(struct psmouse *psmouse, struct alps_data *priv)
> > protocol = &alps_v3_protocol_data;
> > } else if (e7[0] == 0x73 && e7[1] == 0x03 &&
> > (e7[2] == 0x14 || e7[2] == 0x28)) {
> > + if (alps_check_is_trackpoint(psmouse) == 0) {
> > + psmouse_warn(psmouse,
> > + "It is alps trackpoint, use the standard mouse driver.\n");
> > + return -EINVAL;
And here I'm lost. If we have *not* detected ALPS trackpoint then if
block is not called which means that ALPS driver is used.
So why is for non-ALPS trackpoints used ALPS driver? This does not seem
like a correct...
And when we have detected ALPS trackpoint (return value 0) then standard
mouse driver is used and returned -EINVAL. This seems strange too.
So either this code is wrong or there are missing more details for
explaining this strange logic. But still this looks like a hack not a
proper fix/solution.
> > + }
> > protocol = &alps_v8_protocol_data;
> > } else if (e7[0] == 0x73 && e7[1] == 0x03 && e7[2] == 0xc8) {
> > protocol = &alps_v9_protocol_data;
> > --
> > 2.20.1
> >
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [PATCH RESEND] input: adp5589: Add gpio_set_multiple interface
From: Bogdan Togorean @ 2019-05-21 8:38 UTC (permalink / raw)
To: linux-input
Cc: dmitry.torokhov, gustavo, linux-kernel, Michael.Hennerich,
Bogdan Togorean
In-Reply-To: <20190415122525.2576-1-bogdan.togorean@analog.com>
This patch implements the gpio_set_multiple interface for ADP558x chip.
Signed-off-by: Bogdan Togorean <bogdan.togorean@analog.com>
---
drivers/input/keyboard/adp5589-keys.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/input/keyboard/adp5589-keys.c b/drivers/input/keyboard/adp5589-keys.c
index 2835fba71c33..143871bd60ef 100644
--- a/drivers/input/keyboard/adp5589-keys.c
+++ b/drivers/input/keyboard/adp5589-keys.c
@@ -416,6 +416,30 @@ static void adp5589_gpio_set_value(struct gpio_chip *chip,
mutex_unlock(&kpad->gpio_lock);
}
+static void adp5589_gpio_set_multiple(struct gpio_chip *chip,
+ unsigned long *mask, unsigned long *bits)
+{
+ struct adp5589_kpad *kpad = container_of(chip, struct adp5589_kpad, gc);
+ u8 bank, reg_mask, reg_bits;
+
+ mutex_lock(&kpad->gpio_lock);
+
+ for (bank = 0; bank <= kpad->var->bank(kpad->var->maxgpio); bank++) {
+ if (bank > kpad->var->bank(get_bitmask_order(*mask) - 1))
+ break;
+ reg_mask = mask[bank / sizeof(*mask)] >>
+ ((bank % sizeof(*mask)) * BITS_PER_BYTE);
+ reg_bits = bits[bank / sizeof(*bits)] >>
+ ((bank % sizeof(*bits)) * BITS_PER_BYTE);
+ kpad->dat_out[bank] &= ~reg_mask;
+ kpad->dat_out[bank] |= reg_bits & reg_mask;
+ adp5589_write(kpad->client, kpad->var->reg(ADP5589_GPO_DATA_OUT_A) + bank,
+ kpad->dat_out[bank]);
+ }
+
+ mutex_unlock(&kpad->gpio_lock);
+}
+
static int adp5589_gpio_direction_input(struct gpio_chip *chip, unsigned off)
{
struct adp5589_kpad *kpad = gpiochip_get_data(chip);
@@ -517,6 +541,7 @@ static int adp5589_gpio_add(struct adp5589_kpad *kpad)
kpad->gc.direction_output = adp5589_gpio_direction_output;
kpad->gc.get = adp5589_gpio_get_value;
kpad->gc.set = adp5589_gpio_set_value;
+ kpad->gc.set_multiple = adp5589_gpio_set_multiple;
kpad->gc.can_sleep = 1;
kpad->gc.base = gpio_data->gpio_start;
--
2.21.0
^ permalink raw reply related
* Re: [RFC PATCH v2 0/4] Input: mpr121-polled: Add polled driver for MPR121
From: Michal Vokáč @ 2019-05-21 6:51 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-input, devicetree, linux-kernel, Pengutronix Kernel Team
In-Reply-To: <20190521053705.GI183429@dtor-ws>
On 21. 05. 19 7:37, Dmitry Torokhov wrote:
> Hi Michal,
>
> On Fri, May 17, 2019 at 03:12:49PM +0200, Michal Vokáč wrote:
>> Hi,
>>
>> I have to deal with a situation where we have a custom i.MX6 based
>> platform in production that uses the MPR121 touchkey controller.
>> Unfortunately the chip is connected using only the I2C interface.
>> The interrupt line is not used. Back in 2015 (Linux v3.14), my
>> colleague modded the existing mpr121_touchkey.c driver to use polling
>> instead of interrupt.
>>
>> For quite some time yet I am in a process of updating the product from
>> the ancient Freescale v3.14 kernel to the latest mainline and pushing
>> any needed changes upstream. The DT files for our imx6dl-yapp4 platform
>> already made it into v5.1-rc.
>>
>> I rebased and updated our mpr121 patch to the latest mainline.
>> It is created as a separate driver, similarly to gpio_keys_polled.
>>
>> The I2C device is quite susceptible to ESD. An ESD test quite often
>> causes reset of the chip or some register randomly changes its value.
>> The [PATCH 3/4] adds a write-through register cache. With the cache
>> this state can be detected and the device can be re-initialied.
>>
>> The main question is: Is there any chance that such a polled driver
>> could be accepted? Is it correct to implement it as a separate driver
>> or should it be done as an option in the existing driver? I can not
>> really imagine how I would do that though..
>>
>> There are also certain worries that the MPR121 chip may no longer be
>> available in nonspecifically distant future. In case of EOL I will need
>> to add a polled driver for an other touchkey chip. May it be already
>> in mainline or a completely new one.
>
> I think that my addition of input_polled_dev was ultimately a wrong
> thing to do. I am looking into enabling polling mode for regular input
> devices as we then can enable polling mode in existing drivers.
OK, that sounds good. Especially when one needs to switch from one chip
to another that is already in tree, the need for a whole new polling
driver is eliminated.
I am still quite a novice in all kernel areas as I literally jump from
one subsystem to another to fix issues related to our platform. Anyway,
do you see any opportunity to help with that work?
> As far as gpio-keys vs gpio-key-polled, I feel that the capabilities of
> polling driver is sufficiently different from interrupt-driven one, so
> we will likely keep them separate.
OK, understand.
Thank you,
Michal
^ permalink raw reply
* Re: [PATCH 2/2] Input: synaptics - remove X240 from the topbuttonpad list
From: Benjamin Tissoires @ 2019-05-21 6:49 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Aaron Ma, open list:HID CORE LAYER, lkml, Christopher Heiny,
Andrew Duggan, Hans de Goede
In-Reply-To: <20190521050850.GC183429@dtor-ws>
On Tue, May 21, 2019 at 7:09 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Aaron,
>
> On Sun, May 19, 2019 at 03:27:11PM +0800, Aaron Ma wrote:
> > Lenovo ThinkPad X240 does not have the top software button.
> > When this wrong ID in top button list, smbus mode will fail to probe,
> > so keep it working at PS2 mode.
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
> > ---
> > drivers/input/mouse/synaptics.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> > index b6da0c1267e3..6ae7bc92476b 100644
> > --- a/drivers/input/mouse/synaptics.c
> > +++ b/drivers/input/mouse/synaptics.c
> > @@ -140,7 +140,6 @@ static const char * const topbuttonpad_pnp_ids[] = {
> > "LEN002E",
> > "LEN0033", /* Helix */
> > "LEN0034", /* T431s, L440, L540, T540, W540, X1 Carbon 2nd */
> > - "LEN0035", /* X240 */
>
> According to the history this came from Synaptics through Hans, so I'd
> like to make sure there are no several X240 versions floating around...
A quick google image search showed that the X240 had 2 versions: one
with the top software buttons, one without.
And this definitively rings a bell. I am sure we asked Lenovo and
Synaptics to change the PnPID when they would do such a change, but
they "forgot" during the *40 series refresh.
We have code in place to fix the reported ranges of the coordinates,
and we had to check against the board id (see min_max_pnpid_table[] in
synaptics.c).
Unfortunately, X240 (LEN0035) is not part of this table, so I don't
know which refresh of the board ID has implemented the non top
software buttons.
Cheers,
Benjamin
>
> > "LEN0036", /* T440 */
> > "LEN0037", /* X1 Carbon 2nd */
> > "LEN0038",
> > --
> > 2.17.1
> >
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: elantech - enable middle button support on 2 ThinkPads
From: Benjamin Tissoires @ 2019-05-21 6:43 UTC (permalink / raw)
To: Dmitry Torokhov, Peter Hutterer, 廖崇榮
Cc: Aaron Ma, open list:HID CORE LAYER, lkml
In-Reply-To: <20190521051053.GD183429@dtor-ws>
Hi,
On Tue, May 21, 2019 at 7:11 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Aaron,
>
> On Sun, May 19, 2019 at 03:27:10PM +0800, Aaron Ma wrote:
> > Adding 2 new touchpad PNPIDs to enable middle button support.
>
> Could you add their names in the comments please?
>
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
> > ---
> > drivers/input/mouse/elantech.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> > index a7f8b1614559..530142b5a115 100644
> > --- a/drivers/input/mouse/elantech.c
> > +++ b/drivers/input/mouse/elantech.c
> > @@ -1189,6 +1189,8 @@ static const char * const middle_button_pnp_ids[] = {
> > "LEN2132", /* ThinkPad P52 */
> > "LEN2133", /* ThinkPad P72 w/ NFC */
> > "LEN2134", /* ThinkPad P72 */
> > + "LEN0407",
AFAICT, this one is the Lenovo P53.
However, having a whitelist of new models is not going to scale IMO.
I was thinking at submitting a patch to enable middle button
unconditionally, but then I realized that libinput disables middle
click emulation on touchpads with an actual physical middle button.
And this morning I just realized that we might have a better chance at
this if we consider the new models to have the physical middle button.
I know LEN0407 attempts to bind over SMBus, so I would think we can
reduce the set of whitelist by just checking for
ETP_NEW_IC_SMBUS_HOST_NOTIFY (patch coming in).
Cheers,
Benjamin
> > + "LEN0408",
>
> These should come first - I'd like to keep the list sorted
> alphabetically.
>
> > NULL
> > };
> >
> > --
> > 2.17.1
> >
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* RE: [RESEND] input: keyboard: imx: make sure keyboard can always wake up system
From: Anson Huang @ 2019-05-21 6:36 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-input@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx
In-Reply-To: <20190521053047.GG183429@dtor-ws>
Hi, Dmitry
> -----Original Message-----
> From: dmitry.torokhov@gmail.com [mailto:dmitry.torokhov@gmail.com]
> Sent: Tuesday, May 21, 2019 1:31 PM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: shawnguo@kernel.org; s.hauer@pengutronix.de;
> kernel@pengutronix.de; festevam@gmail.com; linux-input@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; dl-linux-
> imx <linux-imx@nxp.com>
> Subject: Re: [RESEND] input: keyboard: imx: make sure keyboard can always
> wake up system
>
> Hi Anson,
> On Thu, Apr 04, 2019 at 01:40:16AM +0000, Anson Huang wrote:
> > There are several scenarios that keyboard can NOT wake up system from
> > suspend, e.g., if a keyboard is depressed between system device
> > suspend phase and device noirq suspend phase, the keyboard ISR will be
> > called and both keyboard depress and release interrupts will be
> > disabled, then keyboard will no longer be able to wake up system.
> > Another scenario would be, if a keyboard is kept depressed, and then
> > system goes into suspend, the expected behavior would be when keyboard
> > is released, system will be waked up, but current implementation can
> > NOT achieve that, because both depress and release interrupts are
> > disabled in ISR, and the event check is still in progress.
> >
> > To fix these issues, need to make sure keyboard's depress or release
> > interrupt is enabled after noirq device suspend phase, this patch
> > moves the suspend/resume callback to noirq suspend/resume phase, and
> > enable the corresponding interrupt according to current keyboard status.
>
> I believe it is possible for IRQ to be disabled and still being enabled as
> wakeup source. What happens if you call disable_irq() before disabling the
> clock?
Doing below does NOT fix the scenario/issue 100%, if the keypad's IRQ arrived during suspend
phase but before disabling its IRQ in its suspend callback, then issue is still there, as the issue is
that when system suspend, keypad's irq arrived during suspend and noirq suspend phase, then
keypad's hardware interrupt detection will be disabled in the ISR handler, and the timer event
setup by ISR handler is NOT fired, imx_keypad_check_for_events() is NOT executed and hardware
keypad's depress/release interrupt is NOT re-enabled yet, so it can NOT wake up system anymore...
So I think the solid fix is to make sure keypad can generate IRQ (either depress or release) at any time
during system suspend flow.
+++ b/drivers/input/keyboard/imx_keypad.c
@@ -533,6 +533,8 @@ static int __maybe_unused imx_kbd_suspend(struct device *dev)
/* imx kbd can wake up system even clock is disabled */
mutex_lock(&input_dev->mutex);
+ disable_irq(kbd->irq);
+
if (input_dev->users)
clk_disable_unprepare(kbd->clk);
@@ -562,6 +569,8 @@ static int __maybe_unused imx_kbd_resume(struct device *dev)
goto err_clk;
}
+ enable_irq(kbd->irq);
+
err_clk:
Anson.
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [RFC PATCH v2 0/4] Input: mpr121-polled: Add polled driver for MPR121
From: Dmitry Torokhov @ 2019-05-21 5:37 UTC (permalink / raw)
To: Michal Vokáč
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-input, devicetree, linux-kernel, Pengutronix Kernel Team
In-Reply-To: <1558098773-47416-1-git-send-email-michal.vokac@ysoft.com>
Hi Michal,
On Fri, May 17, 2019 at 03:12:49PM +0200, Michal Vokáč wrote:
> Hi,
>
> I have to deal with a situation where we have a custom i.MX6 based
> platform in production that uses the MPR121 touchkey controller.
> Unfortunately the chip is connected using only the I2C interface.
> The interrupt line is not used. Back in 2015 (Linux v3.14), my
> colleague modded the existing mpr121_touchkey.c driver to use polling
> instead of interrupt.
>
> For quite some time yet I am in a process of updating the product from
> the ancient Freescale v3.14 kernel to the latest mainline and pushing
> any needed changes upstream. The DT files for our imx6dl-yapp4 platform
> already made it into v5.1-rc.
>
> I rebased and updated our mpr121 patch to the latest mainline.
> It is created as a separate driver, similarly to gpio_keys_polled.
>
> The I2C device is quite susceptible to ESD. An ESD test quite often
> causes reset of the chip or some register randomly changes its value.
> The [PATCH 3/4] adds a write-through register cache. With the cache
> this state can be detected and the device can be re-initialied.
>
> The main question is: Is there any chance that such a polled driver
> could be accepted? Is it correct to implement it as a separate driver
> or should it be done as an option in the existing driver? I can not
> really imagine how I would do that though..
>
> There are also certain worries that the MPR121 chip may no longer be
> available in nonspecifically distant future. In case of EOL I will need
> to add a polled driver for an other touchkey chip. May it be already
> in mainline or a completely new one.
I think that my addition of input_polled_dev was ultimately a wrong
thing to do. I am looking into enabling polling mode for regular input
devices as we then can enable polling mode in existing drivers.
As far as gpio-keys vs gpio-key-polled, I feel that the capabilities of
polling driver is sufficiently different from interrupt-driven one, so
we will likely keep them separate.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: atmel_mxt_ts - add wakeup support
From: Dmitry Torokhov @ 2019-05-21 5:33 UTC (permalink / raw)
To: stefano.manni
Cc: nick, robh+dt, mark.rutland, linux-input, devicetree,
linux-kernel
In-Reply-To: <6f94097bb9192424f92e055e8af8062b2ae3e19f.camel@gmail.com>
On Sat, May 18, 2019 at 06:55:10PM +0200, stefano.manni@gmail.com wrote:
> Hi Dmitry,
>
> On Fri, 2019-05-17 at 14:30 -0700, Dmitry Torokhov wrote:
> > Hi Sefano,
> >
> > On Fri, May 17, 2019 at 11:17:40PM +0200, Stefano Manni wrote:
> > > Add wakeup support to the maxtouch driver.
> > > The device can wake up the system from suspend,
> > > mark the IRQ as wakeup capable, so that device
> > > irq is not disabled during system suspend.
> >
> > This should already be handled by I2C core, see lines after "if
> > (client->flags & I2C_CLIENT_WAKE)" in drivers/i2c/i2c-core-base.c.
> >
> > Unless there is dedicated wakeup interrupt we configure main
> > interrupt
> > as wake source.
> >
>
> what's about the other drivers (e.g. ili210x.c) doing like this?
> Shall they be purged?
They were likely done before I2C and driver core were enhanced to handle
wakeup automatically. We might want to clean them up, as long as we
verify that they keep working.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RESEND] input: keyboard: imx: make sure keyboard can always wake up system
From: dmitry.torokhov @ 2019-05-21 5:30 UTC (permalink / raw)
To: Anson Huang
Cc: shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-input@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx
In-Reply-To: <1554341727-16084-1-git-send-email-Anson.Huang@nxp.com>
Hi Anson,
On Thu, Apr 04, 2019 at 01:40:16AM +0000, Anson Huang wrote:
> There are several scenarios that keyboard can NOT wake up system
> from suspend, e.g., if a keyboard is depressed between system
> device suspend phase and device noirq suspend phase, the keyboard
> ISR will be called and both keyboard depress and release interrupts
> will be disabled, then keyboard will no longer be able to wake up
> system. Another scenario would be, if a keyboard is kept depressed,
> and then system goes into suspend, the expected behavior would be
> when keyboard is released, system will be waked up, but current
> implementation can NOT achieve that, because both depress and release
> interrupts are disabled in ISR, and the event check is still in
> progress.
>
> To fix these issues, need to make sure keyboard's depress or release
> interrupt is enabled after noirq device suspend phase, this patch
> moves the suspend/resume callback to noirq suspend/resume phase, and
> enable the corresponding interrupt according to current keyboard status.
I believe it is possible for IRQ to be disabled and still being enabled
as wakeup source. What happens if you call disable_irq() before
disabling the clock?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: imx6ul_tsc: use devm_platform_ioremap_resource() to simplify code
From: dmitry.torokhov @ 2019-05-21 5:13 UTC (permalink / raw)
To: Anson Huang
Cc: shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-input@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx
In-Reply-To: <1554095712-15413-1-git-send-email-Anson.Huang@nxp.com>
On Mon, Apr 01, 2019 at 05:19:55AM +0000, Anson Huang wrote:
> Use the new helper devm_platform_ioremap_resource() which wraps the
> platform_get_resource() and devm_ioremap_resource() together, to
> simplify the code.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thank you.
> ---
> drivers/input/touchscreen/imx6ul_tsc.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/input/touchscreen/imx6ul_tsc.c b/drivers/input/touchscreen/imx6ul_tsc.c
> index c10fc59..e04eecd 100644
> --- a/drivers/input/touchscreen/imx6ul_tsc.c
> +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> @@ -364,8 +364,6 @@ static int imx6ul_tsc_probe(struct platform_device *pdev)
> struct device_node *np = pdev->dev.of_node;
> struct imx6ul_tsc *tsc;
> struct input_dev *input_dev;
> - struct resource *tsc_mem;
> - struct resource *adc_mem;
> int err;
> int tsc_irq;
> int adc_irq;
> @@ -403,16 +401,14 @@ static int imx6ul_tsc_probe(struct platform_device *pdev)
> return err;
> }
>
> - tsc_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - tsc->tsc_regs = devm_ioremap_resource(&pdev->dev, tsc_mem);
> + tsc->tsc_regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(tsc->tsc_regs)) {
> err = PTR_ERR(tsc->tsc_regs);
> dev_err(&pdev->dev, "failed to remap tsc memory: %d\n", err);
> return err;
> }
>
> - adc_mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - tsc->adc_regs = devm_ioremap_resource(&pdev->dev, adc_mem);
> + tsc->adc_regs = devm_platform_ioremap_resource(pdev, 1);
> if (IS_ERR(tsc->adc_regs)) {
> err = PTR_ERR(tsc->adc_regs);
> dev_err(&pdev->dev, "failed to remap adc memory: %d\n", err);
> --
> 2.7.4
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: keyboard: imx: use devm_platform_ioremap_resource() to simplify code
From: dmitry.torokhov @ 2019-05-21 5:12 UTC (permalink / raw)
To: Anson Huang
Cc: shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-input@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx
In-Reply-To: <1554096209-17870-1-git-send-email-Anson.Huang@nxp.com>
On Mon, Apr 01, 2019 at 05:28:12AM +0000, Anson Huang wrote:
> Use the new helper devm_platform_ioremap_resource() which wraps the
> platform_get_resource() and devm_ioremap_resource() together, to
> simplify the code.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thank you.
> ---
> drivers/input/keyboard/imx_keypad.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
> index 539cb67..cf08f4a 100644
> --- a/drivers/input/keyboard/imx_keypad.c
> +++ b/drivers/input/keyboard/imx_keypad.c
> @@ -422,7 +422,6 @@ static int imx_keypad_probe(struct platform_device *pdev)
> dev_get_platdata(&pdev->dev);
> struct imx_keypad *keypad;
> struct input_dev *input_dev;
> - struct resource *res;
> int irq, error, i, row, col;
>
> if (!keymap_data && !pdev->dev.of_node) {
> @@ -455,8 +454,7 @@ static int imx_keypad_probe(struct platform_device *pdev)
> timer_setup(&keypad->check_matrix_timer,
> imx_keypad_check_for_events, 0);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - keypad->mmio_base = devm_ioremap_resource(&pdev->dev, res);
> + keypad->mmio_base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(keypad->mmio_base))
> return PTR_ERR(keypad->mmio_base);
>
> --
> 2.7.4
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: elantech - enable middle button support on 2 ThinkPads
From: Dmitry Torokhov @ 2019-05-21 5:10 UTC (permalink / raw)
To: Aaron Ma; +Cc: linux-input, linux-kernel, benjamin.tissoires
In-Reply-To: <20190519072711.2592-1-aaron.ma@canonical.com>
Hi Aaron,
On Sun, May 19, 2019 at 03:27:10PM +0800, Aaron Ma wrote:
> Adding 2 new touchpad PNPIDs to enable middle button support.
Could you add their names in the comments please?
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
> ---
> drivers/input/mouse/elantech.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index a7f8b1614559..530142b5a115 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1189,6 +1189,8 @@ static const char * const middle_button_pnp_ids[] = {
> "LEN2132", /* ThinkPad P52 */
> "LEN2133", /* ThinkPad P72 w/ NFC */
> "LEN2134", /* ThinkPad P72 */
> + "LEN0407",
> + "LEN0408",
These should come first - I'd like to keep the list sorted
alphabetically.
> NULL
> };
>
> --
> 2.17.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] Input: synaptics - remove X240 from the topbuttonpad list
From: Dmitry Torokhov @ 2019-05-21 5:08 UTC (permalink / raw)
To: Aaron Ma
Cc: linux-input, linux-kernel, benjamin.tissoires, Christopher Heiny,
Andrew Duggan, Hans de Goede
In-Reply-To: <20190519072711.2592-2-aaron.ma@canonical.com>
Hi Aaron,
On Sun, May 19, 2019 at 03:27:11PM +0800, Aaron Ma wrote:
> Lenovo ThinkPad X240 does not have the top software button.
> When this wrong ID in top button list, smbus mode will fail to probe,
> so keep it working at PS2 mode.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
> ---
> drivers/input/mouse/synaptics.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index b6da0c1267e3..6ae7bc92476b 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -140,7 +140,6 @@ static const char * const topbuttonpad_pnp_ids[] = {
> "LEN002E",
> "LEN0033", /* Helix */
> "LEN0034", /* T431s, L440, L540, T540, W540, X1 Carbon 2nd */
> - "LEN0035", /* X240 */
According to the history this came from Synaptics through Hans, so I'd
like to make sure there are no several X240 versions floating around...
> "LEN0036", /* T440 */
> "LEN0037", /* X1 Carbon 2nd */
> "LEN0038",
> --
> 2.17.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Hui Wang @ 2019-05-21 2:26 UTC (permalink / raw)
To: Xiaoxiao Liu, XiaoXiao Liu, dmitry.torokhov@gmail.com
Cc: pali.rohar@gmail.com, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <OSBPR01MB485510A2A32CD9D2CE5EF7A1DA070@OSBPR01MB4855.jpnprd01.prod.outlook.com>
Tested-by: Hui Wang <hui.wang@canonical.com>
On 2019/5/21 上午9:07, Xiaoxiao Liu wrote:
> Add Pali Rohár.
>
> -----邮件原件-----
> 发件人: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
> 发送时间: Monday, May 20, 2019 7:02 PM
> 收件人: dmitry.torokhov@gmail.com
> 抄送: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; hui.wang@canonical.com; 曹 曉建 Xiaojian Cao <xiaojian.cao@cn.alps.com>; zhangfp1@lenovo.com; 劉 曉曉 Xiaoxiao Liu <xiaoxiao.liu-1@cn.alps.com>; XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
> 主题: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
>
> when the alps trackpoint is detected and using the alps_v8_protocol_data procotol, the alps driver will not report the input data.
>
> solution: use standard mouse driver instead of alps driver when the specail trackpoint was detected.
>
> Signed-off-by: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
> ---
> drivers/input/mouse/alps.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c index 0a6f7ca883e7..516ae1d0eb17 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -24,7 +24,7 @@
>
> #include "psmouse.h"
> #include "alps.h"
> -
> +#include "trackpoint.h"
> /*
> * Definitions for ALPS version 3 and 4 command mode protocol
> */
> @@ -2864,6 +2864,22 @@ static const struct alps_protocol_info *alps_match_table(unsigned char *e7,
> return NULL;
> }
>
> +int alps_check_is_trackpoint(struct psmouse *psmouse) {
> + u8 param[2] = { 0 };
> + int error;
> +
> + error = ps2_command(&psmouse->ps2dev,
> + param, MAKE_PS2_CMD(0, 2, TP_READ_ID));
> + if (error)
> + return error;
> +
> + if (param[0] == TP_VARIANT_ALPS)
> + return 0;
> + psmouse_warn(psmouse, "It is not alps trackpoint.\n");
> + return -ENODEV;
> +}
> +
> static int alps_identify(struct psmouse *psmouse, struct alps_data *priv) {
> const struct alps_protocol_info *protocol; @@ -2912,6 +2928,11 @@ static int alps_identify(struct psmouse *psmouse, struct alps_data *priv)
> protocol = &alps_v3_protocol_data;
> } else if (e7[0] == 0x73 && e7[1] == 0x03 &&
> (e7[2] == 0x14 || e7[2] == 0x28)) {
> + if (alps_check_is_trackpoint(psmouse) == 0) {
> + psmouse_warn(psmouse,
> + "It is alps trackpoint, use the standard mouse driver.\n");
> + return -EINVAL;
> + }
> protocol = &alps_v8_protocol_data;
> } else if (e7[0] == 0x73 && e7[1] == 0x03 && e7[2] == 0xc8) {
> protocol = &alps_v9_protocol_data;
> --
> 2.20.1
>
^ permalink raw reply
* 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Xiaoxiao Liu @ 2019-05-21 1:07 UTC (permalink / raw)
To: XiaoXiao Liu, dmitry.torokhov@gmail.com
Cc: pali.rohar@gmail.com, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, hui.wang@canonical.com,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <20190520110149.27107-1-sliuuxiaonxiao@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 2431 bytes --]
Add Pali Roh¨¢r.
-----ÓʼþÔ¼þ-----
·¢¼þÈË: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
·¢ËÍʱ¼ä: Monday, May 20, 2019 7:02 PM
ÊÕ¼þÈË: dmitry.torokhov@gmail.com
³ËÍ: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; hui.wang@canonical.com; ²Ü •Ô½¨ Xiaojian Cao <xiaojian.cao@cn.alps.com>; zhangfp1@lenovo.com; „¢ •Ô•Ô Xiaoxiao Liu <xiaoxiao.liu-1@cn.alps.com>; XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
Ö÷Ìâ: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
when the alps trackpoint is detected and using the alps_v8_protocol_data procotol, the alps driver will not report the input data.
solution: use standard mouse driver instead of alps driver when the specail trackpoint was detected.
Signed-off-by: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
---
drivers/input/mouse/alps.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c index 0a6f7ca883e7..516ae1d0eb17 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -24,7 +24,7 @@
#include "psmouse.h"
#include "alps.h"
-
+#include "trackpoint.h"
/*
* Definitions for ALPS version 3 and 4 command mode protocol
*/
@@ -2864,6 +2864,22 @@ static const struct alps_protocol_info *alps_match_table(unsigned char *e7,
return NULL;
}
+int alps_check_is_trackpoint(struct psmouse *psmouse) {
+ u8 param[2] = { 0 };
+ int error;
+
+ error = ps2_command(&psmouse->ps2dev,
+ param, MAKE_PS2_CMD(0, 2, TP_READ_ID));
+ if (error)
+ return error;
+
+ if (param[0] == TP_VARIANT_ALPS)
+ return 0;
+ psmouse_warn(psmouse, "It is not alps trackpoint.\n");
+ return -ENODEV;
+}
+
static int alps_identify(struct psmouse *psmouse, struct alps_data *priv) {
const struct alps_protocol_info *protocol; @@ -2912,6 +2928,11 @@ static int alps_identify(struct psmouse *psmouse, struct alps_data *priv)
protocol = &alps_v3_protocol_data;
} else if (e7[0] == 0x73 && e7[1] == 0x03 &&
(e7[2] == 0x14 || e7[2] == 0x28)) {
+ if (alps_check_is_trackpoint(psmouse) == 0) {
+ psmouse_warn(psmouse,
+ "It is alps trackpoint, use the standard mouse driver.\n");
+ return -EINVAL;
+ }
protocol = &alps_v8_protocol_data;
} else if (e7[0] == 0x73 && e7[1] == 0x03 && e7[2] == 0xc8) {
protocol = &alps_v9_protocol_data;
--
2.20.1
^ permalink raw reply
* [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: XiaoXiao Liu @ 2019-05-20 11:01 UTC (permalink / raw)
To: dmitry.torokhov
Cc: linux-input, linux-kernel, hui.wang, xiaojian.cao, zhangfp1,
xiaoxiao.liu-1, XiaoXiao Liu
when the alps trackpoint is detected and using the alps_v8_protocol_data
procotol, the alps driver will not report the input data.
solution: use standard mouse driver instead of alps driver when the specail
trackpoint was detected.
Signed-off-by: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
---
drivers/input/mouse/alps.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 0a6f7ca883e7..516ae1d0eb17 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -24,7 +24,7 @@
#include "psmouse.h"
#include "alps.h"
-
+#include "trackpoint.h"
/*
* Definitions for ALPS version 3 and 4 command mode protocol
*/
@@ -2864,6 +2864,22 @@ static const struct alps_protocol_info *alps_match_table(unsigned char *e7,
return NULL;
}
+int alps_check_is_trackpoint(struct psmouse *psmouse)
+{
+ u8 param[2] = { 0 };
+ int error;
+
+ error = ps2_command(&psmouse->ps2dev,
+ param, MAKE_PS2_CMD(0, 2, TP_READ_ID));
+ if (error)
+ return error;
+
+ if (param[0] == TP_VARIANT_ALPS)
+ return 0;
+ psmouse_warn(psmouse, "It is not alps trackpoint.\n");
+ return -ENODEV;
+}
+
static int alps_identify(struct psmouse *psmouse, struct alps_data *priv)
{
const struct alps_protocol_info *protocol;
@@ -2912,6 +2928,11 @@ static int alps_identify(struct psmouse *psmouse, struct alps_data *priv)
protocol = &alps_v3_protocol_data;
} else if (e7[0] == 0x73 && e7[1] == 0x03 &&
(e7[2] == 0x14 || e7[2] == 0x28)) {
+ if (alps_check_is_trackpoint(psmouse) == 0) {
+ psmouse_warn(psmouse,
+ "It is alps trackpoint, use the standard mouse driver.\n");
+ return -EINVAL;
+ }
protocol = &alps_v8_protocol_data;
} else if (e7[0] == 0x73 && e7[1] == 0x03 && e7[2] == 0xc8) {
protocol = &alps_v9_protocol_data;
--
2.20.1
^ permalink raw reply related
* [PATCH 2/2] Input: synaptics - remove X240 from the topbuttonpad list
From: Aaron Ma @ 2019-05-19 7:27 UTC (permalink / raw)
To: aaron.ma, linux-input, linux-kernel, dmitry.torokhov,
benjamin.tissoires
In-Reply-To: <20190519072711.2592-1-aaron.ma@canonical.com>
Lenovo ThinkPad X240 does not have the top software button.
When this wrong ID in top button list, smbus mode will fail to probe,
so keep it working at PS2 mode.
Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
---
drivers/input/mouse/synaptics.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index b6da0c1267e3..6ae7bc92476b 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -140,7 +140,6 @@ static const char * const topbuttonpad_pnp_ids[] = {
"LEN002E",
"LEN0033", /* Helix */
"LEN0034", /* T431s, L440, L540, T540, W540, X1 Carbon 2nd */
- "LEN0035", /* X240 */
"LEN0036", /* T440 */
"LEN0037", /* X1 Carbon 2nd */
"LEN0038",
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] Input: elantech - enable middle button support on 2 ThinkPads
From: Aaron Ma @ 2019-05-19 7:27 UTC (permalink / raw)
To: aaron.ma, linux-input, linux-kernel, dmitry.torokhov,
benjamin.tissoires
Adding 2 new touchpad PNPIDs to enable middle button support.
Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
---
drivers/input/mouse/elantech.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index a7f8b1614559..530142b5a115 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1189,6 +1189,8 @@ static const char * const middle_button_pnp_ids[] = {
"LEN2132", /* ThinkPad P52 */
"LEN2133", /* ThinkPad P72 w/ NFC */
"LEN2134", /* ThinkPad P72 */
+ "LEN0407",
+ "LEN0408",
NULL
};
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox