Hi Dmitry,

I have a bugreport about Synaptics touchpad not working as proper 
Synaptics, but only being detected as standard PS/2.

Looking at the i8042.debug output, the device is clearly buggy, as it 
doesn't identify itself by 0x47 when queried:

	91 -> i8042 (command) [58]
	e8 -> i8042 (parameter) [58]
	fa <- i8042 (interrupt, 3, 12) [59]
	91 -> i8042 (command) [59]
	00 -> i8042 (parameter) [59]
	fa <- i8042 (interrupt, 3, 12) [59]
	91 -> i8042 (command) [59]
	e8 -> i8042 (parameter) [59]
	fa <- i8042 (interrupt, 3, 12) [60]
	91 -> i8042 (command) [60]
	00 -> i8042 (parameter) [60]
	fa <- i8042 (interrupt, 3, 12) [61]
	91 -> i8042 (command) [61]
	e8 -> i8042 (parameter) [61]
	fa <- i8042 (interrupt, 3, 12) [61]
	91 -> i8042 (command) [61]
	00 -> i8042 (parameter) [61]
	fa <- i8042 (interrupt, 3, 12) [62]
	91 -> i8042 (command) [62]
	e8 -> i8042 (parameter) [62]
	fa <- i8042 (interrupt, 3, 12) [63]
	91 -> i8042 (command) [63]
	00 -> i8042 (parameter) [63]
	fa <- i8042 (interrupt, 3, 12) [64]
	91 -> i8042 (command) [64]
	e9 -> i8042 (parameter) [64]
	fa <- i8042 (interrupt, 3, 12) [64]

... and here we time out after approximately 0.5s. nomux doesn't really 
fix it, we start getting a lot of timeouts on i8042 with that.

Apparently the device works with Synaptics driver in Other OS(TM) though. 
Do you have any idea what they might be doing differently so that they 
make the touchpad identify itself properly?

https://bugzilla.kernel.org/show_bug.cgi?id=15416 seems to be related BTW.

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--

[ message continues ]

Hi Jiri,

Do you have the device in your possession? If so can you check if the
driver installed in Other OS uses active multiplexing? I think you can
infer whether it does or not by looking at the pointer properties - I
think it would "Synaptics Blah at port X" or something like that...

Also you could try combining nomux with reset and see if it makes any
sense...

Thanks.

-- 
Dmitry
--

[ message continues ]

Unfortunately I don't have the hardware myself, it's only bugreport that 

Yes, I have already had the reporter to do this, but that's even better -- 
a lot of commands time out, as you can see below

 20 -> i8042 (command) [0]
 47 <- i8042 (return) [0]
 20 -> i8042 (command) [0]
 47 <- i8042 (return) [0]
 60 -> i8042 (command) [0]
 56 -> i8042 (parameter) [0]
 d3 -> i8042 (command) [0]
 5a -> i8042 (parameter) [0]
 5a <- i8042 (return) [0]
 a7 -> i8042 (command) [0]
 20 -> i8042 (command) [0]
 76 <- i8042 (return) [0]
 a8 -> i8042 (command) [0]
 20 -> i8042 (command) [0]
 56 <- i8042 (return) [0]
 60 -> i8042 (command) [0]
 56 -> i8042 (parameter) [0]
 d3 -> i8042 (command) [0]
 a5 -> i8042 (parameter) [0]
 a5 <- i8042 (aux_test_irq, aux) [1]
 60 -> i8042 (command) [1]
 74 -> i8042 (parameter) [1]
 60 -> i8042 (command) [1]
 56 -> i8042 (parameter) [1]
 60 -> i8042 (command) [1]
 47 -> i8042 (parameter) [1]
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
 f2 -> i8042 (kbd-data) [1]
 fa <- i8042 (interrupt, 0, 1, timeout) [1]
 ab <- i8042 (interrupt, 0, 1, timeout) [1]
 83 <- i8042 (interrupt, 0, 1, timeout) [1]
 ed -> i8042 (kbd-data) [1]
 fa <- i8042 (interrupt, 0, 1, timeout) [1]
 00 -> i8042 (kbd-data) [1]
 fa <- i8042 (interrupt, 0, 1, timeout) [1]
 f3 -> i8042 (kbd-data) [1]
 fa <- i8042 (interrupt, 0, 1, timeout) [1]
 00 -> i8042 (kbd-data) [1]
 fa <- i8042 (interrupt, 0, 1, timeout) [1]
 f4 -> i8042 (kbd-data) [1]
 fa <- i8042 (interrupt, 0, 1, timeout) [1]
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
 d4 -> i8042 (command) [2]
 f2 -> i8042 (parameter) [2]
 fa <- i8042 (interrupt, 1, 12, timeout) [2]
 00 <- i8042 (interrupt, 1, 12, timeout) [3]
 60 -> i8042 (command) [3]
 45 -> i8042 (parameter) [3]
 60 -> i8042 (command) [3]
 47 -> i8042 (parameter) [3]
 d4 -> i8042 (command) [3]
 f2 -> i8042 (parameter) [3]
 fa <- i8042 ...
