Re: ideapad-laptop touchpad handling problems, request for help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 11/10/22 17:42, Eray Orçunus wrote:
> Hi Hans,
> 
> On 10 Nov 2022 at 15:37, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
>> On 11/10/22 13:00, Eray Orçunus wrote:
>>> While I agree with your findings(and thanks for your effort, I also tried
>>> to solve this but later gave up), they doesn't apply to one type of
>>> IdeaPads (like my 520-15IKB), so I'm sure this patch won't work on me.
>>> This is because my IdeaPad has this features:
>>>
>>> - i8042.noaux doesn't affect touchpad, and it's connected over i2c
>>> - There is no touchpad LED, and touchpad hotkey only sends "key pressed"
>>>   ACPI event, doesn't do anything else
>>> - VPCCMD_W_TOUCHPAD does nothing (also confirmed on Windows)
>>> - Sending 1 to VPCCMD_W_TOUCHPAD on boot is not needed
>>> - VPCCMD_R_TOUCHPAD always returns 1 (this is interesting)
>>
>> So if i8042.noaux does not do anything, then why do you want to add
>> "SYNA2B33" to the list of ACPI HIDs for which we set:
>>
>> features.touchpad_ctrl_via_ec=0;
>>
>> ?
>>
>> IOW what bad effects / behavior are you seeing with touchpad_ctrl_via_ec=1?
>>
>> Or are you seeing bad behavior on some other modes? If yes, then what
>> is the bad behavior you are seeing on other models ?
> 
> It was just because I didn't want to have a not working "touchpad"
> attribute :) I used/still using several GNOME extensions and they show
> me "Touchpad" toggle just because I have "touchpad" attribute exposed
> there, which is doing nothing, and misleading.

So you are using a gnome-shell extension specifically for ideapads,
which actually uses the sysfs attributes registered by the ideapad-laptop
driver?

I did not expect that. My plan is to pretty much not care about if
the touchpad sysfs attribute works and just document that it may
not work on newer ideapad models.

I believe that the best fix for the ideapad specific extension
might be to just file a bug against the extension and ask it
to remove the touchpad on/off support.

gnome already has a prefectly working touchpad on/off toggle
on the normal control-panel so it is not like removing the
ideapad specific one will cause any loss of functionality.

> But I would understand if you don't want to touch it at that stage, and
> you would rather prefer not working "touchpad" attributes to not
> exposed "touchpad" attributes that would have been perfectly working.

>> I'm guessing that this part:
>>
>>                 unsigned char param;
>>                 /*
>>                  * Some IdeaPads don't really turn off touchpad - they only
>>                  * switch the LED state. We (de)activate KBC AUX port to turn
>>                  * touchpad off and on. We send KEY_TOUCHPAD_OFF and
>>                  * KEY_TOUCHPAD_ON to not to get out of sync with LED
>>                  */
>>                 i8042_command(&param, value ? I8042_CMD_AUX_ENABLE : I8042_CMD_AUX_DISABLE);
>>
>> May cause issues on some models. It definitely feels fishy and
>> I would like to disable this except on models where:
>>
>> 1. There is a LED controlled by some touchpad on/off hotkey; and
>> 2. The EC fails to disable the touchpad itself
>>
>> Which would currently mean only enable this bit on Maxim's Z570
>> using a DMI based allow list.
> 
> Agreed, but do you mean "and" or "or"? I mean we can also include the
> models that toggle touchpad value while not really toggling the touchpad
> (just as you described below) and don't have a touchpad LED (but I don't
> know if such model exists really), this way they won't go out of sync
> regardless of is there a touchpad LED or not.

I meant "and" since I was talking about the Z570.

But you are right that if there are other models which do toggle
the value returned when reading from VPCCMD_R_TOUCHPAD, but don't
actually turn the touchpad on/off, that those then will also need
ideapad-laptop to control the ps2 aux port.


