Patchwork Input: ALPS - add interleaved protocol support (Dell E6x00 series)

login
register
mail settings
Submitter Andy Isaacson
Date Jan. 15, 2010, 6:11 p.m.
Message ID <20100115181122.GA11414@hexapodia.org>
Download mbox | patch
Permalink /patch/42985/
State Superseded
Delegated to: Stefan Bader
Headers show

Comments

Andy Isaacson - Jan. 15, 2010, 6:11 p.m.
From: Sebastian Kapfer <sebastian_kapfer@gmx.net>
Date: Tue, 15 Dec 2009 08:39:50 -0800
Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)

commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream

Properly handle version of the protocol where standard PS/2 packets
from trackpoint are stuffed into middle (byte 3-6) of the standard
ALPS packets when both the touchpad and trackpoint are used together.

The patch is based on work done by Matthew Chapman and additional
research done by David Kubicek and Erik Osterholm:

	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610

Many thanks to David Kubicek for his efforts in researching fine points
of this new version of the protocol, especially interaction between pad
and stick in these models.

Signed-off-by: Sebastian Kapfer <sebastian_kapfer@gmx.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

Cherrypick to 2.6.31 by Andy Isaacson <adi@hexapodia.org>.  Tested on
Dell E4300.

 drivers/input/mouse/alps.c |  252 +++++++++++++++++++++++++++++++++++++++-----
 drivers/input/mouse/alps.h |    1 +
 2 files changed, 228 insertions(+), 25 deletions(-)
Stefan Bader - Jan. 18, 2010, 2:23 p.m.
I am a bit uncertain about this patch in stable from the view of regression
avoidance. Looking over the patch its hard to tell for certain whether the path
of execution is the same as before for the non-interleaved protocol.
Dmitry, how do you feel about it? Or maybe there has even be positive testing
with non-interleaved hardware with that patch.

-Stefan

Andy Isaacson wrote:
> From: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> Date: Tue, 15 Dec 2009 08:39:50 -0800
> Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> 
> commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> 
> Properly handle version of the protocol where standard PS/2 packets
> from trackpoint are stuffed into middle (byte 3-6) of the standard
> ALPS packets when both the touchpad and trackpoint are used together.
> 
> The patch is based on work done by Matthew Chapman and additional
> research done by David Kubicek and Erik Osterholm:
> 
> 	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> 
> Many thanks to David Kubicek for his efforts in researching fine points
> of this new version of the protocol, especially interaction between pad
> and stick in these models.
> 
> Signed-off-by: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> ---
> 
> Cherrypick to 2.6.31 by Andy Isaacson <adi@hexapodia.org>.  Tested on
> Dell E4300.
> 
>  drivers/input/mouse/alps.c |  252 +++++++++++++++++++++++++++++++++++++++-----
>  drivers/input/mouse/alps.h |    1 +
>  2 files changed, 228 insertions(+), 25 deletions(-)
>
Dmitry Torokhov - Jan. 19, 2010, 8:36 a.m.
On Mon, Jan 18, 2010 at 03:23:12PM +0100, Stefan Bader wrote:
> I am a bit uncertain about this patch in stable from the view of regression
> avoidance. Looking over the patch its hard to tell for certain whether the path
> of execution is the same as before for the non-interleaved protocol.
> Dmitry, how do you feel about it? Or maybe there has even be positive testing
> with non-interleaved hardware with that patch.

Umm, it is a bit large for -stable to my taste. However without the
patch the affected laptops are pretty much unusable so I think we better
get it in. The non-interleaved devices should continue to work fine, at
least I don't see any adverse effects on my d630 (caveat - I am not
using _this_ version of the patch but rather what is currently in Linus's
tree).

Thanks.

