Thread (37 messages) flat view 37 messages, 6 authors, 2015-04-13

Re: [PATCH] Add a quirk for the Dell XPS 13 (2015) when in PS/2 mode.

From: Pali Rohár <hidden>
Date: 2015-02-20 19:24:26
Also in: lkml

On Friday 20 February 2015 19:47:17 Dmitry Torokhov wrote:
Hi Mario,

On Thu, Feb 19, 2015 at 12:16:51PM -0600, Mario Limonciello 
wrote:
quoted
Hi Dmitry,

On 02/19/2015 11:16 AM, Dmitry Torokhov wrote:
quoted
What kind of glitch is this? Is there a certain pattern to
it? Even if we do not reset the mouse the logs will be
full of error messages.

Thanks.
From waveform capture data leaving the touchpad is valid,
but when it is resent through the EC it's getting
corrupted.  This isn't exclusive to Linux setting it up
wrong or anything, it also happens on Windows.  On Windows
7 the touchpad driver does not issue a reset from the bad
data however.

The glitch is more prevalent as the machine is turned on but
seems to go away after it's been running a while.  We
currently don't believe it to be a problem with the EC
firmware, but we are still exploring other firmware based
solutions.
Can it be related to ther Dell models (Latitudes with ALPS
touchpad) also sending junk data under certain conditions
(adding Pali to teh CC as he was looking at this issue)?
Dell Latitude Exx40 models (with ALPS touchpads) have similar 
problems. Linux psmouse.ko/alps.c driver receive invalid packets 
which cause lot of problems... ALPS people told me those packets 
which was found on i8042 bus are really invalid ALPS packets and 
do not come from ALPS touchpad. Unless there is invisible bug in 
ALPS touchpad firmware (which was not discovered yet), problem is 
either in Dell EmeddedController where is connected ALPS touchpad 
or in Dell BIOS/UEFI (which I believe can modify any such data).

If Dell share EC firmware code in more models (Latitude and XPS) 
or share some BIOS parts, then problem can be really there.
quoted
Yes, the logs do fill up with error messages about the bad
data within the first few minutes of usage.  In my opinion
not freezing but getting errors in the log is better than
freezing and getting errors in the log, so we're at least
trying to provide a workaround for the problem.  If we come
up with a firmware based solution I'd be happy to adjust or
remove this later.
I am not saying we do not need the solution, I am wondering if
we can suppress errors altogether. I am also curious why
reset does not work as it should reinitialize the driver
completely.

And even if you do fix the firmware majority of users will
still need the software solution as updating BIOS is not
something that happens often.

Thanks.
I do not know what can kernel do when it receive invalid PS/2 
data from i8042 bus. If bogus packets are total random we can 
just try to ignore them and try be not out-of-sync. No idea how 
working solution it would be for new XPS model. Looks like for 
Latitude Exx40 models with their problems it is working...

Of course correct way is to fix firmware or BIOS or which part of 
HW is buggy. Ideally distribute that firmware fix to users. I 
heard that synaptics touchpad supports something like on-the-fly 
firmware load (without flashing it) which will be active until 
notebook shutdown.

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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help