Re: [PATCH] Add a quirk for the Dell XPS 13 (2015) when in PS/2 mode.
From: Pali RohÃr
Date: Fri Feb 20 2015 - 14:24:30 EST
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
> > 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
> 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.
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
Description: This is a digitally signed message part.