> 
> -Stefan
> 
> Andy Isaacson wrote:
> > From: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> > Date: Tue, 15 Dec 2009 08:39:50 -0800
> > Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> > 
> > commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> > 
> > Properly handle version of the protocol where standard PS/2 packets
> > from trackpoint are stuffed into middle (byte 3-6) of the standard
> > ALPS packets when both the touchpad and trackpoint are used together.
> > 
> > The patch is based on work done by Matthew Chapman and additional
> > research done by David Kubicek and Erik Osterholm:
> > 
> > 	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> > 
> > Many thanks to David Kubicek for his efforts in researching fine points
> > of this new version of the protocol, especially interaction between pad
> > and stick in these models.
> > 
> > Signed-off-by: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> > Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> > ---
> > 
> > Cherrypick to 2.6.31 by Andy Isaacson <adi@hexapodia.org>.  Tested on
> > Dell E4300.
> > 
> >  drivers/input/mouse/alps.c |  252 +++++++++++++++++++++++++++++++++++++++-----
> >  drivers/input/mouse/alps.h |    1 +
> >  2 files changed, 228 insertions(+), 25 deletions(-)
> > 
>
Andy Isaacson - Jan. 19, 2010, 9:15 a.m.
On Tue, Jan 19, 2010 at 12:36:14AM -0800, Dmitry Torokhov wrote:
> On Mon, Jan 18, 2010 at 03:23:12PM +0100, Stefan Bader wrote:
> > I am a bit uncertain about this patch in stable from the view of
> > regression avoidance. Looking over the patch its hard to tell for
> > certain whether the path of execution is the same as before for the
> > non-interleaved protocol.  Dmitry, how do you feel about it? Or
> > maybe there has even be positive testing with non-interleaved
> > hardware with that patch.
> 
> Umm, it is a bit large for -stable to my taste. However without the
> patch the affected laptops are pretty much unusable so I think we better
> get it in. The non-interleaved devices should continue to work fine, at
> least I don't see any adverse effects on my d630 (caveat - I am not
> using _this_ version of the patch but rather what is currently in Linus's
> tree).

I agree, the interleaved protocol support is awfully high-impact for
-stable.  However as you've observed, the affected machines are really
unusable without some fix.

Personally I'm fine maintaining the backport locally, but it'd be nice
to fix this for Karmic as well.

I'll do some testing on non-Dell hardware tomorrow.

-andy
Ben Hutchings - Jan. 19, 2010, 2:44 p.m.
On Tue, 2010-01-19 at 00:36 -0800, Dmitry Torokhov wrote:
> On Mon, Jan 18, 2010 at 03:23:12PM +0100, Stefan Bader wrote:
> > I am a bit uncertain about this patch in stable from the view of regression
> > avoidance. Looking over the patch its hard to tell for certain whether the path
> > of execution is the same as before for the non-interleaved protocol.
> > Dmitry, how do you feel about it? Or maybe there has even be positive testing
> > with non-interleaved hardware with that patch.
> 
> Umm, it is a bit large for -stable to my taste. However without the
> patch the affected laptops are pretty much unusable so I think we better
> get it in. The non-interleaved devices should continue to work fine, at
> least I don't see any adverse effects on my d630 (caveat - I am not
> using _this_ version of the patch but rather what is currently in Linus's
> tree).
[...]

For what it's worth, we already added this to Debian kernel packages and
I don't believe we've seen any bug reports related to it.

Ben.
Stefan Bader - Jan. 20, 2010, 2:09 p.m.
Ben Hutchings wrote:
> On Tue, 2010-01-19 at 00:36 -0800, Dmitry Torokhov wrote:
>> On Mon, Jan 18, 2010 at 03:23:12PM +0100, Stefan Bader wrote:
>>> I am a bit uncertain about this patch in stable from the view of regression
>>> avoidance. Looking over the patch its hard to tell for certain whether the path
>>> of execution is the same as before for the non-interleaved protocol.
>>> Dmitry, how do you feel about it? Or maybe there has even be positive testing
>>> with non-interleaved hardware with that patch.
>> Umm, it is a bit large for -stable to my taste. However without the
>> patch the affected laptops are pretty much unusable so I think we better
>> get it in. The non-interleaved devices should continue to work fine, at
>> least I don't see any adverse effects on my d630 (caveat - I am not
>> using _this_ version of the patch but rather what is currently in Linus's
>> tree).
> [...]
> 
> For what it's worth, we already added this to Debian kernel packages and
> I don't believe we've seen any bug reports related to it.
> 
> Ben.
> 
That sounds good. Thanks for that feedback Ben. For the Ubuntu part, I dicussed
this with Andy and we agreed to take it into Lucid first and then roll it back
to Karmic after a little delay.

-Stefan
Greg KH - Jan. 21, 2010, 4:13 a.m.
On Fri, Jan 15, 2010 at 10:11:22AM -0800, Andy Isaacson wrote:
> From: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> Date: Tue, 15 Dec 2009 08:39:50 -0800
> Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> 
> commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> 
> Properly handle version of the protocol where standard PS/2 packets
> from trackpoint are stuffed into middle (byte 3-6) of the standard
> ALPS packets when both the touchpad and trackpoint are used together.
> 
> The patch is based on work done by Matthew Chapman and additional
> research done by David Kubicek and Erik Osterholm:
> 
> 	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> 
> Many thanks to David Kubicek for his efforts in researching fine points
> of this new version of the protocol, especially interaction between pad
> and stick in these models.
> 
> Signed-off-by: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> ---
> 
> Cherrypick to 2.6.31 by Andy Isaacson <adi@hexapodia.org>.  Tested on
> Dell E4300.

