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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Feb 2015 10:47:17 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Mario Limonciello <mario_limonciello@...l.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	Pali Rohár <pali.rohar@...il.com>
Subject: Re: [PATCH] Add a quirk for the Dell XPS 13 (2015) when in PS/2 mode.

Hi Mario,

On Thu, Feb 19, 2015 at 12:16:51PM -0600, Mario Limonciello wrote:
> 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)?

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

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.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/