Linux Input/HID development
 help / color / mirror / Atom feed
* 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

* [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

* [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 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 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 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 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 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 7/8] Input: elan_i2c - handle physical middle button
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 models have a middle button, we should export it as well.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

--

no changes in v3

new in v2

Is it really worth having a separate property, or should we just expose a
middle button whatsoever?
---
 drivers/input/mouse/elan_i2c_core.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index 53cac610ba33..7ff044c6cd11 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -99,6 +99,7 @@ struct elan_tp_data {
 	u8			max_baseline;
 	bool			baseline_ready;
 	u8			clickpad;
+	bool			middle_button;
 };
 
 static int elan_get_fwinfo(u16 ic_type, u16 *validpage_count,
@@ -420,6 +421,9 @@ static int elan_query_device_parameters(struct elan_tp_data *data)
 	if (device_property_read_bool(&client->dev, "elan,clickpad"))
 		data->clickpad = 1;
 
+	if (device_property_read_bool(&client->dev, "elan,middle-button"))
+		data->middle_button = true;
+
 	return 0;
 }
 
@@ -958,8 +962,9 @@ static void elan_report_absolute(struct elan_tp_data *data, u8 *packet)
 			finger_data += ETP_FINGER_DATA_LEN;
 	}
 
-	input_report_key(input, BTN_LEFT, tp_info & 0x01);
-	input_report_key(input, BTN_RIGHT, tp_info & 0x02);
+	input_report_key(input, BTN_LEFT,   tp_info & BIT(0));
+	input_report_key(input, BTN_MIDDLE, tp_info & BIT(2));
+	input_report_key(input, BTN_RIGHT,  tp_info & BIT(1));
 	input_report_abs(input, ABS_DISTANCE, hover_event != 0);
 	input_mt_report_pointer_emulation(input, true);
 	input_sync(input);
@@ -1091,10 +1096,13 @@ static int elan_setup_input_device(struct elan_tp_data *data)
 
 	__set_bit(EV_ABS, input->evbit);
 	__set_bit(INPUT_PROP_POINTER, input->propbit);
-	if (data->clickpad)
+	if (data->clickpad) {
 		__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
-	else
+	} else {
 		__set_bit(BTN_RIGHT, input->keybit);
+		if (data->middle_button)
+			__set_bit(BTN_MIDDLE, input->keybit);
+	}
 	__set_bit(BTN_LEFT, input->keybit);
 
 	/* Set up ST parameters */
-- 
2.21.0

^ permalink raw reply related

* [PATCH v3 8/8] Input: elantech: remove P52 and P72 from SMBus blacklist
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>

Both now works correctly over SMBus. Let's use this driver so we can
update all five fingers every 8ms.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

--

changes in v3:
- added the P72 too

new in v2
---
 drivers/input/mouse/elantech.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index ca10fd97d9d5..ea1ee0f44a65 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1779,10 +1779,6 @@ static const char * const i2c_blacklist_pnp_ids[] = {
 	 * These are known to not be working properly as bits are missing
 	 * in elan_i2c.
 	 */
-	"LEN2131", /* ThinkPad P52 w/ NFC */
-	"LEN2132", /* ThinkPad P52 */
-	"LEN2133", /* ThinkPad P72 w/ NFC */
-	"LEN2134", /* ThinkPad P72 */
 	NULL
 };
 
-- 
2.21.0

^ permalink raw reply related

* Re: [PATCH] platform/x86: touchscreen_dmi: Add info for the CHUWI Hi10 Plus tablet.
From: Andy Shevchenko @ 2019-05-24 16:49 UTC (permalink / raw)
  To: Daniel Smith
  Cc: Hans de Goede, Darren Hart, Andy Shevchenko, linux-input,
	Platform Driver, Linux Kernel Mailing List
In-Reply-To: <20190523190913.5801-1-danct12@disroot.org>

On Thu, May 23, 2019 at 10:12 PM Daniel Smith <danct12@disroot.org> wrote:
>
> Added touch screen info for CHUWI Hi10 Plus tablet.
>

Pushed to my review and testing queue, thanks!

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


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply

* [PATCH 2/3] input: Add SW_UNSUPPORT_INSERT define
From: bgoswami @ 2019-05-24 20:40 UTC (permalink / raw)
  To: dmitry.torokhov
  Cc: alsa-devel, Banajit Goswami, plai, tiwai, broonie,
	srinivas.kandagatla, linux-input, Gopikrishnaiah Anandan