What -stable tree is this for?  .31 is no longer being maintained.  Is
this the proper patch for .32?  .27?

> 
>  drivers/input/mouse/alps.c |  252 +++++++++++++++++++++++++++++++++++++++-----
>  drivers/input/mouse/alps.h |    1 +
>  2 files changed, 228 insertions(+), 25 deletions(-)

Ick, that's a big patch, and kind of violates the -stable rules, right?
It's a "add new functionality" type thing that you are doing here from
what I can tell.  This doesn't fix a regression, does it?

confused,

greg k-h
Dmitry Torokhov - Jan. 21, 2010, 7:54 a.m.
On Wed, Jan 20, 2010 at 08:13:03PM -0800, Greg KH wrote:
> On Fri, Jan 15, 2010 at 10:11:22AM -0800, Andy Isaacson wrote:
> > From: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> > Date: Tue, 15 Dec 2009 08:39:50 -0800
> > Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> > 
> > commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> > 
> > Properly handle version of the protocol where standard PS/2 packets
> > from trackpoint are stuffed into middle (byte 3-6) of the standard
> > ALPS packets when both the touchpad and trackpoint are used together.
> > 
> > The patch is based on work done by Matthew Chapman and additional
> > research done by David Kubicek and Erik Osterholm:
> > 
> > 	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> > 
> > Many thanks to David Kubicek for his efforts in researching fine points
> > of this new version of the protocol, especially interaction between pad
> > and stick in these models.
> > 
> > Signed-off-by: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> > Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> > ---
> > 
> > Cherrypick to 2.6.31 by Andy Isaacson <adi@hexapodia.org>.  Tested on
> > Dell E4300.
> 
> What -stable tree is this for?  .31 is no longer being maintained.  Is
> this the proper patch for .32?  .27?
> 
> > 
> >  drivers/input/mouse/alps.c |  252 +++++++++++++++++++++++++++++++++++++++-----
> >  drivers/input/mouse/alps.h |    1 +
> >  2 files changed, 228 insertions(+), 25 deletions(-)
> 
> Ick, that's a big patch, and kind of violates the -stable rules, right?
> It's a "add new functionality" type thing that you are doing here from
> what I can tell.  This doesn't fix a regression, does it?
> 

Well, yes and no. As shipped .32 (and earlier) has the signature for
ALPS that is installed in those newer Latitudes so we try to activate
ALPS protocol for their touchpads. Unfortunately without the patch the
protocol desyncs all the time, making trackpoint/touchpad unuseable.

IOW if you are an owner of said Latitude you want this patch _very
much_. But yes, the patch is sizeable.
Greg KH - Jan. 21, 2010, 4:23 p.m.
On Wed, Jan 20, 2010 at 11:54:38PM -0800, Dmitry Torokhov wrote:
> On Wed, Jan 20, 2010 at 08:13:03PM -0800, Greg KH wrote:
> > On Fri, Jan 15, 2010 at 10:11:22AM -0800, Andy Isaacson wrote:
> > > From: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> > > Date: Tue, 15 Dec 2009 08:39:50 -0800
> > > Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> > > 
> > > commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> > > 
> > > Properly handle version of the protocol where standard PS/2 packets
> > > from trackpoint are stuffed into middle (byte 3-6) of the standard
> > > ALPS packets when both the touchpad and trackpoint are used together.
> > > 
> > > The patch is based on work done by Matthew Chapman and additional
> > > research done by David Kubicek and Erik Osterholm:
> > > 
> > > 	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> > > 
> > > Many thanks to David Kubicek for his efforts in researching fine points
> > > of this new version of the protocol, especially interaction between pad
> > > and stick in these models.
> > > 
> > > Signed-off-by: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> > > Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> > > ---
> > > 
> > > Cherrypick to 2.6.31 by Andy Isaacson <adi@hexapodia.org>.  Tested on
> > > Dell E4300.
> > 
> > What -stable tree is this for?  .31 is no longer being maintained.  Is
> > this the proper patch for .32?  .27?
> > 
> > > 
> > >  drivers/input/mouse/alps.c |  252 +++++++++++++++++++++++++++++++++++++++-----
> > >  drivers/input/mouse/alps.h |    1 +
> > >  2 files changed, 228 insertions(+), 25 deletions(-)
> > 
> > Ick, that's a big patch, and kind of violates the -stable rules, right?
> > It's a "add new functionality" type thing that you are doing here from
> > what I can tell.  This doesn't fix a regression, does it?
> > 
> 
> Well, yes and no. As shipped .32 (and earlier) has the signature for
> ALPS that is installed in those newer Latitudes so we try to activate
> ALPS protocol for their touchpads. Unfortunately without the patch the
> protocol desyncs all the time, making trackpoint/touchpad unuseable.
> 
> IOW if you are an owner of said Latitude you want this patch _very
> much_. But yes, the patch is sizeable.

