Re: [PATCH v3 1/4] input: alps: Do not try to parse data as 3 bytes packet when driver is out of sync

[Dmitry Torokhov]

On Sun, Nov 02, 2014 at 12:25:07AM +0100, Pali Rohár wrote:
> 5th and 6th byte of ALPS trackstick V3 protocol match condition for first byte
> of PS/2 3 bytes packet. When driver enters out of sync state and ALPS trackstick
> is sending data then driver match 5th, 6th and next 1st bytes as PS/2.
> 
> It basically means if user is using trackstick when driver is in out of sync
> state driver will never resync. Processing these bytes as 3 bytes PS/2 data
> cause total mess (random cursor movements, random clicks) and make trackstick
> unusable until psmouse driver decide to do full device reset.
> 
> Lot of users reported problems with ALPS devices on Dell Latitude E6440, E6540
> and E7440 laptops. ALPS device or Dell EC for unknown reason send some invalid
> ALPS PS/2 bytes which cause driver out of sync. It looks like that i8042 and
> psmouse/alps driver always receive group of 6 bytes packets so there are no
> missing bytes and no bytes were inserted between valid once.
> 
> This patch does not fix root of problem with ALPS devices found in Dell Latitude
> laptops but it does not allow to process some (invalid) subsequence of 6 bytes
> ALPS packets as 3 bytes PS/2 when driver is out of sync.
> 
> So with this patch trackstick input device does not report bogus data when
> also driver is out of sync, so trackstick should be usable on those machines.
> 
> Unknown is also information which ALPS devices send 3 bytes packets and why
> ALPS driver needs to handle also bare PS/2 packets. According to git (and plus
> historic tree from bitkeeper) code for processing 3 bytes bare PS/2 packets
> is there since first version of alps.c existence (since 2.6.9-rc2).

I believe it was to handle external devices plugged into PS/2 ports on
Dell laptops (maybe?). Dell laptops do not use active multiplexing
controller so everything comes mixed into single data stream.

> 
> We do not want to break some older ALPS devices. And disabling processing bare
> PS/2 packets when driver is out of sync should not break it.
> 
> Signed-off-by: Pali Rohár <pali.rohar@xxxxxxxxx>
> Tested-by: Pali Rohár <pali.rohar@xxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx

Applied, thank you.

> ---
>  drivers/input/mouse/alps.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index 2b0ae8c..a772745 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -1156,7 +1156,9 @@ static psmouse_ret_t alps_process_byte(struct psmouse *psmouse)
>  {
>  	struct alps_data *priv = psmouse->private;
>  
> -	if ((psmouse->packet[0] & 0xc8) == 0x08) { /* PS/2 packet */
> +	/* FIXME: Could we receive bare PS/2 packets from DualPoint devices?? */
> +	if (!psmouse->out_of_sync_cnt &&
> +	    (psmouse->packet[0] & 0xc8) == 0x08) { /* PS/2 packet */
>  		if (psmouse->pktcnt == 3) {
>  			alps_report_bare_ps2_packet(psmouse, psmouse->packet,
>  						    true);
> -- 
> 1.7.9.5
> 

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