From: Banajit Goswami <bgoswami@codeaurora.org>

Some devices may not support specific type of input devices. For example,
when a headset or extension cable with GND/MIC swap is plugged into a
headset jack that does not support the headset/cable, it needs to be
reported with a corresponding input event. Also, increase the max values
for INPUT_DEVICE_ID_SW_MAX and SW_MAX, to accommodate future extension of
the number of event.

Signed-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
---
 include/linux/mod_devicetable.h        | 2 +-
 include/uapi/linux/input-event-codes.h | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 448621c..7586099 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -299,7 +299,7 @@ struct pcmcia_device_id {
 #define INPUT_DEVICE_ID_LED_MAX		0x0f
 #define INPUT_DEVICE_ID_SND_MAX		0x07
 #define INPUT_DEVICE_ID_FF_MAX		0x7f
-#define INPUT_DEVICE_ID_SW_MAX		0x0f
+#define INPUT_DEVICE_ID_SW_MAX		0x1f
 #define INPUT_DEVICE_ID_PROP_MAX	0x1f
 
 #define INPUT_DEVICE_ID_MATCH_BUS	1
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index 85387c7..960fa86 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -808,7 +808,8 @@
 #define SW_LINEIN_INSERT	0x0d  /* set = inserted */
 #define SW_MUTE_DEVICE		0x0e  /* set = device disabled */
 #define SW_PEN_INSERTED		0x0f  /* set = pen inserted */
-#define SW_MAX			0x0f
+#define SW_UNSUPPORT_INSERT	0x10  /* set = unsupported device inserted */
+#define SW_MAX			0x1f
 #define SW_CNT			(SW_MAX+1)
 
 /*
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related

* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue the special alps trackpoint do not work.
From: Hui Wang @ 2019-05-25  1:33 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: <20190524105822.GA3358@jelly>


On 2019/5/24 下午6:58, Peter Hutterer wrote:
> 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:
>>>>
>> 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.

Oh, looks exactly the same as our issue, will have a try with it.

Thanks,

Hui.


>
> Cheers,
>     Peter
>

^ permalink raw reply

* [PATCH -next] HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices
From: YueHaibing @ 2019-05-25 14:09 UTC (permalink / raw)
  To: jikos, benjamin.tissoires; +Cc: linux-kernel, linux-input, YueHaibing

We should return 'retval' as the correct return value
instead of always zero.

Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/hid/hid-logitech-dj.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 41baa4dbbfcc..7f8db602eec0 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1133,7 +1133,7 @@ static int logi_dj_recv_query_hidpp_devices(struct dj_receiver_dev *djrcv_dev)
 				    HID_REQ_SET_REPORT);
 
 	kfree(hidpp_report);
-	return 0;
+	return retval;
 }
 
 static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
-- 
2.17.1

^ permalink raw reply related

* [PATCH -next] Input: synaptics-rmi4 - Remove set but not used variable 'sensor_flags'
From: YueHaibing @ 2019-05-25 14:11 UTC (permalink / raw)
  To: dmitry.torokhov, cheiny, nick; +Cc: linux-kernel, linux-input, YueHaibing

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/input/rmi4/rmi_f12.c: In function rmi_f12_read_sensor_tuning:
drivers/input/rmi4/rmi_f12.c:76:6: warning: variable sensor_flags set but not used [-Wunused-but-set-variable]

It's not used since introduction in
commit b43d2c1e9353 ("Input: synaptics-rmi4 - add support for F12")

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/input/rmi4/rmi_f12.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index 5c7f48915779..72b5498e1a9f 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -73,7 +73,6 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
 	int pitch_y = 0;
 	int rx_receivers = 0;
 	int tx_receivers = 0;
-	int sensor_flags = 0;
 
 	item = rmi_get_register_desc_item(&f12->control_reg_desc, 8);
 	if (!item) {
@@ -129,10 +128,8 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
 		offset += 2;
 	}
 
-	if (rmi_register_desc_has_subpacket(item, 4)) {
-		sensor_flags = buf[offset];
+	if (rmi_register_desc_has_subpacket(item, 4))
 		offset += 1;
-	}
 
 	sensor->x_mm = (pitch_x * rx_receivers) >> 12;
 	sensor->y_mm = (pitch_y * tx_receivers) >> 12;
-- 
2.17.1

^ permalink raw reply related

* [PATCH -next] Input: tca8418 - Remove set but not used variable ''
From: YueHaibing @ 2019-05-25 14:29 UTC (permalink / raw)
  To: dmitry.torokhov; +Cc: linux-kernel, linux-input, YueHaibing

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/input/keyboard/tca8418_keypad.c: In function tca8418_keypad_probe:
drivers/input/keyboard/tca8418_keypad.c:269:24: warning: variable max_keys set but not used [-Wunused-but-set-variable]

It's not used since commit 16ff7cb1848a ("Input:
tca8418-keypad - switch to using managed resources")

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/input/keyboard/tca8418_keypad.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/input/keyboard/tca8418_keypad.c b/drivers/input/keyboard/tca8418_keypad.c
index 6da607d3b811..3bbd7e652533 100644
--- a/drivers/input/keyboard/tca8418_keypad.c
+++ b/drivers/input/keyboard/tca8418_keypad.c
@@ -266,7 +266,7 @@ static int tca8418_keypad_probe(struct i2c_client *client,
 	struct tca8418_keypad *keypad_data;
 	struct input_dev *input;
 	u32 rows = 0, cols = 0;
-	int error, row_shift, max_keys;
+	int error, row_shift;
 	u8 reg;
 
 	/* Check i2c driver capabilities */
@@ -291,7 +291,6 @@ static int tca8418_keypad_probe(struct i2c_client *client,
 	}
 
 	row_shift = get_count_order(cols);
-	max_keys = rows << row_shift;
 
 	/* Allocate memory for keypad_data and input device */
 	keypad_data = devm_kzalloc(dev, sizeof(*keypad_data), GFP_KERNEL);
-- 
2.17.1

^ permalink raw reply related

* Re: [PATCH -next] Input: synaptics-rmi4 - Remove set but not used variable 'sensor_flags'
From: Dmitry Torokhov @ 2019-05-26 16:19 UTC (permalink / raw)
  To: YueHaibing; +Cc: cheiny, nick, linux-kernel, linux-input
In-Reply-To: <20190525141119.11852-1-yuehaibing@huawei.com>

On Sat, May 25, 2019 at 10:11:19PM +0800, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/input/rmi4/rmi_f12.c: In function rmi_f12_read_sensor_tuning:
> drivers/input/rmi4/rmi_f12.c:76:6: warning: variable sensor_flags set but not used [-Wunused-but-set-variable]
> 
> It's not used since introduction in
> commit b43d2c1e9353 ("Input: synaptics-rmi4 - add support for F12")
> 
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>

Applied, thank you.

> ---
>  drivers/input/rmi4/rmi_f12.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
> index 5c7f48915779..72b5498e1a9f 100644
> --- a/drivers/input/rmi4/rmi_f12.c
> +++ b/drivers/input/rmi4/rmi_f12.c
> @@ -73,7 +73,6 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
>  	int pitch_y = 0;
>  	int rx_receivers = 0;
>  	int tx_receivers = 0;
> -	int sensor_flags = 0;
>  
>  	item = rmi_get_register_desc_item(&f12->control_reg_desc, 8);
>  	if (!item) {
> @@ -129,10 +128,8 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
>  		offset += 2;
>  	}
>  
> -	if (rmi_register_desc_has_subpacket(item, 4)) {
> -		sensor_flags = buf[offset];
> +	if (rmi_register_desc_has_subpacket(item, 4))
>  		offset += 1;
> -	}
>  
>  	sensor->x_mm = (pitch_x * rx_receivers) >> 12;
>  	sensor->y_mm = (pitch_y * tx_receivers) >> 12;
> -- 
> 2.17.1
> 
> 

-- 
Dmitry

^ permalink raw reply

* Re: [PATCH -next] Input: tca8418 - Remove set but not used variable ''
From: Dmitry Torokhov @ 2019-05-26 16:19 UTC (permalink / raw)
  To: YueHaibing; +Cc: linux-kernel, linux-input
In-Reply-To: <20190525142921.18812-1-yuehaibing@huawei.com>

On Sat, May 25, 2019 at 10:29:21PM +0800, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/input/keyboard/tca8418_keypad.c: In function tca8418_keypad_probe:
> drivers/input/keyboard/tca8418_keypad.c:269:24: warning: variable max_keys set but not used [-Wunused-but-set-variable]
> 
> It's not used since commit 16ff7cb1848a ("Input:
> tca8418-keypad - switch to using managed resources")
> 
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>

Applied, thank you.

> ---
>  drivers/input/keyboard/tca8418_keypad.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/input/keyboard/tca8418_keypad.c b/drivers/input/keyboard/tca8418_keypad.c
> index 6da607d3b811..3bbd7e652533 100644
> --- a/drivers/input/keyboard/tca8418_keypad.c
> +++ b/drivers/input/keyboard/tca8418_keypad.c
> @@ -266,7 +266,7 @@ static int tca8418_keypad_probe(struct i2c_client *client,
>  	struct tca8418_keypad *keypad_data;
>  	struct input_dev *input;
>  	u32 rows = 0, cols = 0;
> -	int error, row_shift, max_keys;
> +	int error, row_shift;
>  	u8 reg;
>  
>  	/* Check i2c driver capabilities */
> @@ -291,7 +291,6 @@ static int tca8418_keypad_probe(struct i2c_client *client,
>  	}
>  
>  	row_shift = get_count_order(cols);
> -	max_keys = rows << row_shift;
>  
>  	/* Allocate memory for keypad_data and input device */
>  	keypad_data = devm_kzalloc(dev, sizeof(*keypad_data), GFP_KERNEL);
> -- 
> 2.17.1
> 
> 

-- 
Dmitry

^ permalink raw reply

* RE: [PATCH v2 08/10] Input: elan_i2c - export true width/height
From: 廖崇榮 @ 2019-05-27  3:55 UTC (permalink / raw)
  To: 'Benjamin Tissoires', 'Dmitry Torokhov',
	'Rob Herring', 'Aaron Ma',
	'Hans de Goede'
  Cc: 'open list:HID CORE LAYER', 'lkml', devicetree
In-Reply-To: <CAO-hwJJXGTZq7zRVhcFNwh-kOo0rUhZOsNtFX1yA93Km=L+ynA@mail.gmail.com>

Hi

-----Original Message-----
From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] 
Sent: Friday, May 24, 2019 5:37 PM
To: Dmitry Torokhov; KT Liao; Rob Herring; Aaron Ma; Hans de Goede
Cc: open list:HID CORE LAYER; lkml; devicetree@vger.kernel.org
Subject: Re: [PATCH v2 08/10] Input: elan_i2c - export true width/height

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?
I suggest you apply the patch, I have no idea why ETP_FWIDTH_REDUCE existed. 
Our FW team know nothing about ETP_FWIDTH_REDUCE ether.

The only side effect will happen on Chromebook because such computation have stayed in ChromeOS' kernel for four years.
Chrome's finger/palm threshold may be different from other Linux distribution.
We will discuss it with Google once the patch picked by chrome and cause something wrong.

Cheers,
Benjamin


>
>         data->input = input;
>
> --
> 2.21.0
>

^ permalink raw reply

* Re: [PATCH 1/3] ALSA: jack: Remove hard coding of jack_switch_types array size
From: Takashi Iwai @ 2019-05-27  7:41 UTC (permalink / raw)
  To: bgoswami
  Cc: alsa-devel, plai, Dmitry Torokhov, Gopikrishnaiah Anandan,
	broonie, srinivas.kandagatla, linux-input
In-Reply-To: <1558730423-16490-1-git-send-email-bgoswami@codeaurora.org>

On Fri, 24 May 2019 22:40:23 +0200,
<bgoswami@codeaurora.org> wrote:
> 
> From: Banajit Goswami <bgoswami@codeaurora.org>
> 
> The size for jack_switch_types array is currently controlled by
> a MACRO 'SND_JACK_SWITCH_TYPES', whose value needs to be updated
> everytime a new jack switch type is added. Remove this MACRO
> and use ARRAY_SIZE instead to get size of the array.
> 
> Signed-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>
> Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>

The changes in ALSA side (this one and patch 3) look good.

Rather a bigger question is about the addition of the new input bit.
This needs the review and ack from input subsystem people.

Adding to Cc.


thanks,

Takashi


> ---
>  include/sound/jack.h | 3 ---
>  sound/core/jack.c    | 4 ++--
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/include/sound/jack.h b/include/sound/jack.h
> index 1e84bfb..b0791c5 100644
> --- a/include/sound/jack.h
> +++ b/include/sound/jack.h
> @@ -68,9 +68,6 @@ enum snd_jack_types {
>  	SND_JACK_BTN_5		= 0x0200,
>  };
>  
> -/* Keep in sync with definitions above */
> -#define SND_JACK_SWITCH_TYPES 6
> -
>  struct snd_jack {
>  	struct list_head kctl_list;
>  	struct snd_card *card;
> diff --git a/sound/core/jack.c b/sound/core/jack.c
> index 84c2a17..36b047b 100644
> --- a/sound/core/jack.c
> +++ b/sound/core/jack.c
> @@ -33,7 +33,7 @@ struct snd_jack_kctl {
>  };
>  
>  #ifdef CONFIG_SND_JACK_INPUT_DEV
> -static int jack_switch_types[SND_JACK_SWITCH_TYPES] = {
> +static int jack_switch_types[] = {
>  	SW_HEADPHONE_INSERT,
>  	SW_MICROPHONE_INSERT,
>  	SW_LINEOUT_INSERT,
> @@ -250,7 +250,7 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
>  
>  		jack->type = type;
>  
> -		for (i = 0; i < SND_JACK_SWITCH_TYPES; i++)
> +		for (i = 0; i < ARRAY_SIZE(jack_switch_types); i++)
>  			if (type & (1 << i))
>  				input_set_capability(jack->input_dev, EV_SW,
>  						     jack_switch_types[i]);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> 

^ permalink raw reply

* Re: [PATCH 3/3] ALSA: jack: add switch event for unsupported jack types
From: Takashi Iwai @ 2019-05-27  7:43 UTC (permalink / raw)
  To: bgoswami
  Cc: alsa-devel, plai, Dmitry Torokhov, Gopikrishnaiah Anandan,
	broonie, srinivas.kandagatla, linux-input
In-Reply-To: <1558730450-16580-1-git-send-email-bgoswami@codeaurora.org>

On Fri, 24 May 2019 22:40:50 +0200,
<bgoswami@codeaurora.org> wrote:
> 
> From: Banajit Goswami <bgoswami@codeaurora.org>
> 
> Add a jack switch event to report unsupported plug type.
> This event can be used to report a headset or an extension
> cable with GND/MIC swap etc., which may not be supported by
> the device.
> 
> Signed-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>
> Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>

Adding input people to Cc to get the whole picture.


> ---
>  sound/core/jack.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/core/jack.c b/sound/core/jack.c
> index 36b047b..4c21e48 100644
> --- a/sound/core/jack.c
> +++ b/sound/core/jack.c
> @@ -40,6 +40,7 @@ struct snd_jack_kctl {
>  	SW_JACK_PHYSICAL_INSERT,
>  	SW_VIDEOOUT_INSERT,
>  	SW_LINEIN_INSERT,
> +	SW_UNSUPPORT_INSERT,
>  };
>  #endif /* CONFIG_SND_JACK_INPUT_DEV */
>  
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> 

^ permalink raw reply

* Re: [PATCH RESEND] input: adp5589: Add gpio_set_multiple interface
From: Togorean, Bogdan @ 2019-05-27  8:40 UTC (permalink / raw)
  To: dmitry.torokhov@gmail.com
  Cc: linux-input@vger.kernel.org, Hennerich, Michael,
	linux-kernel@vger.kernel.org, gustavo@embeddedor.com
In-Reply-To: <20190523071820.GA121292@dtor-ws>

Hi Dmitry,

Thank you for your review

On Thu, 2019-05-23 at 00:18 -0700, Dmitry Torokhov wrote:
> [External]
> 
> 
> Hi Bogdan,
> 
> On Tue, May 21, 2019 at 11:38:22AM +0300, Bogdan Togorean wrote:
> > 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;
> 
> I wonder if we should have:
> 
>         last_gpio = min(kpad->var->maxgpio, get_bitmask_order(*mask)
> - 1);
>         last_bank = kpad->var->bank(last_bank);
>         for (bank = 0; bank <= last_bank; bank++) {
>                 ...
>         }
I agree this can be made more clear in the way you proposed.
> 
> > +             reg_mask = mask[bank / sizeof(*mask)] >>
> > +                        ((bank % sizeof(*mask)) * BITS_PER_BYTE);
> > +             reg_bits = bits[bank / sizeof(*bits)] >>
> > +                        ((bank % sizeof(*bits)) * BITS_PER_BYTE);
> 
> This s really hard to parse. We know that "bank" is a byte, and mask
> is
> long, we do not have to be this roundabout it.
Here main reasons for doing this complexity were to support 64bit/32bit
architectures (differet long size) and to avoid use of magic values
(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]);
> > +     }
> 
> However the biggest issue is that this implementation seems to ignore
> the kpad->gpiomap that translates GPIO numbers as seen by gpiolib to
> GPIO numbers used by the chip. You need to reshuffle the mask and
> bits,
> and only then do the writes.
> 
> Given the complexities, does set_multiple really save anything?
> 
We have a critical application where we need to set multiple GPIOs that
are on the same bank simultaneously. No delay accepted. So this was the
usecase which led to implementation of set_multiple_interface for this
chip.
> Thanks.
> 
> --
> Dmitry
Thank you,
Bogdan


^ permalink raw reply

* [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: XiaoXiao Liu @ 2019-05-27  9:44 UTC (permalink / raw)
  To: dmitry.torokhov, pali.rohar
  Cc: peter.hutterer, hui.wang, linux-input, linux-kernel, xiaojian.cao,
	zhangfp1, xiaoxiao.liu-1, XiaoXiao Liu

The alps devices which detected to use the ALPS_PROTO_V8 procotol contains
ALPS touchpad and ALPS trackstick.The ALPS_PROTO_V8 procotol do not
support the trackstick device process by default.

When the trackstick was detected to use ALPS_PROTO_V8 procotol,
the v8 process_packet method alps_process_packet_ss4_v2 will reject to
report the data when the device using ALPS_PROTO_V8 procotol is not set
the ALPS_DUALPOINT flag.

The alps cs19 trackstick is detected to use the ALPS_PROTO_V8 procotol
but without ALPS_DUALPOINT flag, the alps driver will not report the
input data. so the trackstick will not work.

solution: when the alps cs19 device detected, set the device
ALPS_DUALPOINT flag,then the input data will be processed.

Signed-off-by: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
---
 drivers/input/mouse/alps.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 0a6f7ca883e7..a54677cf7474 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
  */
@@ -220,6 +220,23 @@ static bool alps_is_valid_first_byte(struct alps_data *priv,
 	return (data & priv->mask0) == priv->byte0;
 }
 
+static int alps_check_cs19_trackstick(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 && param[1] & 0x20) {
+		psmouse_warn(psmouse, "It is alps cs19 trackstick");
+		return 0;
+	}
+	return -1;
+}
+
 static void alps_report_buttons(struct input_dev *dev1, struct input_dev *dev2,
 				int left, int right, int middle)
 {
@@ -2568,8 +2585,12 @@ static int alps_update_dual_info_ss4_v2(unsigned char otp[][4],
 			alps_exit_command_mode(psmouse);
 			ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE);
 
-			if (reg_val == 0x0C || reg_val == 0x1D)
+			if (reg_val == 0x0C || reg_val == 0x1D) {
+				is_dual = true;
+			} else if (alps_check_cs19_trackstick(psmouse) == 0) {
+				//For support Thinkpad CS19 TrackStick
 				is_dual = true;
+			}
 		}
 	}
 
-- 
2.20.1

^ permalink raw reply related

* Re: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: Pali Rohár @ 2019-05-27 10:09 UTC (permalink / raw)
  To: XiaoXiao Liu
  Cc: dmitry.torokhov, peter.hutterer, hui.wang, linux-input,
	linux-kernel, xiaojian.cao, zhangfp1, xiaoxiao.liu-1
In-Reply-To: <20190527094422.7558-1-sliuuxiaonxiao@gmail.com>

Hi!

On Monday 27 May 2019 05:44:22 XiaoXiao Liu wrote:
> The alps devices which detected to use the ALPS_PROTO_V8 procotol contains
> ALPS touchpad and ALPS trackstick.The ALPS_PROTO_V8 procotol do not
> support the trackstick device process by default.

Normally PS/2 device handled by alps.c is touchpad and in some cases
touchpad sends also trackstick data in that one PS/2 channel.

Does it mean that your device (reported to kernel) sends only trackstick
packets and not touchpad?

> When the trackstick was detected to use ALPS_PROTO_V8 procotol,
> the v8 process_packet method alps_process_packet_ss4_v2 will reject to
> report the data when the device using ALPS_PROTO_V8 procotol is not set
> the ALPS_DUALPOINT flag.
> 
> The alps cs19 trackstick is detected to use the ALPS_PROTO_V8 procotol
> but without ALPS_DUALPOINT flag, the alps driver will not report the
> input data. so the trackstick will not work.
> 
> solution: when the alps cs19 device detected, set the device
> ALPS_DUALPOINT flag,then the input data will be processed.
> 
> Signed-off-by: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>
> ---
>  drivers/input/mouse/alps.c | 25 +++++++++++++++++++++++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index 0a6f7ca883e7..a54677cf7474 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
>   */
> @@ -220,6 +220,23 @@ static bool alps_is_valid_first_byte(struct alps_data *priv,
>  	return (data & priv->mask0) == priv->byte0;
>  }
>  
> +static int alps_check_cs19_trackstick(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 && param[1] & 0x20) {

I guess that you want parenthesis around (param[1] & 0x20). And also
describe what that 0x20 constant means.

> +		psmouse_warn(psmouse, "It is alps cs19 trackstick");

It is not a warning.

> +		return 0;
> +	}
> +	return -1;
> +}
> +
>  static void alps_report_buttons(struct input_dev *dev1, struct input_dev *dev2,
>  				int left, int right, int middle)
>  {
> @@ -2568,8 +2585,12 @@ static int alps_update_dual_info_ss4_v2(unsigned char otp[][4],
>  			alps_exit_command_mode(psmouse);
>  			ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE);
>  
> -			if (reg_val == 0x0C || reg_val == 0x1D)
> +			if (reg_val == 0x0C || reg_val == 0x1D) {

Hm... why your device does not match these constants?

> +				is_dual = true;
> +			} else if (alps_check_cs19_trackstick(psmouse) == 0) {
> +				//For support Thinkpad CS19 TrackStick
>  				is_dual = true;
> +			}
>  		}
>  	}
>  