>> At least on Maxim's Z570 the laptop does toggle the value
>> returned by VPCCMD_R_TOUCHPAD and the LED it self, while at the
>> same time not actually disabling the touchpad.
>> The problem is this all relies on being able to detect i2c vs ps/2
>> touchpads which is not as simple as it sounds. Specifically many
>> new touchpad are connected to both busses at the same time, offering
>> a ps/2 mode by default for compatibility with older software / os-es
>> and being able to switch to a modern i2c/smbus mode for better performance.
>>
>> I've asked Benjamin Tissoires, the kernel expert on this about this
>> and his answer was that it is almost impossible to determine if
>> a touchpad is going to be using ps/2 or i2c without first waiting
>> for the whole driver stack to have initialized and then see which
>> driver(s) are attached and I guess even then the touchpad might
>> show up as both ps/2 + i2c with only one of them actually generating
>> events:
>>
>> https://lore.kernel.org/linux-input/ae50236e-1ce8-b526-9c17-7bc0463ebb86@xxxxxxxxxx/T/#u
>>
>> So based on Benjamin's answer I'm afraid that trying to differentiate
>> between i2c vs ps2 is not really doable.
> 
> Thanks for the explanation and the link, but as Benjamin said, I believe
> we can use ACPI table for detecting PS/2 devices. I believe the DSDTs
> with PS2M(and probably MSS[0-9] too) devices probably have PS/2 touchpad,
> and have working EC and i8042 commands. Yet this still needs
> confirmation/testing, and I think should be resorted if your suggestion
> below won't work - your suggestion looks better and easier.

I don't think there are any guarantees that models with touchpads
which support both ps2 + i2c mode won't have the PS2M or MSS[0-9]
devices, especially since the ps2 support is there to e.g. have
a working mouse in the Windows installer before a touchpad specific
i2c driver is loaded / available.  And the windows installer likely
needs the ACPI ps/2 devices to detect the touchpad ...


>> 1: Fixing undesirable i8042_command(... I8042_CMD_AUX_DISABLE) calls
>> --------------------------------------------------------------------
>>
>> My suggestion is to move to an allow-list for this and for now
>> populate that list with only the DMI strings for Maxim's Z570 and see
>> from there.
> 
> Agreed.
> 
>>
>> 2: Fixing wrong/spurious KEY_TOUCHPAD_OFF / KEY_TOUCHPAD_ON events
>> ------------------------------------------------------------------
>>
>> There are 2 subcases here:
>>
>> 2.1: Fix sending of KEY_TOUCHPAD_OFF/_ON events at probe/resume
>> ---------------------------------------------------------------
>>
>> We can simply fix this by giving ideapad_sync_touchpad_state()
>> a parameter to let it know if events should be send at all and
>> set that parameter to false when called on probe/resume
> 
> Agreed.
> 
>> 2.2: Sending wrong KEY_TOUCHPAD_OFF/_ON events at toggle time
>> -------------------------------------------------------------
>>
>> On models where the EC does not control the touchpad at all,
>> currently we still do ideapad_sync_touchpad_state() and then
>> send either KEY_TOUCHPAD_OFF or _ON based on the value read
>> from VPCCMD_R_TOUCHPAD.
>>
>> But on these models VPCCMD_R_TOUCHPAD always returns 0 or 1,
>> so we always send KEY_TOUCHPAD_OFF or always send KEY_TOUCHPAD_ON,
>> instead of toggling the state / asking userspace to toggle
>> its sw touchpad on/off state.
>>
>> I believe we can detect this case by checking that
>> the value read from VPCCMD_R_TOUCHPAD has not changed
>> despite us receiving a notify with bit 5 being set in
>> the value read from VPCCMD_R_VPC1.
>>
>> My suggestion to fix this case is to detect when the value
>> read from VPCCMD_R_TOUCHPAD does not change and in that
>> case send KEY_TOUCHPAD_TOGGLE to userspace.
> 
> While this is an awesome idea, what about doing this at boot?
> Like we will send 0 first, then check if it reads 0, then send 1,
> and confirm if it reads 1. This would be the ultimate solution, and
> would also fix my "cosmetic" concerns :)

Ok, I've attached a patch series implementing this, please let me
know what you think; and if possible please test this.

Regards,

Hans