So is this something that you, as the maintainer of the subsystem, would
recommend that I consider for the -stable tree because of this
situation?

thanks,

greg k-h
Dmitry Torokhov - Jan. 21, 2010, 5:30 p.m.
On Thu, Jan 21, 2010 at 08:23:28AM -0800, Greg KH wrote:
> On Wed, Jan 20, 2010 at 11:54:38PM -0800, Dmitry Torokhov wrote:
> > On Wed, Jan 20, 2010 at 08:13:03PM -0800, Greg KH wrote:
> > > On Fri, Jan 15, 2010 at 10:11:22AM -0800, Andy Isaacson wrote:
> > > > From: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> > > > Date: Tue, 15 Dec 2009 08:39:50 -0800
> > > > Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> > > > 
> > > > commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> > > > 
> > > > Properly handle version of the protocol where standard PS/2 packets
> > > > from trackpoint are stuffed into middle (byte 3-6) of the standard
> > > > ALPS packets when both the touchpad and trackpoint are used together.
> > > > 
> > > > The patch is based on work done by Matthew Chapman and additional
> > > > research done by David Kubicek and Erik Osterholm:
> > > > 
> > > > 	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> > > > 
> > > > Many thanks to David Kubicek for his efforts in researching fine points
> > > > of this new version of the protocol, especially interaction between pad
> > > > and stick in these models.
> > > > 
> > > > Signed-off-by: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> > > > Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> > > > ---
> > > > 
> > > > Cherrypick to 2.6.31 by Andy Isaacson <adi@hexapodia.org>.  Tested on
> > > > Dell E4300.
> > > 
> > > What -stable tree is this for?  .31 is no longer being maintained.  Is
> > > this the proper patch for .32?  .27?
> > > 
> > > > 
> > > >  drivers/input/mouse/alps.c |  252 +++++++++++++++++++++++++++++++++++++++-----
> > > >  drivers/input/mouse/alps.h |    1 +
> > > >  2 files changed, 228 insertions(+), 25 deletions(-)
> > > 
> > > Ick, that's a big patch, and kind of violates the -stable rules, right?
> > > It's a "add new functionality" type thing that you are doing here from
> > > what I can tell.  This doesn't fix a regression, does it?
> > > 
> > 
> > Well, yes and no. As shipped .32 (and earlier) has the signature for
> > ALPS that is installed in those newer Latitudes so we try to activate
> > ALPS protocol for their touchpads. Unfortunately without the patch the
> > protocol desyncs all the time, making trackpoint/touchpad unuseable.
> > 
> > IOW if you are an owner of said Latitude you want this patch _very
> > much_. But yes, the patch is sizeable.
> 
> So is this something that you, as the maintainer of the subsystem, would
> recommend that I consider for the -stable tree because of this
> situation?
> 

Yes, I am recommending it. The new behavior should be mostly contained
by ALPS_INTERLEAVED flag that is only set for one particular signature;
the rest of devices should not be affected.

The patch could be made smaller (there are some comments and a bit of
restructuring that could be cut out) but given that it is in Debian for
some time I question whether introducing 3rd, less tested variant to
reduce patch line count makes sense.

