* [PATCH v3 6/8] Input: elantech/SMBus - export all capabilities from the PS/2 node
From: Benjamin Tissoires @ 2019-05-24 13:50 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: <20190524135046.17710-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>
--
no changes in v3
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 v3 5/8] Input: elan_i2c - do not query the info if they are provided
From: Benjamin Tissoires @ 2019-05-24 13:50 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: <20190524135046.17710-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>
--
no changes in v3
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 v3 4/8] dt-bindings: add more optional properties for elan_i2c touchpads
From: Benjamin Tissoires @ 2019-05-24 13:50 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: <20190524135046.17710-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>
--
no changes in v3
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 v3 3/8] Input: elantech - detect middle button based on firmware version
From: Benjamin Tissoires @ 2019-05-24 13:50 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: <20190524135046.17710-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>
--
no changes in v3
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 v3 2/8] Input: elantech - add helper function elantech_is_buttonpad()
From: Benjamin Tissoires @ 2019-05-24 13:50 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: <20190524135046.17710-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>
--
no changes in v3
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 v3 1/8] Input: elantech - query the min/max information beforehand too
From: Benjamin Tissoires @ 2019-05-24 13:50 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: <20190524135046.17710-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 v3
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 v3 0/8] Fix Elan I2C touchpads in latest generation from Lenovo
From: Benjamin Tissoires @ 2019-05-24 13:50 UTC (permalink / raw)
To: Dmitry Torokhov, KT Liao, Rob Herring, Aaron Ma, Hans de Goede
Cc: linux-input, linux-kernel, devicetree, Benjamin Tissoires
Here comes the v3.
Very few changes from v2:
- dropped the last 2 patches where I tried to be smart, and it turns out
that it was not very a good idea
- also removed the only other blacklisted model, as it has been tested with
the v2 and it is also now working properly
Cheers,
Benjamin
Benjamin Tissoires (8):
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: elantech: remove P52 and P72 from SMBus blacklist
.../devicetree/bindings/input/elan_i2c.txt | 11 +
drivers/input/mouse/elan_i2c_core.c | 72 +++-
drivers/input/mouse/elantech.c | 320 ++++++++++--------
drivers/input/mouse/elantech.h | 8 +
4 files changed, 246 insertions(+), 165 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Peter Hutterer @ 2019-05-24 10:58 UTC (permalink / raw)
To: Hui Wang
Cc: Pali Rohár, Xiaoxiao Liu, dmitry.torokhov, XiaoXiao Liu,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <f0c2dff9-519e-d54d-4cd0-2be666656dc2@canonical.com>
On Fri, May 24, 2019 at 06:43:58PM +0800, Hui Wang wrote:
>
> On 2019/5/24 下午5:37, Peter Hutterer wrote:
> > On Fri, May 24, 2019 at 03:37:57PM +0800, Hui Wang wrote:
> > > On 2019/5/24 下午3:26, Pali Rohár wrote:
> > > > On Friday 24 May 2019 13:50:53 Hui Wang wrote:
> > > > > On 2019/5/24 下午1:36, Peter Hutterer wrote:
> > > > > > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote:
> > > > > > > On 2019/5/23 下午2:01, Peter Hutterer wrote:
> > > > > > > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote:
> > > > > > > > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote:
> > > > > > > > > > Hi Pali,
> > > > > > > > > >
> > > > > > > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that
> > > > > > > > > > alps_check_is_trackpoint() result and then update
> > > > > > > > > > alps_process_packet_ss4_v3() code to supports also
> > > > > > > > > > V8 trackpoint packets?
> > > > > > > > > > --> Yes, we can do like so, when we use the v8 method to process the trackpoint , the mouse speed is not ideal.
> > > > > > > > > > Then we choose the standard mouse driver.
> > > > > > > > > Mouse speed is something which is configurable. Have you configured it
> > > > > > > > > somehow? Also there is libinput project should handle these settings
> > > > > > > > > more properly.
> > > > > > > > >
> > > > > > > > > Adding Peter Hutterer, maintainer of libinput to loop. I think he could
> > > > > > > > > help with this problem.
> > > > > > > > libinput has a quirk for a magic multiplier on trackpoints. it was the only
> > > > > > > > solution I found that came close to "working" given that every device seems
> > > > > > > > to provide some other random magic data. Doc for it is here:
> > > > > > > > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html
> > > > > > > Hello Peter Hutterer,
> > > > > > >
> > > > > > > To adjust the trackpoint speed from userspace:
> > > > > > >
> > > > > > > If the libinput version is lower than 1.9.0, we could set
> > > > > > > POINTINGSTICK_CONST_ACCEL=0.25
> > > > > > >
> > > > > > > If the libinput version is higher than 1.12.0, we could set
> > > > > > > AttrTrackpointMultiplier=0.25
> > > > > > >
> > > > > > > But if we use libinput-1.10.0, how could we adjust the speed?
> > > > > > The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working
> > > > > > well (hence why it got replaced again). See the docs here though:
> > > > > > https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html
> > > > > >
> > > > > > Cheers,
> > > > > > Peter
> > > > > OK, got it, Thanks.
> > > > Is not here some database where for input device name / id is specified
> > > > that property? So users do not have to invent what is correct value for
> > > > their hardware?
> > > Since the libinput version in the ubuntu 18.04 is 1.10, I tried to set
> > > LIBINPUT_ATTR_TRACKPOINT_RANGE with different values (from 25, 20, 10, 5) in
> > > the udev hwdb database, I checked it with "udevadm info /dev/input/eventX"
> > > to confirm the value is set to LIBINPUT_ATTR_TRACKPOINT_RANGE successfully,
> > > but looks like the cursor speed doesn't change at all. So for ubuntu 18.04,
> > > looks like we have to adjust the speed in the kernel driver.
> > I don't think it's a good idea to make the kernel driver behaviour based on
> > an EOL libinput version just because one version of ubuntu ships with that.
> > 18.10 and 19.04 both ship with libinput 1.12.
> >
> > It'd be better to make sure it works well with a *current* version and then
> > patch libinput on 18.04 where needed.
>
> OK, that is sth we need to do. But anyway it is a bit risky to backport
> that much code and the whole folder of quirks to libinput 1.10.4, we need
> to do lots of test to make sure there is no regression on other machines.
>
> Probably we only need to keep the quirks/30-vendor-alps.quirks to 1.10.4 and
> drop other quirks, that will be better for our testing effort.
might be worth looking at what is in 1.10.7, e.g. a3b3e85c0e looks like it
may be of interest. That one suggests the range on some ALPS devices is over
100, so testing with 5-25 may really not have had any effect.
Cheers,
Peter
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Pali Rohár @ 2019-05-24 9:52 UTC (permalink / raw)
To: Peter Hutterer
Cc: Hui Wang, Xiaoxiao Liu, dmitry.torokhov, XiaoXiao Liu,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <20190524093238.GA1119@jelly>
On Friday 24 May 2019 19:32:38 Peter Hutterer wrote:
> On Fri, May 24, 2019 at 09:26:48AM +0200, Pali Rohár wrote:
> > On Friday 24 May 2019 13:50:53 Hui Wang wrote:
> > > On 2019/5/24 下午1:36, Peter Hutterer wrote:
> > > > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote:
> > > > > On 2019/5/23 下午2:01, Peter Hutterer wrote:
> > > > > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote:
> > > > > > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote:
> > > > > > > > Hi Pali,
> > > > > > > >
> > > > > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that
> > > > > > > > alps_check_is_trackpoint() result and then update
> > > > > > > > alps_process_packet_ss4_v3() code to supports also
> > > > > > > > V8 trackpoint packets?
> > > > > > > > --> Yes, we can do like so, when we use the v8 method to process the trackpoint , the mouse speed is not ideal.
> > > > > > > > Then we choose the standard mouse driver.
> > > > > > > Mouse speed is something which is configurable. Have you configured it
> > > > > > > somehow? Also there is libinput project should handle these settings
> > > > > > > more properly.
> > > > > > >
> > > > > > > Adding Peter Hutterer, maintainer of libinput to loop. I think he could
> > > > > > > help with this problem.
> > > > > > libinput has a quirk for a magic multiplier on trackpoints. it was the only
> > > > > > solution I found that came close to "working" given that every device seems
> > > > > > to provide some other random magic data. Doc for it is here:
> > > > > > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html
> > > > > Hello Peter Hutterer,
> > > > >
> > > > > To adjust the trackpoint speed from userspace:
> > > > >
> > > > > If the libinput version is lower than 1.9.0, we could set
> > > > > POINTINGSTICK_CONST_ACCEL=0.25
> > > > >
> > > > > If the libinput version is higher than 1.12.0, we could set
> > > > > AttrTrackpointMultiplier=0.25
> > > > >
> > > > > But if we use libinput-1.10.0, how could we adjust the speed?
> > > > The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working
> > > > well (hence why it got replaced again). See the docs here though:
> > > > https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html
> > > >
> > > > Cheers,
> > > > Peter
> > >
> > > OK, got it, Thanks.
> >
> > Is not here some database where for input device name / id is specified
> > that property? So users do not have to invent what is correct value for
> > their hardware?
>
> yeah, libinput ships with a quirks database that sets those, but it relies
> on users to submit the quirks.
> https://gitlab.freedesktop.org/libinput/libinput/tree/master/quirks
That is enough!
> There's no "correct" value anyway, if you ask 3 users what the trackpoint
> should do you'll get 5 answers :)
I know :) but reason for such database is to provide some sane defaults.
Which seems it is already there.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH v2 08/10] Input: elan_i2c - export true width/height
From: Benjamin Tissoires @ 2019-05-24 9:37 UTC (permalink / raw)
To: Dmitry Torokhov, KT Liao, Rob Herring, Aaron Ma, Hans de Goede
Cc: open list:HID CORE LAYER, lkml, devicetree
In-Reply-To: <20190521132712.2818-9-benjamin.tissoires@redhat.com>
On Tue, May 21, 2019 at 3:28 PM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> The width/height is actually in the same unit than X and Y. So we should
> not tamper the data, but just set the proper resolution, so that userspace
> can correctly detect which touch is a palm or a finger.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> --
>
> new in v2
> ---
> drivers/input/mouse/elan_i2c_core.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
> index 7ff044c6cd11..6f4feedb7765 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -45,7 +45,6 @@
> #define DRIVER_NAME "elan_i2c"
> #define ELAN_VENDOR_ID 0x04f3
> #define ETP_MAX_PRESSURE 255
> -#define ETP_FWIDTH_REDUCE 90
> #define ETP_FINGER_WIDTH 15
> #define ETP_RETRY_COUNT 3
>
> @@ -915,12 +914,8 @@ static void elan_report_contact(struct elan_tp_data *data,
> return;
> }
>
> - /*
> - * To avoid treating large finger as palm, let's reduce the
> - * width x and y per trace.
> - */
> - area_x = mk_x * (data->width_x - ETP_FWIDTH_REDUCE);
> - area_y = mk_y * (data->width_y - ETP_FWIDTH_REDUCE);
> + area_x = mk_x * data->width_x;
> + area_y = mk_y * data->width_y;
>
> major = max(area_x, area_y);
> minor = min(area_x, area_y);
> @@ -1123,8 +1118,10 @@ static int elan_setup_input_device(struct elan_tp_data *data)
> ETP_MAX_PRESSURE, 0, 0);
> input_set_abs_params(input, ABS_MT_TOUCH_MAJOR, 0,
> ETP_FINGER_WIDTH * max_width, 0, 0);
> + input_abs_set_res(input, ABS_MT_TOUCH_MAJOR, data->x_res);
> input_set_abs_params(input, ABS_MT_TOUCH_MINOR, 0,
> ETP_FINGER_WIDTH * min_width, 0, 0);
> + input_abs_set_res(input, ABS_MT_TOUCH_MINOR, data->y_res);
I had a chat with Peter on Wednesday, and he mentioned that this is
dangerous as Major/Minor are max/min of the width and height. And
given that we might have 2 different resolutions, we would need to do
some computation in the kernel to ensure the data is correct with
respect to the resolution.
TL;DR: I don't think we should export the resolution there :(
KT, should I drop the patch entirely, or is there a strong argument
for keeping the ETP_FWIDTH_REDUCE around?
Cheers,
Benjamin
>
> data->input = input;
>
> --
> 2.21.0
>
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Peter Hutterer @ 2019-05-24 9:37 UTC (permalink / raw)
To: Hui Wang
Cc: Pali Rohár, Xiaoxiao Liu, dmitry.torokhov, XiaoXiao Liu,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <d0b659bf-e6ed-bbbb-a3ab-17daf525a577@canonical.com>
On Fri, May 24, 2019 at 03:37:57PM +0800, Hui Wang wrote:
>
> On 2019/5/24 下午3:26, Pali Rohár wrote:
> > On Friday 24 May 2019 13:50:53 Hui Wang wrote:
> > > On 2019/5/24 下午1:36, Peter Hutterer wrote:
> > > > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote:
> > > > > On 2019/5/23 下午2:01, Peter Hutterer wrote:
> > > > > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote:
> > > > > > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote:
> > > > > > > > Hi Pali,
> > > > > > > >
> > > > > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that
> > > > > > > > alps_check_is_trackpoint() result and then update
> > > > > > > > alps_process_packet_ss4_v3() code to supports also
> > > > > > > > V8 trackpoint packets?
> > > > > > > > --> Yes, we can do like so, when we use the v8 method to process the trackpoint , the mouse speed is not ideal.
> > > > > > > > Then we choose the standard mouse driver.
> > > > > > > Mouse speed is something which is configurable. Have you configured it
> > > > > > > somehow? Also there is libinput project should handle these settings
> > > > > > > more properly.
> > > > > > >
> > > > > > > Adding Peter Hutterer, maintainer of libinput to loop. I think he could
> > > > > > > help with this problem.
> > > > > > libinput has a quirk for a magic multiplier on trackpoints. it was the only
> > > > > > solution I found that came close to "working" given that every device seems
> > > > > > to provide some other random magic data. Doc for it is here:
> > > > > > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html
> > > > > Hello Peter Hutterer,
> > > > >
> > > > > To adjust the trackpoint speed from userspace:
> > > > >
> > > > > If the libinput version is lower than 1.9.0, we could set
> > > > > POINTINGSTICK_CONST_ACCEL=0.25
> > > > >
> > > > > If the libinput version is higher than 1.12.0, we could set
> > > > > AttrTrackpointMultiplier=0.25
> > > > >
> > > > > But if we use libinput-1.10.0, how could we adjust the speed?
> > > > The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working
> > > > well (hence why it got replaced again). See the docs here though:
> > > > https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html
> > > >
> > > > Cheers,
> > > > Peter
> > > OK, got it, Thanks.
> > Is not here some database where for input device name / id is specified
> > that property? So users do not have to invent what is correct value for
> > their hardware?
>
> Since the libinput version in the ubuntu 18.04 is 1.10, I tried to set
> LIBINPUT_ATTR_TRACKPOINT_RANGE with different values (from 25, 20, 10, 5) in
> the udev hwdb database, I checked it with "udevadm info /dev/input/eventX"
> to confirm the value is set to LIBINPUT_ATTR_TRACKPOINT_RANGE successfully,
> but looks like the cursor speed doesn't change at all. So for ubuntu 18.04,
> looks like we have to adjust the speed in the kernel driver.
I don't think it's a good idea to make the kernel driver behaviour based on
an EOL libinput version just because one version of ubuntu ships with that.
18.10 and 19.04 both ship with libinput 1.12.
It'd be better to make sure it works well with a *current* version and then
patch libinput on 18.04 where needed.
Cheers,
Peter
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Peter Hutterer @ 2019-05-24 9:32 UTC (permalink / raw)
To: Pali Rohár
Cc: Hui Wang, Xiaoxiao Liu, dmitry.torokhov, XiaoXiao Liu,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <20190524072648.6zqgz7rpwpcv22pb@pali>
On Fri, May 24, 2019 at 09:26:48AM +0200, Pali Rohár wrote:
> On Friday 24 May 2019 13:50:53 Hui Wang wrote:
> > On 2019/5/24 下午1:36, Peter Hutterer wrote:
> > > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote:
> > > > On 2019/5/23 下午2:01, Peter Hutterer wrote:
> > > > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote:
> > > > > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote:
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that
> > > > > > > alps_check_is_trackpoint() result and then update
> > > > > > > alps_process_packet_ss4_v3() code to supports also
> > > > > > > V8 trackpoint packets?
> > > > > > > --> Yes, we can do like so, when we use the v8 method to process the trackpoint , the mouse speed is not ideal.
> > > > > > > Then we choose the standard mouse driver.
> > > > > > Mouse speed is something which is configurable. Have you configured it
> > > > > > somehow? Also there is libinput project should handle these settings
> > > > > > more properly.
> > > > > >
> > > > > > Adding Peter Hutterer, maintainer of libinput to loop. I think he could
> > > > > > help with this problem.
> > > > > libinput has a quirk for a magic multiplier on trackpoints. it was the only
> > > > > solution I found that came close to "working" given that every device seems
> > > > > to provide some other random magic data. Doc for it is here:
> > > > > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html
> > > > Hello Peter Hutterer,
> > > >
> > > > To adjust the trackpoint speed from userspace:
> > > >
> > > > If the libinput version is lower than 1.9.0, we could set
> > > > POINTINGSTICK_CONST_ACCEL=0.25
> > > >
> > > > If the libinput version is higher than 1.12.0, we could set
> > > > AttrTrackpointMultiplier=0.25
> > > >
> > > > But if we use libinput-1.10.0, how could we adjust the speed?
> > > The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working
> > > well (hence why it got replaced again). See the docs here though:
> > > https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html
> > >
> > > Cheers,
> > > Peter
> >
> > OK, got it, Thanks.
>
> Is not here some database where for input device name / id is specified
> that property? So users do not have to invent what is correct value for
> their hardware?
yeah, libinput ships with a quirks database that sets those, but it relies
on users to submit the quirks.
https://gitlab.freedesktop.org/libinput/libinput/tree/master/quirks
There's no "correct" value anyway, if you ask 3 users what the trackpoint
should do you'll get 5 answers :)
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH v2 09/10] Input: elan_i2c - correct the width/size base value
From: Benjamin Tissoires @ 2019-05-24 9:19 UTC (permalink / raw)
To: 廖崇榮
Cc: Dmitry Torokhov, Rob Herring, Aaron Ma, Hans de Goede,
open list:HID CORE LAYER, lkml, devicetree
In-Reply-To: <011a01d5120f$146265e0$3d2731a0$@emc.com.tw>
On Fri, May 24, 2019 at 11:00 AM 廖崇榮 <kt.liao@emc.com.tw> wrote:
>
> Hi
>
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
> Sent: Friday, May 24, 2019 3:06 PM
> To: 廖崇榮
> Cc: Dmitry Torokhov; Rob Herring; Aaron Ma; Hans de Goede; open list:HID CORE LAYER; lkml; devicetree@vger.kernel.org
> Subject: Re: [PATCH v2 09/10] Input: elan_i2c - correct the width/size base value
>
> On Fri, May 24, 2019 at 5:13 AM 廖崇榮 <kt.liao@emc.com.tw> wrote:
> >
> > Hi Benjamin,
> >
> > Thanks so much for all you do for Elan touchpad.
> >
> > For the width_*, I have a question for it.
> > Our antenna sensors fully occupied the whole touchpad PCB.
> >
> > The Gap between 2 sensors are 7.5 mil (0.19mm).
> > That's why we did not minus one trace.
>
> So, with the P52 I have:
> [ +0.000009] max: (3045,1731) drivers/input/mouse/elan_i2c_core.c:428
> [ +0.000003] traces: (24,14) drivers/input/mouse/elan_i2c_core.c:429
> [ +0.000002] size: (98,55) drivers/input/mouse/elan_i2c_core.c:430
> [ +0.000001] res: (31,31) drivers/input/mouse/elan_i2c_core.c:431
>
> calculated size (max/res): 98 x 56 mm
> true size, as measured: 101 x 60 mm
>
> I list layout information of P52 touchpad as below.
> Physical size : 99 x 58 mm
> Active Area size : ~ 97 * 56 mm, (boarding is 1.008mm for each side)
>
> Sensor layout:
> X Pitch : 4.0286 mm
> Y Pitch : 4.0147 mm
>
> Which gives (without the minus 1):
> width_x = max_x / x_traces = 3045 / 24 = 126.875 -> 3.9885 mm width_y = max_y / y_traces = 1731 / 14 = 123.643 -> 4.0927 mm
>
> -> this gives a total size of the touchpad of: 96 x 57 mm (width_x *
> 24, width_y * 14)
>
> With the minus 1:
> width_x = max_x / x_traces = 3045 / 23 = 132.391 -> 4.2707 mm width_y = max_y / y_traces = 1731 / 14 = 133.154 -> 4.2953 mm
>
> -> this gives a total size of the touchpad of: 102 x 60 mm (width_x *
> 24, width_y * 14)
> and considering traces-1: 98 x 56 mm
>
> Removing 1 to the number of traces gave a squarer values in rows and columns, and this is what is done in the PS/2 driver.
> Also, going back to the size of the touchpad gives a better value when removing 1 on the *traces.
> So maybe when forwarding the properties we should remove one there in the PS/2 driver?
>
> Removing 1 trace may be better for some of previous touchpad. (depending on sensor pattern)
> mk_* indicate the number of trace which is touched, and it's not a precise value.
> I think the usability won't change too much whether removing one trace.
> PS/2 have supported plenty of touchpad. It's better to remain the same.
>
OK, so I guess I should just drop this patch from the series then.
Cheers,
Benjamin
^ permalink raw reply
* RE: [PATCH v2 09/10] Input: elan_i2c - correct the width/size base value
From: 廖崇榮 @ 2019-05-24 9:00 UTC (permalink / raw)
To: 'Benjamin Tissoires'
Cc: 'Dmitry Torokhov', 'Rob Herring',
'Aaron Ma', 'Hans de Goede',
'open list:HID CORE LAYER', 'lkml', devicetree
In-Reply-To: <CAO-hwJLnjxVxdodqAkKdQpqjAPGV1QYnugM+9t_86xRD92WJ-Q@mail.gmail.com>
Hi
-----Original Message-----
From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
Sent: Friday, May 24, 2019 3:06 PM
To: 廖崇榮
Cc: Dmitry Torokhov; Rob Herring; Aaron Ma; Hans de Goede; open list:HID CORE LAYER; lkml; devicetree@vger.kernel.org
Subject: Re: [PATCH v2 09/10] Input: elan_i2c - correct the width/size base value
On Fri, May 24, 2019 at 5:13 AM 廖崇榮 <kt.liao@emc.com.tw> wrote:
>
> Hi Benjamin,
>
> Thanks so much for all you do for Elan touchpad.
>
> For the width_*, I have a question for it.
> Our antenna sensors fully occupied the whole touchpad PCB.
>
> The Gap between 2 sensors are 7.5 mil (0.19mm).
> That's why we did not minus one trace.
So, with the P52 I have:
[ +0.000009] max: (3045,1731) drivers/input/mouse/elan_i2c_core.c:428
[ +0.000003] traces: (24,14) drivers/input/mouse/elan_i2c_core.c:429
[ +0.000002] size: (98,55) drivers/input/mouse/elan_i2c_core.c:430
[ +0.000001] res: (31,31) drivers/input/mouse/elan_i2c_core.c:431
calculated size (max/res): 98 x 56 mm
true size, as measured: 101 x 60 mm
I list layout information of P52 touchpad as below.
Physical size : 99 x 58 mm
Active Area size : ~ 97 * 56 mm, (boarding is 1.008mm for each side)
Sensor layout:
X Pitch : 4.0286 mm
Y Pitch : 4.0147 mm
Which gives (without the minus 1):
width_x = max_x / x_traces = 3045 / 24 = 126.875 -> 3.9885 mm width_y = max_y / y_traces = 1731 / 14 = 123.643 -> 4.0927 mm
-> this gives a total size of the touchpad of: 96 x 57 mm (width_x *
24, width_y * 14)
With the minus 1:
width_x = max_x / x_traces = 3045 / 23 = 132.391 -> 4.2707 mm width_y = max_y / y_traces = 1731 / 14 = 133.154 -> 4.2953 mm
-> this gives a total size of the touchpad of: 102 x 60 mm (width_x *
24, width_y * 14)
and considering traces-1: 98 x 56 mm
Removing 1 to the number of traces gave a squarer values in rows and columns, and this is what is done in the PS/2 driver.
Also, going back to the size of the touchpad gives a better value when removing 1 on the *traces.
So maybe when forwarding the properties we should remove one there in the PS/2 driver?
Removing 1 trace may be better for some of previous touchpad. (depending on sensor pattern)
mk_* indicate the number of trace which is touched, and it's not a precise value.
I think the usability won't change too much whether removing one trace.
PS/2 have supported plenty of touchpad. It's better to remain the same.
Thanks
KT
Cheers,
Benjamin
>
>
> Thanks
> KT
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
> Sent: Tuesday, May 21, 2019 9:27 PM
> To: Dmitry Torokhov; KT Liao; Rob Herring; Aaron Ma; Hans de Goede
> Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; Benjamin Tissoires
> Subject: [PATCH v2 09/10] Input: elan_i2c - correct the width/size
> base value
>
> *_traces are the number of antennas. width_* is thus the space between
> 2 antennas. Which means, we should subtract 1 to the number of
> antennas to divide the touchpad by the number of holes between each antenna.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> --
>
> new in v2
> ---
> drivers/input/mouse/elan_i2c_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c
> b/drivers/input/mouse/elan_i2c_core.c
> index 6f4feedb7765..3375eaa9a72e 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -398,8 +398,8 @@ static int elan_query_device_parameters(struct
> elan_tp_data *data)
> if (error)
> return error;
> }
> - data->width_x = data->max_x / x_traces;
> - data->width_y = data->max_y / y_traces;
> + data->width_x = data->max_x / (x_traces - 1);
> + data->width_y = data->max_y / (y_traces - 1);
>
> if (device_property_read_u32(&client->dev,
> "touchscreen-x-mm", &x_mm) ||
> --
> 2.21.0
>
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Hui Wang @ 2019-05-24 7:37 UTC (permalink / raw)
To: Pali Rohár
Cc: Peter Hutterer, Xiaoxiao Liu, dmitry.torokhov, XiaoXiao Liu,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <20190524072648.6zqgz7rpwpcv22pb@pali>
On 2019/5/24 下午3:26, Pali Rohár wrote:
> On Friday 24 May 2019 13:50:53 Hui Wang wrote:
>> On 2019/5/24 下午1:36, Peter Hutterer wrote:
>>> On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote:
>>>> On 2019/5/23 下午2:01, Peter Hutterer wrote:
>>>>> On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote:
>>>>>> On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote:
>>>>>>> Hi Pali,
>>>>>>>
>>>>>>> Ok, and cannot you set ALPS_DUALPOINT flag based on that
>>>>>>> alps_check_is_trackpoint() result and then update
>>>>>>> alps_process_packet_ss4_v3() code to supports also
>>>>>>> V8 trackpoint packets?
>>>>>>> --> Yes, we can do like so, when we use the v8 method to process the trackpoint , the mouse speed is not ideal.
>>>>>>> Then we choose the standard mouse driver.
>>>>>> Mouse speed is something which is configurable. Have you configured it
>>>>>> somehow? Also there is libinput project should handle these settings
>>>>>> more properly.
>>>>>>
>>>>>> Adding Peter Hutterer, maintainer of libinput to loop. I think he could
>>>>>> help with this problem.
>>>>> libinput has a quirk for a magic multiplier on trackpoints. it was the only
>>>>> solution I found that came close to "working" given that every device seems
>>>>> to provide some other random magic data. Doc for it is here:
>>>>> https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html
>>>> Hello Peter Hutterer,
>>>>
>>>> To adjust the trackpoint speed from userspace:
>>>>
>>>> If the libinput version is lower than 1.9.0, we could set
>>>> POINTINGSTICK_CONST_ACCEL=0.25
>>>>
>>>> If the libinput version is higher than 1.12.0, we could set
>>>> AttrTrackpointMultiplier=0.25
>>>>
>>>> But if we use libinput-1.10.0, how could we adjust the speed?
>>> The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working
>>> well (hence why it got replaced again). See the docs here though:
>>> https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html
>>>
>>> Cheers,
>>> Peter
>> OK, got it, Thanks.
> Is not here some database where for input device name / id is specified
> that property? So users do not have to invent what is correct value for
> their hardware?
Since the libinput version in the ubuntu 18.04 is 1.10, I tried to set
LIBINPUT_ATTR_TRACKPOINT_RANGE with different values (from 25, 20, 10,
5) in the udev hwdb database, I checked it with "udevadm info
/dev/input/eventX" to confirm the value is set to
LIBINPUT_ATTR_TRACKPOINT_RANGE successfully, but looks like the cursor
speed doesn't change at all. So for ubuntu 18.04, looks like we have to
adjust the speed in the kernel driver.
Thanks,
Hui.
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Pali Rohár @ 2019-05-24 7:26 UTC (permalink / raw)
To: Hui Wang
Cc: Peter Hutterer, Xiaoxiao Liu, dmitry.torokhov, XiaoXiao Liu,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <d1fd207d-68e1-0b57-f0dc-c254bfc9352c@canonical.com>
On Friday 24 May 2019 13:50:53 Hui Wang wrote:
> On 2019/5/24 下午1:36, Peter Hutterer wrote:
> > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote:
> > > On 2019/5/23 下午2:01, Peter Hutterer wrote:
> > > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote:
> > > > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that
> > > > > > alps_check_is_trackpoint() result and then update
> > > > > > alps_process_packet_ss4_v3() code to supports also
> > > > > > V8 trackpoint packets?
> > > > > > --> Yes, we can do like so, when we use the v8 method to process the trackpoint , the mouse speed is not ideal.
> > > > > > Then we choose the standard mouse driver.
> > > > > Mouse speed is something which is configurable. Have you configured it
> > > > > somehow? Also there is libinput project should handle these settings
> > > > > more properly.
> > > > >
> > > > > Adding Peter Hutterer, maintainer of libinput to loop. I think he could
> > > > > help with this problem.
> > > > libinput has a quirk for a magic multiplier on trackpoints. it was the only
> > > > solution I found that came close to "working" given that every device seems
> > > > to provide some other random magic data. Doc for it is here:
> > > > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html
> > > Hello Peter Hutterer,
> > >
> > > To adjust the trackpoint speed from userspace:
> > >
> > > If the libinput version is lower than 1.9.0, we could set
> > > POINTINGSTICK_CONST_ACCEL=0.25
> > >
> > > If the libinput version is higher than 1.12.0, we could set
> > > AttrTrackpointMultiplier=0.25
> > >
> > > But if we use libinput-1.10.0, how could we adjust the speed?
> > The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working
> > well (hence why it got replaced again). See the docs here though:
> > https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html
> >
> > Cheers,
> > Peter
>
> OK, got it, Thanks.
Is not here some database where for input device name / id is specified
that property? So users do not have to invent what is correct value for
their hardware?
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH v2 09/10] Input: elan_i2c - correct the width/size base value
From: Benjamin Tissoires @ 2019-05-24 7:05 UTC (permalink / raw)
To: 廖崇榮
Cc: Dmitry Torokhov, Rob Herring, Aaron Ma, Hans de Goede,
open list:HID CORE LAYER, lkml, devicetree
In-Reply-To: <003d01d511de$9da229c0$d8e67d40$@emc.com.tw>
On Fri, May 24, 2019 at 5:13 AM 廖崇榮 <kt.liao@emc.com.tw> wrote:
>
> Hi Benjamin,
>
> Thanks so much for all you do for Elan touchpad.
>
> For the width_*, I have a question for it.
> Our antenna sensors fully occupied the whole touchpad PCB.
>
> The Gap between 2 sensors are 7.5 mil (0.19mm).
> That's why we did not minus one trace.
So, with the P52 I have:
[ +0.000009] max: (3045,1731) drivers/input/mouse/elan_i2c_core.c:428
[ +0.000003] traces: (24,14) drivers/input/mouse/elan_i2c_core.c:429
[ +0.000002] size: (98,55) drivers/input/mouse/elan_i2c_core.c:430
[ +0.000001] res: (31,31) drivers/input/mouse/elan_i2c_core.c:431
calculated size (max/res): 98 x 56 mm
true size, as measured: 101 x 60 mm
Which gives (without the minus 1):
width_x = max_x / x_traces = 3045 / 24 = 126.875 -> 3.9885 mm
width_y = max_y / y_traces = 1731 / 14 = 123.643 -> 4.0927 mm
-> this gives a total size of the touchpad of: 96 x 57 mm (width_x *
24, width_y * 14)
With the minus 1:
width_x = max_x / x_traces = 3045 / 23 = 132.391 -> 4.2707 mm
width_y = max_y / y_traces = 1731 / 14 = 133.154 -> 4.2953 mm
-> this gives a total size of the touchpad of: 102 x 60 mm (width_x *
24, width_y * 14)
and considering traces-1: 98 x 56 mm
Removing 1 to the number of traces gave a squarer values in rows and
columns, and this is what is done in the PS/2 driver.
Also, going back to the size of the touchpad gives a better value when
removing 1 on the *traces.
So maybe when forwarding the properties we should remove one there in
the PS/2 driver?
Cheers,
Benjamin
>
>
> Thanks
> KT
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
> Sent: Tuesday, May 21, 2019 9:27 PM
> To: Dmitry Torokhov; KT Liao; Rob Herring; Aaron Ma; Hans de Goede
> Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; Benjamin Tissoires
> Subject: [PATCH v2 09/10] Input: elan_i2c - correct the width/size base
> value
>
> *_traces are the number of antennas. width_* is thus the space between 2
> antennas. Which means, we should subtract 1 to the number of antennas to
> divide the touchpad by the number of holes between each antenna.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> --
>
> new in v2
> ---
> drivers/input/mouse/elan_i2c_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c
> b/drivers/input/mouse/elan_i2c_core.c
> index 6f4feedb7765..3375eaa9a72e 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -398,8 +398,8 @@ static int elan_query_device_parameters(struct
> elan_tp_data *data)
> if (error)
> return error;
> }
> - data->width_x = data->max_x / x_traces;
> - data->width_y = data->max_y / y_traces;
> + data->width_x = data->max_x / (x_traces - 1);
> + data->width_y = data->max_y / (y_traces - 1);
>
> if (device_property_read_u32(&client->dev,
> "touchscreen-x-mm", &x_mm) ||
> --
> 2.21.0
>
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Hui Wang @ 2019-05-24 5:50 UTC (permalink / raw)
To: Peter Hutterer
Cc: Pali Rohár, Xiaoxiao Liu, dmitry.torokhov, XiaoXiao Liu,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <20190524053648.GA16379@jelly>
On 2019/5/24 下午1:36, Peter Hutterer wrote:
> On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote:
>> On 2019/5/23 下午2:01, Peter Hutterer wrote:
>>> On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote:
>>>> On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote:
>>>>> Hi Pali,
>>>>>
>>>>> Ok, and cannot you set ALPS_DUALPOINT flag based on that
>>>>> alps_check_is_trackpoint() result and then update
>>>>> alps_process_packet_ss4_v3() code to supports also
>>>>> V8 trackpoint packets?
>>>>> --> Yes, we can do like so, when we use the v8 method to process the trackpoint , the mouse speed is not ideal.
>>>>> Then we choose the standard mouse driver.
>>>> Mouse speed is something which is configurable. Have you configured it
>>>> somehow? Also there is libinput project should handle these settings
>>>> more properly.
>>>>
>>>> Adding Peter Hutterer, maintainer of libinput to loop. I think he could
>>>> help with this problem.
>>> libinput has a quirk for a magic multiplier on trackpoints. it was the only
>>> solution I found that came close to "working" given that every device seems
>>> to provide some other random magic data. Doc for it is here:
>>> https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html
>> Hello Peter Hutterer,
>>
>> To adjust the trackpoint speed from userspace:
>>
>> If the libinput version is lower than 1.9.0, we could set
>> POINTINGSTICK_CONST_ACCEL=0.25
>>
>> If the libinput version is higher than 1.12.0, we could set
>> AttrTrackpointMultiplier=0.25
>>
>> But if we use libinput-1.10.0, how could we adjust the speed?
> The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working
> well (hence why it got replaced again). See the docs here though:
> https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html
>
> Cheers,
> Peter
OK, got it, Thanks.
>>> There are also different speeds depending on which xorg driver you'd use (or
>>> libinput/Wayland), so a "mouse speed is not ideal" is almost a guarantee,
>>> given a large enough variety of setups :) That's why we have the speed
>>> toggle, but I'm happy to hear any suggestions on how to make the trackpoint
>>> more useful (in libinput anyway).
>>>
>>>> I do not think it is a good idea to force back to generic PS/2 mouse
>>>> driver for touchpads and trackpoints. Native drivers for touchpads and
>>>> trackpoints supports multitouch, absolute reporting and lot of other
>>>> things... Also calculation of mouse speed from absolute positions on
>>>> touchpads can be more easily fixed as from emulated relative movements.
>>> Yeah, agree. Using PS/2 mouse drivers means you lose *all* the extra
>>> features touchpads have like palm detection, tapping, scrolling, gestures,
>>> etc.
>>>
>>> Cheers,
>>> Peter
>>>
>>>> Dmitry, what is your opinion about this problem? What should psmouse.ko
>>>> do in this situation? Disallow usage of absolute mode and force bare
>>>> PS/2 relative mode?
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Peter Hutterer @ 2019-05-24 5:36 UTC (permalink / raw)
To: Hui Wang
Cc: Pali Rohár, Xiaoxiao Liu, dmitry.torokhov, XiaoXiao Liu,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <38ec4a40-d51a-aeb1-a5e8-dbaed1142298@canonical.com>
On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote:
>
> On 2019/5/23 下午2:01, Peter Hutterer wrote:
> > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote:
> > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote:
> > > > Hi Pali,
> > > >
> > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that
> > > > alps_check_is_trackpoint() result and then update
> > > > alps_process_packet_ss4_v3() code to supports also
> > > > V8 trackpoint packets?
> > > > --> Yes, we can do like so, when we use the v8 method to process the trackpoint , the mouse speed is not ideal.
> > > > Then we choose the standard mouse driver.
> > > Mouse speed is something which is configurable. Have you configured it
> > > somehow? Also there is libinput project should handle these settings
> > > more properly.
> > >
> > > Adding Peter Hutterer, maintainer of libinput to loop. I think he could
> > > help with this problem.
> > libinput has a quirk for a magic multiplier on trackpoints. it was the only
> > solution I found that came close to "working" given that every device seems
> > to provide some other random magic data. Doc for it is here:
> > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html
>
> Hello Peter Hutterer,
>
> To adjust the trackpoint speed from userspace:
>
> If the libinput version is lower than 1.9.0, we could set
> POINTINGSTICK_CONST_ACCEL=0.25
>
> If the libinput version is higher than 1.12.0, we could set
> AttrTrackpointMultiplier=0.25
>
> But if we use libinput-1.10.0, how could we adjust the speed?
The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working
well (hence why it got replaced again). See the docs here though:
https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html
Cheers,
Peter
> >
> > There are also different speeds depending on which xorg driver you'd use (or
> > libinput/Wayland), so a "mouse speed is not ideal" is almost a guarantee,
> > given a large enough variety of setups :) That's why we have the speed
> > toggle, but I'm happy to hear any suggestions on how to make the trackpoint
> > more useful (in libinput anyway).
> >
> > > I do not think it is a good idea to force back to generic PS/2 mouse
> > > driver for touchpads and trackpoints. Native drivers for touchpads and
> > > trackpoints supports multitouch, absolute reporting and lot of other
> > > things... Also calculation of mouse speed from absolute positions on
> > > touchpads can be more easily fixed as from emulated relative movements.
> > Yeah, agree. Using PS/2 mouse drivers means you lose *all* the extra
> > features touchpads have like palm detection, tapping, scrolling, gestures,
> > etc.
> >
> > Cheers,
> > Peter
> >
> > > Dmitry, what is your opinion about this problem? What should psmouse.ko
> > > do in this situation? Disallow usage of absolute mode and force bare
> > > PS/2 relative mode?
> >
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Hui Wang @ 2019-05-24 5:25 UTC (permalink / raw)
To: Peter Hutterer, Pali Rohár
Cc: Xiaoxiao Liu, dmitry.torokhov, XiaoXiao Liu,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com
In-Reply-To: <20190523060154.GA10526@jelly>
On 2019/5/23 下午2:01, Peter Hutterer wrote:
> On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote:
>> On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote:
>>> Hi Pali,
>>>
>>> Ok, and cannot you set ALPS_DUALPOINT flag based on that
>>> alps_check_is_trackpoint() result and then update
>>> alps_process_packet_ss4_v3() code to supports also
>>> V8 trackpoint packets?
>>> --> Yes, we can do like so, when we use the v8 method to process the trackpoint , the mouse speed is not ideal.
>>> Then we choose the standard mouse driver.
>> Mouse speed is something which is configurable. Have you configured it
>> somehow? Also there is libinput project should handle these settings
>> more properly.
>>
>> Adding Peter Hutterer, maintainer of libinput to loop. I think he could
>> help with this problem.
> libinput has a quirk for a magic multiplier on trackpoints. it was the only
> solution I found that came close to "working" given that every device seems
> to provide some other random magic data. Doc for it is here:
> https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html
Hello Peter Hutterer,
To adjust the trackpoint speed from userspace:
If the libinput version is lower than 1.9.0, we could set
POINTINGSTICK_CONST_ACCEL=0.25
If the libinput version is higher than 1.12.0, we could set
AttrTrackpointMultiplier=0.25
But if we use libinput-1.10.0, how could we adjust the speed?
Many thanks in advance.
Hui.
>
> There are also different speeds depending on which xorg driver you'd use (or
> libinput/Wayland), so a "mouse speed is not ideal" is almost a guarantee,
> given a large enough variety of setups :) That's why we have the speed
> toggle, but I'm happy to hear any suggestions on how to make the trackpoint
> more useful (in libinput anyway).
>
>> I do not think it is a good idea to force back to generic PS/2 mouse
>> driver for touchpads and trackpoints. Native drivers for touchpads and
>> trackpoints supports multitouch, absolute reporting and lot of other
>> things... Also calculation of mouse speed from absolute positions on
>> touchpads can be more easily fixed as from emulated relative movements.
> Yeah, agree. Using PS/2 mouse drivers means you lose *all* the extra
> features touchpads have like palm detection, tapping, scrolling, gestures,
> etc.
>
> Cheers,
> Peter
>
>> Dmitry, what is your opinion about this problem? What should psmouse.ko
>> do in this situation? Disallow usage of absolute mode and force bare
>> PS/2 relative mode?
>
^ permalink raw reply
* RE: [PATCH v2 09/10] Input: elan_i2c - correct the width/size base value
From: 廖崇榮 @ 2019-05-24 3:13 UTC (permalink / raw)
To: 'Benjamin Tissoires', 'Dmitry Torokhov',
'Rob Herring', 'Aaron Ma',
'Hans de Goede'
Cc: linux-input, linux-kernel, devicetree
In-Reply-To: <20190521132712.2818-10-benjamin.tissoires@redhat.com>
Hi Benjamin,
Thanks so much for all you do for Elan touchpad.
For the width_*, I have a question for it.
Our antenna sensors fully occupied the whole touchpad PCB.
The Gap between 2 sensors are 7.5 mil (0.19mm).
That's why we did not minus one trace.
Thanks
KT
-----Original Message-----
From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
Sent: Tuesday, May 21, 2019 9:27 PM
To: Dmitry Torokhov; KT Liao; Rob Herring; Aaron Ma; Hans de Goede
Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org;
devicetree@vger.kernel.org; Benjamin Tissoires
Subject: [PATCH v2 09/10] Input: elan_i2c - correct the width/size base
value
*_traces are the number of antennas. width_* is thus the space between 2
antennas. Which means, we should subtract 1 to the number of antennas to
divide the touchpad by the number of holes between each antenna.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
--
new in v2
---
drivers/input/mouse/elan_i2c_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index 6f4feedb7765..3375eaa9a72e 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -398,8 +398,8 @@ static int elan_query_device_parameters(struct
elan_tp_data *data)
if (error)
return error;
}
- data->width_x = data->max_x / x_traces;
- data->width_y = data->max_y / y_traces;
+ data->width_x = data->max_x / (x_traces - 1);
+ data->width_y = data->max_y / (y_traces - 1);
if (device_property_read_u32(&client->dev,
"touchscreen-x-mm", &x_mm) ||
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 2/2] input: keyboard: mtk-pmic-keys: add MT6392 support
From: Dmitry Torokhov @ 2019-05-23 22:55 UTC (permalink / raw)
To: Fabien Parent
Cc: robh+dt, mark.rutland, matthias.bgg, linux-input, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20190513142120.6527-2-fparent@baylibre.com>
On Mon, May 13, 2019 at 04:21:20PM +0200, Fabien Parent wrote:
> Add support for MT6392 PMIC's keys.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
Apparently this depends on not-yet merged MT6392 support in MFD, so
please merge through MFD tree with the rest of it.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/keyboard/mtk-pmic-keys.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
> index 8e6ebab05ab4..aaf68cbf7e5b 100644
> --- a/drivers/input/keyboard/mtk-pmic-keys.c
> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
> @@ -18,6 +18,7 @@
> #include <linux/interrupt.h>
> #include <linux/kernel.h>
> #include <linux/mfd/mt6323/registers.h>
> +#include <linux/mfd/mt6392/registers.h>
> #include <linux/mfd/mt6397/core.h>
> #include <linux/mfd/mt6397/registers.h>
> #include <linux/module.h>
> @@ -83,6 +84,16 @@ static const struct mtk_pmic_regs mt6323_regs = {
> .pmic_rst_reg = MT6323_TOP_RST_MISC,
> };
>
> +static const struct mtk_pmic_regs mt6392_regs = {
> + .keys_regs[MTK_PMIC_PWRKEY_INDEX] =
> + MTK_PMIC_KEYS_REGS(MT6392_CHRSTATUS,
> + 0x2, MT6392_INT_MISC_CON, 0x10),
> + .keys_regs[MTK_PMIC_HOMEKEY_INDEX] =
> + MTK_PMIC_KEYS_REGS(MT6392_CHRSTATUS,
> + 0x4, MT6392_INT_MISC_CON, 0x8),
> + .pmic_rst_reg = MT6392_TOP_RST_MISC,
> +};
> +
> struct mtk_pmic_keys_info {
> struct mtk_pmic_keys *keys;
> const struct mtk_pmic_keys_regs *regs;
> @@ -238,6 +249,9 @@ static const struct of_device_id of_mtk_pmic_keys_match_tbl[] = {
> }, {
> .compatible = "mediatek,mt6323-keys",
> .data = &mt6323_regs,
> + }, {
> + .compatible = "mediatek,mt6392-keys",
> + .data = &mt6392_regs,
> }, {
> /* sentinel */
> }
> --
> 2.20.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: uinput - add compat ioctl number translation for UI_*_FF_UPLOAD
From: Dmitry Torokhov @ 2019-05-23 19:59 UTC (permalink / raw)
To: Andrey Smirnov
Cc: linux-input, Pierre-Loup A . Griffais, stable, linux-kernel
In-Reply-To: <20190522013922.25538-1-andrew.smirnov@gmail.com>
On Tue, May 21, 2019 at 06:39:22PM -0700, Andrey Smirnov wrote:
> In the case of compat syscall ioctl numbers for UI_BEGIN_FF_UPLOAD and
> UI_END_FF_UPLOAD need to be adjusted before being passed on
> uinput_ioctl_handler() since code built with -m32 will be passing
> slightly different values. Extend the code already covering
> UI_SET_PHYS to cover UI_BEGIN_FF_UPLOAD and UI_END_FF_UPLOAD as well.
>
> Reported-by: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: linux-input@vger.kernel.org
> Cc: stable@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
Applied, thank you.
> ---
> drivers/input/misc/uinput.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 1a6762fc38f9..1116d4cd5695 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -1051,13 +1051,24 @@ static long uinput_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>
> #ifdef CONFIG_COMPAT
>
> -#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
> +#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
> +#define UI_BEGIN_FF_UPLOAD_COMPAT _IOWR(UINPUT_IOCTL_BASE, 200, struct uinput_ff_upload_compat)
> +#define UI_END_FF_UPLOAD_COMPAT _IOW(UINPUT_IOCTL_BASE, 201, struct uinput_ff_upload_compat)
>
> static long uinput_compat_ioctl(struct file *file,
> unsigned int cmd, unsigned long arg)
> {
> - if (cmd == UI_SET_PHYS_COMPAT)
> + switch (cmd) {
> + case UI_SET_PHYS_COMPAT:
> cmd = UI_SET_PHYS;
> + break;
> + case UI_BEGIN_FF_UPLOAD_COMPAT:
> + cmd = UI_BEGIN_FF_UPLOAD;
> + break;
> + case UI_END_FF_UPLOAD_COMPAT:
> + cmd = UI_END_FF_UPLOAD;
> + break;
> + }
>
> return uinput_ioctl_handler(file, cmd, arg, compat_ptr(arg));
> }
> --
> 2.21.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: silead: Add MSSL0017 to acpi_device_id.
From: Dmitry Torokhov @ 2019-05-23 19:55 UTC (permalink / raw)
To: Daniel Smith
Cc: Hans de Goede, linux-input, platform-driver-x86, linux-kernel
In-Reply-To: <20190523190659.3117-1-danct12@disroot.org>
On Fri, May 24, 2019 at 02:06:59AM +0700, Daniel Smith wrote:
> On Chuwi Hi10 Plus, the Silead device id is MSSL0017.
>
> Signed-off-by: Daniel Smith <danct12@disroot.org>
Applied keeping Hans' reviewed-by from the previous version; thank you.
> ---
> drivers/input/touchscreen/silead.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
> index 09241d4cdebc..06f0eb04a8fd 100644
> --- a/drivers/input/touchscreen/silead.c
> +++ b/drivers/input/touchscreen/silead.c
> @@ -617,6 +617,7 @@ static const struct acpi_device_id silead_ts_acpi_match[] = {
> { "MSSL1680", 0 },
> { "MSSL0001", 0 },
> { "MSSL0002", 0 },
> + { "MSSL0017", 0 },
> { }
> };
> MODULE_DEVICE_TABLE(acpi, silead_ts_acpi_match);
> --
> 2.21.0
>
--
Dmitry
^ permalink raw reply
* [PATCH] platform/x86: touchscreen_dmi: Add info for the CHUWI Hi10 Plus tablet.
From: Daniel Smith @ 2019-05-23 19:09 UTC (permalink / raw)
Cc: Daniel Smith, Hans de Goede, Darren Hart, Andy Shevchenko,
linux-input, platform-driver-x86, linux-kernel
Added touch screen info for CHUWI Hi10 Plus tablet.
Signed-off-by: Daniel Smith <danct12@disroot.org>
---
drivers/platform/x86/touchscreen_dmi.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index bd0856d2e825..1dbb53c3f1e7 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -91,6 +91,22 @@ static const struct ts_dmi_data chuwi_hi10_air_data = {
.properties = chuwi_hi10_air_props,
};
+static const struct property_entry chuwi_hi10_plus_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 0),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 5),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 1914),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1283),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-chuwi-hi10plus.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("silead,home-button"),
+ { }
+};
+
+static const struct ts_dmi_data chuwi_hi10_plus_data = {
+ .acpi_name = "MSSL0017:00",
+ .properties = chuwi_hi10_plus_props,
+};
+
static const struct property_entry chuwi_vi8_props[] = {
PROPERTY_ENTRY_U32("touchscreen-min-x", 4),
PROPERTY_ENTRY_U32("touchscreen-min-y", 6),
@@ -605,6 +621,15 @@ static const struct dmi_system_id touchscreen_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_SKU, "P1W6_C109D_B"),
},
},
+ {
+ /* Chuwi Hi10 Plus (CWI527) */
+ .driver_data = (void *)&chuwi_hi10_plus_data,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Hi10 plus tablet"),
+ DMI_MATCH(DMI_BOARD_NAME, "Cherry Trail CR"),
+ },
+ },
{
/* Chuwi Vi8 (CWI506) */
.driver_data = (void *)&chuwi_vi8_data,
--
2.21.0
^ 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