On Friday 20 February 2015 20:56:23 Mario Limonciello wrote:

Hi Pali & Dmitry,

On 02/20/2015 01:24 PM, Pali Rohár wrote:

quoted

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

quoted

Hi Mario,

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

wrote:

quoted

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)?

We use the same embedded controller design and codebase on
many of our laptops.  Depending on the root cause, it's
possible to be the same problem that's happening on Latitude
6x40.  I'm leaning on it's likely not the same problem though
because on Latitude 6x40 II understand the issue does not
show up on the other side of the EC when the waveform was
analyzed in Windows.

quoted

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).

A colleague has shared to me some information about the issue
on 6x40 laptops as well.  There was a recent EC change
(released within last 2 weeks or so) that helps to fix
problems with i8042 traffic. It was intended to fix keyboard
repeating, but it may also fix the touchpad data.  Can you
please confirm if the new BIOS/EC update fixes the problem?

I have BIOS version A05 on my E6440 machine. That version does 
not have problems with "repeating keys" and my workaround for 
ALPS touchpad (which is in mainline tree and -stable trees now) 
works fine. If I do not see other problems, I will not update 
BIOS (just because current version working -- with workarounds).

But CCing Rob. He told me as first about existence of new BIOS 
version for E6440 and he is already testing new version of BIOS, 
so can share details.

Mario, can you share some details about that new BIOS update? If 
it is not secret, how was problem with "repeating keys" fixed? 
Why linux had more problems as Windows? Cannot we implement some 
"workaround" in linux kernel to prevent that (or similar) 
problems in future?

quoted

If Dell share EC firmware code in more models (Latitude and
XPS) or share some BIOS parts, then problem can be really
there.

Yes, specifically with XPS 13 (2015) the code base for the EC
has common components with Latitude and Precision.  For the
XPS problem, the EC code has been reviewed but not found any
issues with it pointing to an EC problem.  There are other
aspects that are being explored such as the input to the EC
being overamplified by a mis configured buffer in the
touchpad.  This would cause the data to saturate outside of
spec in the EC.

quoted

quoted

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.

Thanks.  I think it's fair to hide them when resetafter=0 is
configured (such as the quirk turns on).  If you agree, i'll
adjust the patch to do this. To clarify the problem, the
errors will show up and after 5 the touchpad is reset.  The
reset is what causes the freeze because the touchpad driver
takes 1-3 seconds to reinitialize.  The problem will happen
continue to happen though as it's believed to be higher up
the chain. If resetafter=0 is set, the errors will show up in
the logs, but the touchpad recovers on it's own.

resetafter=0 means to never reset (even if driver receive e.g 
thousand invalid packets). I think this is very dangerous if 
there will be other bugs either in linux driver or some other HW 
problems.

For ALPS issue I added resetafter = pktsize * 2 (Allow 2 invalid 
packets without resetting device). Cannot you find something 
similar for synaptics touchpads on XPS? (pktsize for ALPS is 6, 
no idea how big are synaptics packets).

quoted

quoted

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.

Yes, thanks I agree on this.  We are working on making
firmware flash on Latitude/Precision/XPS easier for Linux
users, but we're not there yet on everything.  If you look on
XPS 13 (2015) it's one of the first to support firmware flash
from F12 boot menu.  It will search any USB disks and
partitions that firmware can mount such as EFI system
partition.

Older Dell HW (laptops, desktops, servers) supported BIOS update 
directly from Linux (ubuntu has needed tools in standard 
repositories). It is not supported/provided anymore? I see that 
dell_rbu driver is still in linux kernel.

dell_rbu.ko:
description:    Driver for updating BIOS image on DELL systems

quoted

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.

Yes, if we can fix this in firmware, that's our goal too. 
If/when we get a firmware fix, the quirk can be configured to
only activate on earlier versions of the firmware that are
affected.

I'm not aware of the on-the-fly firmware load for Synaptics. 
Do you know more about this?  In dual mode touchpads is this
only present on the I2C mode?

There is problem with some synaptics touchpad on some laptops 
(probably not dell). Windows driver loads own firmware into 
synaptics touchpad which use different protocol (as original 
firmware in touchpad). And that loaded firmware is active until 
laptop is not shut down. When you reboot from Windows to Linux 
then linux kernel driver refuse to identify & use touchpad 
because it does not support that new firmware loaded by 
Windows... I do not know lot of about this problem, I just heard 
about it from other people. I did not see any laptop "in action".

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