Thanks.
Greg KH - Jan. 25, 2010, 7:21 p.m.
On Thu, Jan 21, 2010 at 09:30:48AM -0800, Dmitry Torokhov wrote:
> On Thu, Jan 21, 2010 at 08:23:28AM -0800, Greg KH wrote:
> > On Wed, Jan 20, 2010 at 11:54:38PM -0800, Dmitry Torokhov wrote:
> > > On Wed, Jan 20, 2010 at 08:13:03PM -0800, Greg KH wrote:
> > > > On Fri, Jan 15, 2010 at 10:11:22AM -0800, Andy Isaacson wrote:
> > > > > From: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> > > > > Date: Tue, 15 Dec 2009 08:39:50 -0800
> > > > > Subject: [PATCH] Input: ALPS - add interleaved protocol support (Dell E6x00 series)
> > > > > 
> > > > > commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream
> > > > > 
> > > > > Properly handle version of the protocol where standard PS/2 packets
> > > > > from trackpoint are stuffed into middle (byte 3-6) of the standard
> > > > > ALPS packets when both the touchpad and trackpoint are used together.
> > > > > 
> > > > > The patch is based on work done by Matthew Chapman and additional
> > > > > research done by David Kubicek and Erik Osterholm:
> > > > > 
> > > > > 	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610
> > > > > 
> > > > > Many thanks to David Kubicek for his efforts in researching fine points
> > > > > of this new version of the protocol, especially interaction between pad
> > > > > and stick in these models.
> > > > > 
> > > > > Signed-off-by: Sebastian Kapfer <sebastian_kapfer@gmx.net>
> > > > > Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> > > > > ---
> > > > > 
> > > > > Cherrypick to 2.6.31 by Andy Isaacson <adi@hexapodia.org>.  Tested on
> > > > > Dell E4300.
> > > > 
> > > > What -stable tree is this for?  .31 is no longer being maintained.  Is
> > > > this the proper patch for .32?  .27?
> > > > 
> > > > > 
> > > > >  drivers/input/mouse/alps.c |  252 +++++++++++++++++++++++++++++++++++++++-----
> > > > >  drivers/input/mouse/alps.h |    1 +
> > > > >  2 files changed, 228 insertions(+), 25 deletions(-)
> > > > 
> > > > Ick, that's a big patch, and kind of violates the -stable rules, right?
> > > > It's a "add new functionality" type thing that you are doing here from
> > > > what I can tell.  This doesn't fix a regression, does it?
> > > > 
> > > 
> > > Well, yes and no. As shipped .32 (and earlier) has the signature for
> > > ALPS that is installed in those newer Latitudes so we try to activate
> > > ALPS protocol for their touchpads. Unfortunately without the patch the
> > > protocol desyncs all the time, making trackpoint/touchpad unuseable.
> > > 
> > > IOW if you are an owner of said Latitude you want this patch _very
> > > much_. But yes, the patch is sizeable.
> > 
> > So is this something that you, as the maintainer of the subsystem, would
> > recommend that I consider for the -stable tree because of this
> > situation?
> > 
> 
> Yes, I am recommending it. The new behavior should be mostly contained
> by ALPS_INTERLEAVED flag that is only set for one particular signature;
> the rest of devices should not be affected.
> 
> The patch could be made smaller (there are some comments and a bit of
> restructuring that could be cut out) but given that it is in Debian for
> some time I question whether introducing 3rd, less tested variant to
> reduce patch line count makes sense.

Ok, I've now queued this up for the next .32 release, thanks.

greg k-h
Stefan Bader - Feb. 10, 2010, 10:26 a.m.
Committed to repo.

Patch

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 5547e24..b172bef 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -5,6 +5,7 @@ 
  * Copyright (c) 2003-2005 Peter Osterlund <petero2@telia.com>
  * Copyright (c) 2004 Dmitry Torokhov <dtor@mail.ru>
  * Copyright (c) 2005 Vojtech Pavlik <vojtech@suse.cz>
+ * Copyright (c) 2009 Sebastian Kapfer <sebastian_kapfer@gmx.net>
  *
  * ALPS detection, tap switching and status querying info is taken from
  * tpconfig utility (by C. Scott Ananian and Bruce Kall).
@@ -35,6 +36,8 @@ 
 #define ALPS_OLDPROTO	0x10
 #define ALPS_PASS	0x20
 #define ALPS_FW_BK_2	0x40