-- 
Pali Rohár
pali.rohar@gmail.com

^ permalink raw reply

* INFO: trying to register non-static key in usbtouch_reset_resume
From: syzbot @ 2019-05-27 11:38 UTC (permalink / raw)
  To: andreyknvl, dmitry.torokhov, linux-input, linux-kernel, linux-usb,
	rydberg, syzkaller-bugs

Hello,

syzbot found the following crash on:

HEAD commit:    43151d6c usb-fuzzer: main usb gadget fuzzer driver
git tree:       https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=14a2b45ca00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=95aff7278e7ff25e
dashboard link: https://syzkaller.appspot.com/bug?extid=933daad9be4e67ba91a9
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1776669aa00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+933daad9be4e67ba91a9@syzkaller.appspotmail.com

usb 1-1: config 0 descriptor??
usb 1-1: string descriptor 0 read error: -71
hub 1-1:0.189: ignoring external hub
input: USB Touchscreen 08f2:007f as  
/devices/platform/dummy_hcd.0/usb1/1-1/1-1:0.189/input/input6
usb 1-1: reset high-speed USB device number 3 using dummy_hcd
usb 1-1: Using ep0 maxpacket: 8
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc3+ #8
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0xca/0x13e lib/dump_stack.c:113
  assign_lock_key kernel/locking/lockdep.c:786 [inline]
  register_lock_class+0x11ae/0x1240 kernel/locking/lockdep.c:1095
  __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
  lock_acquire+0x100/0x2b0 kernel/locking/lockdep.c:4211
  __mutex_lock_common kernel/locking/mutex.c:925 [inline]
  __mutex_lock+0xf9/0x12b0 kernel/locking/mutex.c:1072
  usbtouch_reset_resume+0xb3/0x170  
