Re: [PATCH] Add a quirk for the Dell XPS 13 (2015) when in PS/2 mode.

[Pali RohÃr]

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

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?

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

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

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

> > 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@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.