All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
	Hans de Goede <hdegoede@redhat.com>,
	Masaki Ota <masaki.ota@jp.alps.com>,
	linux-input@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Regression since commit 92bac83
Date: Tue, 20 Oct 2015 09:22:23 +0200	[thread overview]
Message-ID: <20151020072223.GC22600@pali> (raw)
In-Reply-To: <20151019165128.GB7006@dtor-ws>

On Monday 19 October 2015 09:51:28 Dmitry Torokhov wrote:
> On Mon, Oct 19, 2015 at 10:55:20AM -0500, Larry Finger wrote:
> > On 10/19/2015 03:08 AM, Hans de Goede wrote:
> > >Hi,
> > >
> > >On 19-10-15 01:59, Larry Finger wrote:
> > >>Hi,
> > >>
> > >>I recently upgraded the kernel in a Dell Latitude D600 and found that the
> > >>touchpad clicks failed. The problem was bisected to commit
> > >>92bac83dd79e60e65c475222e41a992a70434beb ("Input: alps - non interleaved V2
> > >>dualpoint has separate stick button bits"). The laptop has a combination
> > >>touchpad and control stick. For this device, the following values are found:
> > >>
> > >>priv->protoversion is 0x200 (ALPS_PROTO_V2)
> > >>priv->flags is 0x6 (ALPS_DUALPOINT | ALPS_PASS)
> > >>
> > >>As a result, the new code added in this patch is executed, and left, right,
> > >>and middle are updated. Once this code is introduced, a left click causes some
> > >>event as it will wake a sleeping screen, but not select any windows or do
> > >>anything useful.
> > >>
> > >>Please advise on what information would be needed to help debug this problem.
> > >
> > >Can you build a recent upstream kernel from source, and when building it
> > >comment out these lines in drivers/input/mouse/alps.c, around lines 2555 - 2556
> > >
> > >         if (dmi_name_in_vendors("Dell"))
> > >                 priv->flags |= ALPS_DELL;
> > >
> > >That should fix things, if that fixes things we need to rename the flag
> > >and move to a list of dmi-matched models (rather then vendor) where the new
> > >behavior
> > >introduced by the patch causing you problems is actually necessary.
> > >
> > >Step 1 is confirming that not setting the flag fixes things for you,
> > >if you can get back to us confirming that, then I'll whip up a patch
> > >to switch to model matching (which is not ideal, but seems to be
> > >necessary).
> > 
> > Thanks for the quick response. Removing the two lines mentioned
> > above restored correct touchpad operation with kernel 4.2.0. It
> > seems that the Latitude D600 is different than other Dell models.
> 
> I wonder if we should not revert all these patches splitting what once
> was one relative input device into separate trackstick/external mouse.
> They seem to cause a lot of troubles for little benefit. Pali?
> 
> Thanks.
> 

Hi Dmitry! I think that this bug is not related to my separation
patches, but rather to approach which is trying to fix some obscure bug
on some Dell machines...

-- 
Pali Rohár
pali.rohar@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
	Hans de Goede <hdegoede@redhat.com>,
	Masaki Ota <masaki.ota@jp.alps.com>,
	linux-input@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Regression since commit 92bac83
Date: Tue, 20 Oct 2015 09:22:23 +0200	[thread overview]
Message-ID: <20151020072223.GC22600@pali> (raw)
In-Reply-To: <20151019165128.GB7006@dtor-ws>

On Monday 19 October 2015 09:51:28 Dmitry Torokhov wrote:
> On Mon, Oct 19, 2015 at 10:55:20AM -0500, Larry Finger wrote:
> > On 10/19/2015 03:08 AM, Hans de Goede wrote:
> > >Hi,
> > >
> > >On 19-10-15 01:59, Larry Finger wrote:
> > >>Hi,
> > >>
> > >>I recently upgraded the kernel in a Dell Latitude D600 and found that the
> > >>touchpad clicks failed. The problem was bisected to commit
> > >>92bac83dd79e60e65c475222e41a992a70434beb ("Input: alps - non interleaved V2
> > >>dualpoint has separate stick button bits"). The laptop has a combination
> > >>touchpad and control stick. For this device, the following values are found:
> > >>
> > >>priv->protoversion is 0x200 (ALPS_PROTO_V2)
> > >>priv->flags is 0x6 (ALPS_DUALPOINT | ALPS_PASS)
> > >>
> > >>As a result, the new code added in this patch is executed, and left, right,
> > >>and middle are updated. Once this code is introduced, a left click causes some
> > >>event as it will wake a sleeping screen, but not select any windows or do
> > >>anything useful.
> > >>
> > >>Please advise on what information would be needed to help debug this problem.
> > >
> > >Can you build a recent upstream kernel from source, and when building it
> > >comment out these lines in drivers/input/mouse/alps.c, around lines 2555 - 2556
> > >
> > >         if (dmi_name_in_vendors("Dell"))
> > >                 priv->flags |= ALPS_DELL;
> > >
> > >That should fix things, if that fixes things we need to rename the flag
> > >and move to a list of dmi-matched models (rather then vendor) where the new
> > >behavior
> > >introduced by the patch causing you problems is actually necessary.
> > >
> > >Step 1 is confirming that not setting the flag fixes things for you,
> > >if you can get back to us confirming that, then I'll whip up a patch
> > >to switch to model matching (which is not ideal, but seems to be
> > >necessary).
> > 
> > Thanks for the quick response. Removing the two lines mentioned
> > above restored correct touchpad operation with kernel 4.2.0. It
> > seems that the Latitude D600 is different than other Dell models.
> 
> I wonder if we should not revert all these patches splitting what once
> was one relative input device into separate trackstick/external mouse.
> They seem to cause a lot of troubles for little benefit. Pali?
> 
> Thanks.
> 

Hi Dmitry! I think that this bug is not related to my separation
patches, but rather to approach which is trying to fix some obscure bug
on some Dell machines...

-- 
Pali Rohár
pali.rohar@gmail.com

  parent reply	other threads:[~2015-10-20  7:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-18 23:59 Regression since commit 92bac83 Larry Finger
2015-10-19  8:08 ` Hans de Goede
2015-10-19 15:55   ` Larry Finger
2015-10-19 16:51     ` Dmitry Torokhov
2015-10-19 17:21       ` Hans de Goede
2015-10-20  7:22       ` Pali Rohár [this message]
2015-10-20  7:22         ` Pali Rohár
2015-10-20 11:39     ` Hans de Goede
2015-10-20 17:33       ` Larry Finger
2015-10-21  8:19       ` Pali Rohár
2015-10-21  8:19         ` Pali Rohár
2015-10-21  8:30         ` Hans de Goede
2015-10-21  8:30           ` Hans de Goede
2015-10-21  8:37           ` Pali Rohár

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151020072223.GC22600@pali \
    --to=pali.rohar@gmail.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masaki.ota@jp.alps.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.