From 47f03d8d93e3b1319f6477357755147cb7ff45b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Eray=20Or=C3=A7unus?= <erayorcunus@xxxxxxxxx>
Date: Sat, 29 Oct 2022 15:03:06 +0300
Subject: [PATCH 1/4] platform/x86: ideapad-laptop: Revert "check for touchpad
 support in _CFG"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Last 8 bit of _CFG started being used in later IdeaPads, thus 30th bit
doesn't always show whether device supports touchpad or touchpad switch.
Remove checking bit 30 of _CFG, so older IdeaPads like S10-3 can switch
touchpad again via touchpad attribute.

This reverts commit b3ed1b7fe378 ("platform/x86: ideapad-laptop: check for
touchpad support in _CFG").

Signed-off-by: Eray Orçunus <erayorcunus@xxxxxxxxx>
Link: https://lore.kernel.org/r/20221029120311.11152-2-erayorcunus@xxxxxxxxx
Reviewed-by: Hans de Goede <hdegoede@xxxxxxxxxx>
Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
---
 drivers/platform/x86/ideapad-laptop.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c
index 33b3dfdd1b08..870c6f4c4245 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -46,11 +46,10 @@ static const char *const ideapad_wmi_fnesc_events[] = {
 #endif
 
 enum {
-	CFG_CAP_BT_BIT       = 16,
-	CFG_CAP_3G_BIT       = 17,
-	CFG_CAP_WIFI_BIT     = 18,
-	CFG_CAP_CAM_BIT      = 19,
-	CFG_CAP_TOUCHPAD_BIT = 30,
+	CFG_CAP_BT_BIT   = 16,
+	CFG_CAP_3G_BIT   = 17,
+	CFG_CAP_WIFI_BIT = 18,
+	CFG_CAP_CAM_BIT  = 19,
 };
 
 enum {
@@ -371,8 +370,6 @@ static int debugfs_cfg_show(struct seq_file *s, void *data)
 		seq_puts(s, " wifi");
 	if (test_bit(CFG_CAP_CAM_BIT, &priv->cfg))
 		seq_puts(s, " camera");
-	if (test_bit(CFG_CAP_TOUCHPAD_BIT, &priv->cfg))
-		seq_puts(s, " touchpad");
 	seq_puts(s, "\n");
 
 	seq_puts(s, "Graphics: ");
@@ -665,8 +662,7 @@ static umode_t ideapad_is_visible(struct kobject *kobj,
 	else if (attr == &dev_attr_fn_lock.attr)
 		supported = priv->features.fn_lock;
 	else if (attr == &dev_attr_touchpad.attr)
-		supported = priv->features.touchpad_ctrl_via_ec &&
-			    test_bit(CFG_CAP_TOUCHPAD_BIT, &priv->cfg);
+		supported = priv->features.touchpad_ctrl_via_ec;
 	else if (attr == &dev_attr_usb_charging.attr)
 		supported = priv->features.usb_charging;
 
-- 
2.37.3

From cb8b3117193ffa89a9ba1971640f37f032a6f2ed Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@xxxxxxxxxx>
Date: Thu, 10 Nov 2022 17:00:00 +0100
Subject: [PATCH 2/4] platform/x86: ideapad-laptop: Refactor
 ideapad_sync_touchpad_state()

Add an error exit for read_ec_data() failing instead of putting the main
body in an if (success) block.

Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
---
 drivers/platform/x86/ideapad-laptop.c | 27 +++++++++++++++------------
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c
index 870c6f4c4245..7ab638069df9 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -1398,23 +1398,26 @@ static void ideapad_kbd_bl_exit(struct ideapad_private *priv)
 static void ideapad_sync_touchpad_state(struct ideapad_private *priv)
 {
 	unsigned long value;
+	unsigned char param;
+	int ret;
 
 	if (!priv->features.touchpad_ctrl_via_ec)
 		return;
 
 	/* Without reading from EC touchpad LED doesn't switch state */
-	if (!read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, &value)) {
-		unsigned char param;
-		/*
-		 * Some IdeaPads don't really turn off touchpad - they only
-		 * switch the LED state. We (de)activate KBC AUX port to turn
-		 * touchpad off and on. We send KEY_TOUCHPAD_OFF and
-		 * KEY_TOUCHPAD_ON to not to get out of sync with LED
-		 */
-		i8042_command(&param, value ? I8042_CMD_AUX_ENABLE : I8042_CMD_AUX_DISABLE);
-		ideapad_input_report(priv, value ? 67 : 66);
-		sysfs_notify(&priv->platform_device->dev.kobj, NULL, "touchpad");
-	}
+	ret = read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, &value);
+	if (ret)
+		return;
+
+	/*
+	 * Some IdeaPads don't really turn off touchpad - they only
+	 * switch the LED state. We (de)activate KBC AUX port to turn
+	 * touchpad off and on. We send KEY_TOUCHPAD_OFF and
+	 * KEY_TOUCHPAD_ON to not to get out of sync with LED
+	 */
+	i8042_command(&param, value ? I8042_CMD_AUX_ENABLE : I8042_CMD_AUX_DISABLE);
+	ideapad_input_report(priv, value ? 67 : 66);
+	sysfs_notify(&priv->platform_device->dev.kobj, NULL, "touchpad");
 }
 
 static void ideapad_acpi_notify(acpi_handle handle, u32 event, void *data)
-- 
2.37.3

From 93103ff85ce83f4a21973ee26ba50319f5f8236b Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@xxxxxxxxxx>
Date: Thu, 10 Nov 2022 17:03:46 +0100
Subject: [PATCH 3/4] platform/x86: ideapad-laptop: Do not send KEY_TOUCHPAD*
 events on probe / resume

The sending of KEY_TOUCHPAD* events is causing spurious touchpad OSD
showing on resume.

Disable the sending of events on probe / resume to fix this.

Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
---
 drivers/platform/x86/ideapad-laptop.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c
index 7ab638069df9..0535bb602eee 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -1395,7 +1395,7 @@ static void ideapad_kbd_bl_exit(struct ideapad_private *priv)
 /*
  * module init/exit
  */
-static void ideapad_sync_touchpad_state(struct ideapad_private *priv)
+static void ideapad_sync_touchpad_state(struct ideapad_private *priv, bool send_events)
 {
 	unsigned long value;
 	unsigned char param;
@@ -1416,8 +1416,11 @@ static void ideapad_sync_touchpad_state(struct ideapad_private *priv)
 	 * KEY_TOUCHPAD_ON to not to get out of sync with LED
 	 */
 	i8042_command(&param, value ? I8042_CMD_AUX_ENABLE : I8042_CMD_AUX_DISABLE);
-	ideapad_input_report(priv, value ? 67 : 66);
-	sysfs_notify(&priv->platform_device->dev.kobj, NULL, "touchpad");
+
+	if (send_events) {
+		ideapad_input_report(priv, value ? 67 : 66);
+		sysfs_notify(&priv->platform_device->dev.kobj, NULL, "touchpad");
+	}
 }
 
 static void ideapad_acpi_notify(acpi_handle handle, u32 event, void *data)
@@ -1458,7 +1461,7 @@ static void ideapad_acpi_notify(acpi_handle handle, u32 event, void *data)
 			ideapad_sync_rfk_state(priv);
 			break;
 		case 5:
-			ideapad_sync_touchpad_state(priv);
+			ideapad_sync_touchpad_state(priv, true);
 			break;
 		case 4:
 			ideapad_backlight_notify_brightness(priv);
@@ -1645,7 +1648,7 @@ static int ideapad_acpi_add(struct platform_device *pdev)
 			ideapad_register_rfkill(priv, i);
 
 	ideapad_sync_rfk_state(priv);
-	ideapad_sync_touchpad_state(priv);
+	ideapad_sync_touchpad_state(priv, false);
 
 	err = ideapad_dytc_profile_init(priv);
 	if (err) {
@@ -1747,7 +1750,7 @@ static int ideapad_acpi_resume(struct device *dev)
 	struct ideapad_private *priv = dev_get_drvdata(dev);
 
 	ideapad_sync_rfk_state(priv);
-	ideapad_sync_touchpad_state(priv);
+	ideapad_sync_touchpad_state(priv, false);
 
 	if (priv->dytc)
 		dytc_profile_refresh(priv);
-- 
2.37.3

From b4833f5308a0e90afc0ef4a6ec57b804a89c4a87 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@xxxxxxxxxx>
Date: Thu, 10 Nov 2022 19:37:26 +0100
Subject: [PATCH 4/4] platform/x86: ideapad-laptop: Rework touchpad control
 code
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Recently there have been multiple patches to disable the ideapad-laptop's
touchpad control code, because it is causing issues on various laptops,
see the Fixes tags for this commit.

The turning on/off of the ps2 aux port was added specifically for
the IdeaPad Z570, where the EC does toggle the touchpad on/off LED and
toggles the value returned by reading VPCCMD_R_TOUCHPAD, but it does not
actually turn on/off the touchpad.

The ideapad-laptop code really should not be messing with the i8042
controller on all devices just for this special case.

Drop the touchpad_ctrl_via_ec flag and add a DMI based allow-list for
devices which need this workaround, populating it with just the
Ideapad Z570 for now.

A related problem is that on recent Ideapad models the EC does not control
the touchpad at all. Check for this by checking if the value read from
VPCCMD_R_TOUCHPAD actually changes when receiving a touchpad-toggle hotkey
event; and if it does not change send KEY_TOUCHPAD_TOGGLE to userspace to
let userspace enable/disable the touchpad in software.

Fixes: d69cd7eea93e ("platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634")
Fixes: a231224a601c ("platform/x86: ideapad-laptop: Disable touchpad_switch")
Cc: Maxim Mikityanskiy <maxtram95@xxxxxxxxx>
Cc: GOESSEL Guillaume <g_goessel@xxxxxxxxxxx>
Cc: Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx>
Cc: Manyi Li <limanyi@xxxxxxxxxxxxx>
Cc: Eray Orçunus <erayorcunus@xxxxxxxxx>
Cc: Ike Panhc <ike.pan@xxxxxxxxxxxxx>
Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
---
 drivers/platform/x86/ideapad-laptop.c | 56 +++++++++++----------------
 1 file changed, 23 insertions(+), 33 deletions(-)

diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c
index 0535bb602eee..a529ebc26e5e 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -129,6 +129,7 @@ struct ideapad_private {
 	struct ideapad_dytc_priv *dytc;
 	struct dentry *debug;
 	unsigned long cfg;
+	unsigned long r_touchpad_val;
 	const char *fnesc_guid;
 	struct {
 		bool conservation_mode    : 1;
@@ -137,8 +138,8 @@ struct ideapad_private {
 		bool fn_lock              : 1;
 		bool hw_rfkill_switch     : 1;
 		bool kbd_bl               : 1;
-		bool touchpad_ctrl_via_ec : 1;
 		bool usb_charging         : 1;
+		bool ctrl_ps2_aux_port    : 1;
 	} features;
 	struct {
 		bool initialized;
@@ -661,8 +662,6 @@ static umode_t ideapad_is_visible(struct kobject *kobj,
 		supported = priv->features.fan_mode;
 	else if (attr == &dev_attr_fn_lock.attr)
 		supported = priv->features.fn_lock;
-	else if (attr == &dev_attr_touchpad.attr)
-		supported = priv->features.touchpad_ctrl_via_ec;
 	else if (attr == &dev_attr_usb_charging.attr)
 		supported = priv->features.usb_charging;
 
@@ -1082,6 +1081,7 @@ static const struct key_entry ideapad_keymap[] = {
 	{ KE_KEY,  65, { KEY_PROG4 } },
 	{ KE_KEY,  66, { KEY_TOUCHPAD_OFF } },
 	{ KE_KEY,  67, { KEY_TOUCHPAD_ON } },
+	{ KE_KEY,  68, { KEY_TOUCHPAD_TOGGLE } },
 	{ KE_KEY, 128, { KEY_ESC } },
 	{ KE_END },
 };
@@ -1401,9 +1401,6 @@ static void ideapad_sync_touchpad_state(struct ideapad_private *priv, bool send_
 	unsigned char param;
 	int ret;
 
-	if (!priv->features.touchpad_ctrl_via_ec)
-		return;
-
 	/* Without reading from EC touchpad LED doesn't switch state */
 	ret = read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, &value);
 	if (ret)
@@ -1412,15 +1409,26 @@ static void ideapad_sync_touchpad_state(struct ideapad_private *priv, bool send_
 	/*
 	 * Some IdeaPads don't really turn off touchpad - they only
 	 * switch the LED state. We (de)activate KBC AUX port to turn
-	 * touchpad off and on. We send KEY_TOUCHPAD_OFF and
-	 * KEY_TOUCHPAD_ON to not to get out of sync with LED
+	 * the touchpad on and off.
 	 */
-	i8042_command(&param, value ? I8042_CMD_AUX_ENABLE : I8042_CMD_AUX_DISABLE);
+	if (priv->features.ctrl_ps2_aux_port)
+		i8042_command(&param, value ? I8042_CMD_AUX_ENABLE : I8042_CMD_AUX_DISABLE);
 
 	if (send_events) {
-		ideapad_input_report(priv, value ? 67 : 66);
-		sysfs_notify(&priv->platform_device->dev.kobj, NULL, "touchpad");
+		/*
+		 * On older models the EC controls the touchpad and toggles it
+		 * on/off itself, in this case we report KEY_TOUCHPAD_ON/_OFF.
+		 * If the EC did not toggle, report KEY_TOUCHPAD_TOGGLE.
+		 */
+		if (value != priv->r_touchpad_val) {
+			ideapad_input_report(priv, value ? 67 : 66);
+			sysfs_notify(&priv->platform_device->dev.kobj, NULL, "touchpad");
+		} else {
+			ideapad_input_report(priv, 68);
+		}
 	}
+
+	priv->r_touchpad_val = value;
 }
 
 static void ideapad_acpi_notify(acpi_handle handle, u32 event, void *data)
@@ -1535,19 +1543,12 @@ static const struct dmi_system_id hw_rfkill_list[] = {
 	{}
 };
 
-static const struct dmi_system_id no_touchpad_switch_list[] = {
-	{
-	.ident = "Lenovo Yoga 3 Pro 1370",
-	.matches = {
-		DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-		DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 3"),
-		},
-	},
+static const struct dmi_system_id ctrl_ps2_aux_port_list[] = {
 	{
-	.ident = "ZhaoYang K4e-IML",
+	/* Lenovo Ideapad Z570 */
 	.matches = {
 		DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-		DMI_MATCH(DMI_PRODUCT_VERSION, "ZhaoYang K4e-IML"),
+		DMI_MATCH(DMI_PRODUCT_VERSION, "Ideapad Z570"),
 		},
 	},
 	{}
@@ -1559,14 +1560,7 @@ static void ideapad_check_features(struct ideapad_private *priv)
 	unsigned long val;
 
 	priv->features.hw_rfkill_switch = dmi_check_system(hw_rfkill_list);
-
-	/* Most ideapads with ELAN0634 touchpad don't use EC touchpad switch */
-	if (acpi_dev_present("ELAN0634", NULL, -1))
-		priv->features.touchpad_ctrl_via_ec = 0;
-	else if (dmi_check_system(no_touchpad_switch_list))
-		priv->features.touchpad_ctrl_via_ec = 0;
-	else
-		priv->features.touchpad_ctrl_via_ec = 1;
+	priv->features.ctrl_ps2_aux_port = dmi_check_system(ctrl_ps2_aux_port_list);
 
 	if (!read_ec_data(handle, VPCCMD_R_FAN, &val))
 		priv->features.fan_mode = true;
@@ -1639,10 +1633,6 @@ static int ideapad_acpi_add(struct platform_device *pdev)
 	if (!priv->features.hw_rfkill_switch)
 		write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1);
 
-	/* The same for Touchpad */
-	if (!priv->features.touchpad_ctrl_via_ec)
-		write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1);
-
 	for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
 		if (test_bit(ideapad_rfk_data[i].cfgbit, &priv->cfg))
 			ideapad_register_rfkill(priv, i);
-- 
2.37.3


[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux