On Friday 20 February 2015 19:47:17 Dmitry Torokhov wrote: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.
On Thu, Feb 19, 2015 at 12:16:51PM -0600, Mario Limonciello
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 similarA 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?
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)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.
or share some BIOS parts, then problem can be really there.
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.Yes, the logs do fill up with error messages about the badI am not saying we do not need the solution, I am wondering if
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.
we can suppress errors altogether. I am also curious why
reset does not work as it should reinitialize the driver
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.
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/2Yes, 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.
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