+#define ALPS_PS2_INTERLEAVED	0x80	/* 3-byte PS/2 packet interleaved with
+					   6-byte ALPS packet */
 
 static const struct alps_model_info alps_model_data[] = {
 	{ { 0x32, 0x02, 0x14 },	0xf8, 0xf8, ALPS_PASS | ALPS_DUALPOINT }, /* Toshiba Salellite Pro M10 */
@@ -55,7 +58,9 @@  static const struct alps_model_info alps_model_data[] = {
 	{ { 0x20, 0x02, 0x0e },	0xf8, 0xf8, ALPS_PASS | ALPS_DUALPOINT }, /* XXX */
 	{ { 0x22, 0x02, 0x0a },	0xf8, 0xf8, ALPS_PASS | ALPS_DUALPOINT },
 	{ { 0x22, 0x02, 0x14 }, 0xff, 0xff, ALPS_PASS | ALPS_DUALPOINT }, /* Dell Latitude D600 */
-	{ { 0x62, 0x02, 0x14 }, 0xcf, 0xcf, ALPS_PASS | ALPS_DUALPOINT }, /* Dell Latitude E6500 */
+	/* Dell Latitude E5500, E6400, E6500, Precision M4400 */
+	{ { 0x62, 0x02, 0x14 }, 0xcf, 0xcf,
+		ALPS_PASS | ALPS_DUALPOINT | ALPS_PS2_INTERLEAVED },
 	{ { 0x73, 0x02, 0x50 }, 0xcf, 0xcf, ALPS_FW_BK_1 },		  /* Dell Vostro 1400 */
 };
 
@@ -66,20 +71,88 @@  static const struct alps_model_info alps_model_data[] = {
  */
 
 /*
- * ALPS abolute Mode - new format
+ * PS/2 packet format
+ *
+ * byte 0:  0    0 YSGN XSGN    1    M    R    L
+ * byte 1: X7   X6   X5   X4   X3   X2   X1   X0
+ * byte 2: Y7   Y6   Y5   Y4   Y3   Y2   Y1   Y0
+ *
+ * Note that the device never signals overflow condition.
+ *
+ * ALPS absolute Mode - new format
  *
  * byte 0:  1    ?    ?    ?    1    ?    ?    ?
  * byte 1:  0   x6   x5   x4   x3   x2   x1   x0
- * byte 2:  0   x10  x9   x8   x7    ?  fin  ges
+ * byte 2:  0  x10   x9   x8   x7    ?  fin  ges
  * byte 3:  0   y9   y8   y7    1    M    R    L
  * byte 4:  0   y6   y5   y4   y3   y2   y1   y0
  * byte 5:  0   z6   z5   z4   z3   z2   z1   z0
  *
+ * Dualpoint device -- interleaved packet format
+ *
+ * byte 0:    1    1    0    0    1    1    1    1
+ * byte 1:    0   x6   x5   x4   x3   x2   x1   x0
+ * byte 2:    0  x10   x9   x8   x7    0  fin  ges
+ * byte 3:    0    0 YSGN XSGN    1    1    1    1
+ * byte 4:   X7   X6   X5   X4   X3   X2   X1   X0
+ * byte 5:   Y7   Y6   Y5   Y4   Y3   Y2   Y1   Y0
+ * byte 6:    0   y9   y8   y7    1    m    r    l
+ * byte 7:    0   y6   y5   y4   y3   y2   y1   y0
+ * byte 8:    0   z6   z5   z4   z3   z2   z1   z0
+ *
+ * CAPITALS = stick, miniscules = touchpad
+ *
  * ?'s can have different meanings on different models,
  * such as wheel rotation, extra buttons, stick buttons
  * on a dualpoint, etc.
  */
 
+static bool alps_is_valid_first_byte(const struct alps_model_info *model,
+				     unsigned char data)
+{
+	return (data & model->mask0) == model->byte0;
+}
+
+static void alps_report_buttons(struct psmouse *psmouse,
+				struct input_dev *dev1, struct input_dev *dev2,
+				int left, int right, int middle)
+{
+	struct alps_data *priv = psmouse->private;
+	const struct alps_model_info *model = priv->i;
+
+	if (model->flags & ALPS_PS2_INTERLEAVED) {
+		struct input_dev *dev;
+
+		/*
+		 * If shared button has already been reported on the
+		 * other device (dev2) then this event should be also
+		 * sent through that device.
+		 */
+		dev = test_bit(BTN_LEFT, dev2->key) ? dev2 : dev1;
+		input_report_key(dev, BTN_LEFT, left);
+
+		dev = test_bit(BTN_RIGHT, dev2->key) ? dev2 : dev1;
+		input_report_key(dev, BTN_RIGHT, right);
+
+		dev = test_bit(BTN_MIDDLE, dev2->key) ? dev2 : dev1;
+		input_report_key(dev, BTN_MIDDLE, middle);
+
+		/*
+		 * Sync the _other_ device now, we'll do the first
+		 * device later once we report the rest of the events.
+		 */
+		input_sync(dev2);
+	} else {
+		/*
+		 * For devices with non-interleaved packets we know what
+		 * device buttons belong to so we can simply report them.
+		 */
+		input_report_key(dev1, BTN_LEFT, left);
+		input_report_key(dev1, BTN_RIGHT, right);
+		input_report_key(dev1, BTN_MIDDLE, middle);
+	}
+}
+
 static void alps_process_packet(struct psmouse *psmouse)
 {
 	struct alps_data *priv = psmouse->private;
@@ -89,18 +162,6 @@  static void alps_process_packet(struct psmouse *psmouse)
 	int x, y, z, ges, fin, left, right, middle;
 	int back = 0, forward = 0;
 
-	if ((packet[0] & 0xc8) == 0x08) {   /* 3-byte PS/2 packet */
-		input_report_key(dev2, BTN_LEFT,   packet[0] & 1);
-		input_report_key(dev2, BTN_RIGHT,  packet[0] & 2);
-		input_report_key(dev2, BTN_MIDDLE, packet[0] & 4);
-		input_report_rel(dev2, REL_X,
-			packet[1] ? packet[1] - ((packet[0] << 4) & 0x100) : 0);
-		input_report_rel(dev2, REL_Y,
-			packet[2] ? ((packet[0] << 3) & 0x100) - packet[2] : 0);
-		input_sync(dev2);
-		return;
-	}
-
 	if (priv->i->flags & ALPS_OLDPROTO) {
 		left = packet[2] & 0x10;
 		right = packet[2] & 0x08;
@@ -136,18 +197,13 @@  static void alps_process_packet(struct psmouse *psmouse)
 		input_report_rel(dev2, REL_X,  (x > 383 ? (x - 768) : x));
 		input_report_rel(dev2, REL_Y, -(y > 255 ? (y - 512) : y));
 
-		input_report_key(dev2, BTN_LEFT, left);
-		input_report_key(dev2, BTN_RIGHT, right);
-		input_report_key(dev2, BTN_MIDDLE, middle);
+		alps_report_buttons(psmouse, dev2, dev, left, right, middle);
 
-		input_sync(dev);
 		input_sync(dev2);
 		return;
 	}
 
-	input_report_key(dev, BTN_LEFT, left);
-	input_report_key(dev, BTN_RIGHT, right);
-	input_report_key(dev, BTN_MIDDLE, middle);
+	alps_report_buttons(psmouse, dev, dev2, left, right, middle);
 
 	/* Convert hardware tap to a reasonable Z value */
 	if (ges && !fin) z = 40;
@@ -188,25 +244,168 @@  static void alps_process_packet(struct psmouse *psmouse)
 	input_sync(dev);
 }
 
+static void alps_report_bare_ps2_packet(struct psmouse *psmouse,
+					unsigned char packet[],
+					bool report_buttons)
+{
+	struct alps_data *priv = psmouse->private;
+	struct input_dev *dev2 = priv->dev2;
+
+	if (report_buttons)
+		alps_report_buttons(psmouse, dev2, psmouse->dev,
+				packet[0] & 1, packet[0] & 2, packet[0] & 4);
+
+	input_report_rel(dev2, REL_X,
+		packet[1] ? packet[1] - ((packet[0] << 4) & 0x100) : 0);
+	input_report_rel(dev2, REL_Y,
+		packet[2] ? ((packet[0] << 3) & 0x100) - packet[2] : 0);
+
+	input_sync(dev2);
+}
+
+static psmouse_ret_t alps_handle_interleaved_ps2(struct psmouse *psmouse)
+{
+	struct alps_data *priv = psmouse->private;
+
+	if (psmouse->pktcnt < 6)
+		return PSMOUSE_GOOD_DATA;
+
+	if (psmouse->pktcnt == 6) {
+		/*
+		 * Start a timer to flush the packet if it ends up last
+		 * 6-byte packet in the stream. Timer needs to fire
+		 * psmouse core times out itself. 20 ms should be enough
+		 * to decide if we are getting more data or not.
+		 */
+		mod_timer(&priv->timer, jiffies + msecs_to_jiffies(20));
+		return PSMOUSE_GOOD_DATA;
+	}
+
+	del_timer(&priv->timer);
+
+	if (psmouse->packet[6] & 0x80) {
+
+		/*
+		 * Highest bit is set - that means we either had
+		 * complete ALPS packet and this is start of the
+		 * next packet or we got garbage.
+		 */
+
+		if (((psmouse->packet[3] |
+		      psmouse->packet[4] |
+		      psmouse->packet[5]) & 0x80) ||
+		    (!alps_is_valid_first_byte(priv->i, psmouse->packet[6]))) {
+			dbg("refusing packet %x %x %x %x "
+			    "(suspected interleaved ps/2)\n",
+			    psmouse->packet[3], psmouse->packet[4],
+			    psmouse->packet[5], psmouse->packet[6]);
+			return PSMOUSE_BAD_DATA;
+		}
+
+		alps_process_packet(psmouse);
+
+		/* Continue with the next packet */
+		psmouse->packet[0] = psmouse->packet[6];
+		psmouse->pktcnt = 1;
+
+	} else {
+
+		/*
+		 * High bit is 0 - that means that we indeed got a PS/2
+		 * packet in the middle of ALPS packet.
+		 *
+		 * There is also possibility that we got 6-byte ALPS
+		 * packet followed  by 3-byte packet from trackpoint. We
+		 * can not distinguish between these 2 scenarios but
+		 * becase the latter is unlikely to happen in course of
+		 * normal operation (user would need to press all
+		 * buttons on the pad and start moving trackpoint
+		 * without touching the pad surface) we assume former.
+		 * Even if we are wrong the wost thing that would happen
+		 * the cursor would jump but we should not get protocol
+		 * desynchronization.
+		 */
+
+		alps_report_bare_ps2_packet(psmouse, &psmouse->packet[3],
+					    false);
+
+		/*
+		 * Continue with the standard ALPS protocol handling,
+		 * but make sure we won't process it as an interleaved
+		 * packet again, which may happen if all buttons are
+		 * pressed. To avoid this let's reset the 4th bit which
+		 * is normally 1.
+		 */
+		psmouse->packet[3] = psmouse->packet[6] & 0xf7;
+		psmouse->pktcnt = 4;
+	}
+
+	return PSMOUSE_GOOD_DATA;
+}
+
+static void alps_flush_packet(unsigned long data)
+{
+	struct psmouse *psmouse = (struct psmouse *)data;
+
+	serio_pause_rx(psmouse->ps2dev.serio);
+
+	if (psmouse->pktcnt == 6) {
+
+		/*
+		 * We did not any more data in reasonable amount of time.
+		 * Validate the last 3 bytes and process as a standard
+		 * ALPS packet.
+		 */
+		if ((psmouse->packet[3] |
+		     psmouse->packet[4] |
+		     psmouse->packet[5]) & 0x80) {
+			dbg("refusing packet %x %x %x "
+			    "(suspected interleaved ps/2)\n",
+			    psmouse->packet[3], psmouse->packet[4],
+			    psmouse->packet[5]);
+		} else {
+			alps_process_packet(psmouse);
+		}
+		psmouse->pktcnt = 0;
+	}
+
+	serio_continue_rx(psmouse->ps2dev.serio);
+}
+
 static psmouse_ret_t alps_process_byte(struct psmouse *psmouse)
 {
 	struct alps_data *priv = psmouse->private;
+	const struct alps_model_info *model = priv->i;
 
 	if ((psmouse->packet[0] & 0xc8) == 0x08) { /* PS/2 packet */
 		if (psmouse->pktcnt == 3) {
-			alps_process_packet(psmouse);
+			alps_report_bare_ps2_packet(psmouse, psmouse->packet,
+						    true);
 			return PSMOUSE_FULL_PACKET;
 		}
 		return PSMOUSE_GOOD_DATA;
 	}
 
-	if ((psmouse->packet[0] & priv->i->mask0) != priv->i->byte0)
+	/* Check for PS/2 packet stuffed in the middle of ALPS packet. */
+
+	if ((model->flags & ALPS_PS2_INTERLEAVED) &&
+	    psmouse->pktcnt >= 4 && (psmouse->packet[3] & 0x0f) == 0x0f) {
+		return alps_handle_interleaved_ps2(psmouse);
+	}
+
+	if (!alps_is_valid_first_byte(model, psmouse->packet[0])) {
+		dbg("refusing packet[0] = %x (mask0 = %x, byte0 = %x)\n",
+		    psmouse->packet[0], model->mask0, model->byte0);
 		return PSMOUSE_BAD_DATA;
+	}
 
 	/* Bytes 2 - 6 should have 0 in the highest bit */
 	if (psmouse->pktcnt >= 2 && psmouse->pktcnt <= 6 &&
-	    (psmouse->packet[psmouse->pktcnt - 1] & 0x80))
+	    (psmouse->packet[psmouse->pktcnt - 1] & 0x80)) {
+		dbg("refusing packet[%i] = %x\n",
+		    psmouse->pktcnt - 1, psmouse->packet[psmouse->pktcnt - 1]);
 		return PSMOUSE_BAD_DATA;
+	}
 
 	if (psmouse->pktcnt == 6) {
 		alps_process_packet(psmouse);
@@ -441,6 +640,7 @@  static void alps_disconnect(struct psmouse *psmouse)
 	struct alps_data *priv = psmouse->private;
 
 	psmouse_reset(psmouse);
+	del_timer_sync(&priv->timer);
 	input_unregister_device(priv->dev2);
 	kfree(priv);
 }
@@ -457,6 +657,8 @@  int alps_init(struct psmouse *psmouse)
 		goto init_fail;
 
 	priv->dev2 = dev2;
+	setup_timer(&priv->timer, alps_flush_packet, (unsigned long)psmouse);
+
 	psmouse->private = priv;
 
 	if (alps_hw_init(psmouse, &version))
diff --git a/drivers/input/mouse/alps.h b/drivers/input/mouse/alps.h
index 4bbddc9..4b60241 100644
--- a/drivers/input/mouse/alps.h
+++ b/drivers/input/mouse/alps.h
@@ -23,6 +23,7 @@  struct alps_data {
 	char phys[32];			/* Phys */
 	const struct alps_model_info *i;/* Info */
 	int prev_fin;			/* Finger bit from previous packet */
+	struct timer_list timer;
 };
 
 #ifdef CONFIG_MOUSE_PS2_ALPS