Hi Pali & Dmitry,
On 02/20/2015 01:24 PM, Pali Rohár wrote:
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:
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.
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?
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.
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.
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.
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