[ message continues ]

Hmm, and what happens if you force dfl = 0 in i8042_interrupt()? It looks

KVM + serio_raw but someone needs to write the glue...

-- 
Dmitry
--

[ message continues ]

Yeah, that makes the thing work correctly (together with nomux). This all 
is really strange, isn't it? I doubt other OS discards I8042_STR_TIMEOUT 
completely :)

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--

[ message continues ]

Looking at the latest bugzilla comment for this laptop it appears
exactly what custome Dell drivers do ;)

Well, another blacklist in i8042 I guess...

-- 
Dmitry
--

[ message continues ]

Sigh, seems so.

I'll send you patch once I get positive testing feedback.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--

[ message continues ]

From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] Input: introduce 'notimeout' blacklist for Dell Vostro V13

i8042 controller present in Dell Vostro V13 errorneously signals spurious
timeouts.

Introduce i8042.notimeout parameter for ignoring i8042-signalled timeouts
and apply this quirk automatically for Dell Vostro V13, based on DMI match.

In addition to that, this machine also needs to be added to nomux blacklist.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
 drivers/input/serio/i8042-x86ia64io.h |   21 +++++++++++++++++++++
 drivers/input/serio/i8042.c           |    6 +++++-
 2 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
index a5475b5..b04dd27 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -424,6 +424,13 @@ static const struct dmi_system_id __initconst i8042_dmi_nomux_table[] = {
 			DMI_MATCH(DMI_PRODUCT_VERSION, "0100"),
 		},
 	},
+	{
+		/* Dell Vostro V13 */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Vostro V13"),
+		},
+	},
 	{ }
 };
 
@@ -545,6 +552,17 @@ static const struct dmi_system_id __initconst i8042_dmi_laptop_table[] = {
 };
 #endif
 
+static const struct dmi_system_id __initconst i8042_dmi_notimeout_table[] = {
+	{
+		/* Dell Vostro V13 */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Vostro V13"),
+		},
+	},
+	{ }
+};
+
 /*
  * Some Wistron based laptops need us to explicitly enable the 'Dritek
  * keyboard extension' to make their extra keys start generating scancodes.
@@ -897,6 +915,9 @@ static int __init i8042_platform_init(void)
 	if (dmi_check_system(i8042_dmi_nomux_table))
 		i8042_nomux = true;
 
+	if (dmi_check_system(i8042_dmi_notimeout_table))
+		i8042_notimeout = true;
+
 	if (dmi_check_system(i8042_dmi_dritek_table))
 		i8042_dritek = true;
 #endif /* ...
[ message continues ]

Just to be clear -- I have already received positive feedback from the 
bugreporter I had. I have attached the patch for testing to

	https://bugzilla.kernel.org/show_bug.cgi?id=15416

as well, but I already have confirmation from person owning the hardware, 
so I believe it could be applied.


-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--

[ message continues ]