drivers/input/touchscreen/usbtouchscreen.c:1624
  usb_resume_interface drivers/usb/core/driver.c:1242 [inline]
  usb_resume_interface.isra.0+0x187/0x3a0 drivers/usb/core/driver.c:1210
  usb_resume_both+0x23d/0x780 drivers/usb/core/driver.c:1412
  __rpm_callback+0x287/0x3c0 drivers/base/power/runtime.c:357
  rpm_callback+0x18f/0x230 drivers/base/power/runtime.c:487
  rpm_resume+0x10c2/0x1840 drivers/base/power/runtime.c:851
  __pm_runtime_resume+0x103/0x180 drivers/base/power/runtime.c:1078
  pm_runtime_get_sync include/linux/pm_runtime.h:227 [inline]
  usb_autoresume_device+0x1e/0x60 drivers/usb/core/driver.c:1599
  usb_remote_wakeup+0x7b/0xb0 drivers/usb/core/hub.c:3600
  hub_port_connect_change drivers/usb/core/hub.c:5190 [inline]
  port_event drivers/usb/core/hub.c:5350 [inline]
  hub_event+0x23c9/0x35a0 drivers/usb/core/hub.c:5432
  process_one_work+0x90a/0x1580 kernel/workqueue.c:2269
  process_scheduled_works kernel/workqueue.c:2331 [inline]
  worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417
  kthread+0x30e/0x420 kernel/kthread.c:253
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
dummy_hcd dummy_hcd.0: port status 0x00010100 has changes
usb 1-1: USB disconnect, device number 3
usb usb1: dummy_bus_suspend
usb usb1: dummy_bus_resume
dummy_hcd dummy_hcd.0: port status 0x00010101 has changes
dummy_hcd dummy_hcd.0: port status 0x00100503 has changes
usb 1-1: new high-speed USB device number 4 using dummy_hcd
dummy_hcd dummy_hcd.0: port status 0x00100503 has changes
usb 1-1: Using ep0 maxpacket: 8
usb 1-1: config 0 has an invalid interface number: 189 but max is 0
usb 1-1: config 0 has an invalid descriptor of length 0, skipping remainder  
of the config
usb 1-1: config 0 has no interface number 0
usb 1-1: config 0 interface 189 altsetting 0 endpoint 0x82 has an invalid  
bInterval 0, changing to 7
usb 1-1: New USB device found, idVendor=08f2, idProduct=007f,  
bcdDevice=97.17
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
usb 1-1: string descriptor 0 read error: -71
hub 1-1:0.189: ignoring external hub
input: USB Touchscreen 08f2:007f as  
/devices/platform/dummy_hcd.0/usb1/1-1/1-1:0.189/input/input7
dummy_hcd dummy_hcd.0: port status 0x00010101 has changes
dummy_hcd dummy_hcd.0: port status 0x00010101 has changes
dummy_hcd dummy_hcd.0: port status 0x00100503 has changes
usb 1-1: reset high-speed USB device number 4 using dummy_hcd
dummy_hcd dummy_hcd.0: port status 0x00100503 has changes
usb 1-1: Using ep0 maxpacket: 8
usb usb1: dummy_bus_suspend
usb usb1: dummy_bus_resume
dummy_hcd dummy_hcd.0: port status 0x00010100 has changes
usb 1-1: USB disconnect, device number 6
usb usb1: dummy_bus_suspend
usb usb1: dummy_bus_resume
dummy_hcd dummy_hcd.0: port status 0x00010101 has changes
dummy_hcd dummy_hcd.0: port status 0x00100503 has changes
usb 1-1: new high-speed USB device number 7 using dummy_hcd
dummy_hcd dummy_hcd.0: port status 0x00100503 has changes
usb 1-1: Using ep0 maxpacket: 8
usb 1-1: config 0 has an invalid interface number: 189 but max is 0
usb 1-1: config 0 has an invalid descriptor of length 0, skipping remainder  
of the config
usb 1-1: config 0 has no interface number 0
usb 1-1: config 0 interface 189 altsetting 0 endpoint 0x82 has an invalid  
bInterval 0, changing to 7
usb 1-1: New USB device found, idVendor=08f2, idProduct=007f,  
bcdDevice=97.17
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
usb 1-1: string descriptor 0 read error: -71
hub 1-1:0.189: ignoring external hub
input: USB Touchscreen 08f2:007f as  
/devices/platform/dummy_hcd.0/usb1/1-1/1-1:0.189/input/input10
dummy_hcd dummy_hcd.0: port status 0x00010101 has changes
dummy_hcd dummy_hcd.0: port status 0x00010101 has changes
dummy_hcd dummy_hcd.0: port status 0x00100503 has changes
usb 1-1: reset high-speed USB device number 7 using dummy_hcd
dummy_hcd dummy_hcd.0: port status 0x00100503 has changes
usb 1-1: Using ep0 maxpacket: 8
usb usb1: dummy_bus_suspend


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox