Date:	Fri, 20 Feb 2015 20:24:20 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Mario Limonciello <mario_limonciello@...l.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>
Subject: Re: [PATCH] Add a quirk for the Dell XPS 13 (2015) when in PS/2 mode.

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:
> > Hi Dmitry,
> > 
> > On 02/19/2015 11:16 AM, Dmitry Torokhov wrote:
> > >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.

> > 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@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists