Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1663249 > unrolled thread

RE: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")

Started byMasaki Ota <masaki.ota@jp.alps.com>
First post2017-06-12 07:30 +0200
Last post2017-06-20 01:30 +0200
Articles 6 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS -  fix V8+ protocol handling (73 03 28)") Masaki Ota <masaki.ota@jp.alps.com> - 2017-06-12 07:30 +0200
    Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS -  fix V8+ protocol handling (73 03 28)") Laura Abbott <labbott@redhat.com> - 2017-06-14 21:00 +0200
      RE: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS -  fix V8+ protocol handling (73 03 28)") Masaki Ota <masaki.ota@jp.alps.com> - 2017-06-15 02:40 +0200
        Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS -  fix V8+ protocol handling (73 03 28)") Paul Donohue <linux-kernel@PaulSD.com> - 2017-06-19 20:50 +0200
          Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS -  fix V8+ protocol handling (73 03 28)") Laura Abbott <labbott@redhat.com> - 2017-06-19 22:10 +0200
            Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS -  fix V8+ protocol handling (73 03 28)") Paul Donohue <linux-kernel@PaulSD.com> - 2017-06-20 01:30 +0200

#1663249 — RE: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")

FromMasaki Ota <masaki.ota@jp.alps.com>
Date2017-06-12 07:30 +0200
SubjectRE: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")
Message-ID<tRq5j-6qt-1@gated-at.bofh.it>
Hi, Laura,

Could you try to check below modification?
https://bugzilla.kernel.org/show_bug.cgi?id=195215#c10

This thread person said, the issue was fixed by this change.
I guess it's a XY coordinate setting problem, though the code that before the patch is applied also has a problem.

Best Regards,
Masaki Ota
-----Original Message-----
From: Laura Abbott [mailto:labbott@redhat.com] 
Sent: Wednesday, June 07, 2017 1:59 AM
To: Paul Donohue <linux-kernel@PaulSD.com>
Cc: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; Dmitry Torokhov <dmitry.torokhov@gmail.com>; Pali Rohar <pali.rohar@gmail.com>; Nick Fletcher <nick.m.fletcher@gmail.com>; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; scott.s.lowe@gmail.com
Subject: Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")

On 06/02/2017 09:03 PM, Paul Donohue wrote:
> This might be related to 
> https://bugzilla.kernel.org/show_bug.cgi?id=195215
> 
> Could you have the user try this change? 
> https://bugzilla.kernel.org/show_bug.cgi?id=195215#c12
> 

https://bugzilla.redhat.com/show_bug.cgi?id=1447327#c13

"Cursor movement seems to work, but there are intermittent two-finger scrolling issues on the right-hand side of the touchpad. There are no issues with cursor movement or two-finger scrolling on the left-hand side of the touchpad."

> On Fri, Jun 02, 2017 at 10:54:52AM -0700, Laura Abbott wrote:
>> Hi,
>>
>> Fedora got a bug report 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1447327
>> of a touchpad failure on a Dell Latitude E7370. Testing showed that 
>> the bad commit was
>>
>> commit e7348396c6d51b57c95c6646c390cd078e038e19
>> Author: Masaki Ota <masaki.ota@jp.alps.com>
>> Date:   Fri Mar 17 14:10:57 2017 -0700
>>
>>     Input: ALPS - fix V8+ protocol handling (73 03 28)
>>     
>>     Devices identified as E7="73 03 28" use slightly modified version of V8
>>     protocol, with lower count per electrode, different offsets, and different
>>     feature bits in OTP data.
>>     
>>     Fixes: aeaa881f9b17 ("Input: ALPS - set DualPoint flag for 74 03 28 devices")
>>     Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
>>     Acked-by: Pali Rohar <pali.rohar@gmail.com>
>>     Tested-by: Paul Donohue <linux-kernel@PaulSD.com>
>>     Tested-by: Nick Fletcher <nick.m.fletcher@gmail.com>
>>     Cc: stable@vger.kernel.org
>>     Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>
>> I suspect this particular model needs special handling as well?
>>
>> Thanks,
>> Laura
>>

[toc] | [next] | [standalone]

#1666152

FromLaura Abbott <labbott@redhat.com>
Date2017-06-14 21:00 +0200
Message-ID<tSlGi-od-21@gated-at.bofh.it>
In reply to#1663249
On 06/11/2017 10:25 PM, Masaki Ota wrote:
> Hi, Laura,
> 
> Could you try to check below modification?
> https://bugzilla.kernel.org/show_bug.cgi?id=195215#c10
> 
> This thread person said, the issue was fixed by this change.
> I guess it's a XY coordinate setting problem, though the code that before the patch is applied also has a problem.
> 

With the previous patch plus the part you suggested:

"it appears as if this resolves all remaining touchpad issues.
Cursor movement works as expected, both on the left-hand and right-hand
sides of the touchpad, and I did not see any issues with two-finger
scrolling on either side of the touchpad. Behavior with this test
build appeared to be identical to 4.10.5, the last "official" kernel
release to work with my touchpad."

So it sounds like both parts together fix the issue.

Thanks,
Laura

> Best Regards,
> Masaki Ota
> -----Original Message-----
> From: Laura Abbott [mailto:labbott@redhat.com] 
> Sent: Wednesday, June 07, 2017 1:59 AM
> To: Paul Donohue <linux-kernel@PaulSD.com>
> Cc: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; Dmitry Torokhov <dmitry.torokhov@gmail.com>; Pali Rohar <pali.rohar@gmail.com>; Nick Fletcher <nick.m.fletcher@gmail.com>; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; scott.s.lowe@gmail.com
> Subject: Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")
> 
> On 06/02/2017 09:03 PM, Paul Donohue wrote:
>> This might be related to 
>> https://bugzilla.kernel.org/show_bug.cgi?id=195215
>>
>> Could you have the user try this change? 
>> https://bugzilla.kernel.org/show_bug.cgi?id=195215#c12
>>
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1447327#c13
> 
> "Cursor movement seems to work, but there are intermittent two-finger scrolling issues on the right-hand side of the touchpad. There are no issues with cursor movement or two-finger scrolling on the left-hand side of the touchpad."
> 
>> On Fri, Jun 02, 2017 at 10:54:52AM -0700, Laura Abbott wrote:
>>> Hi,
>>>
>>> Fedora got a bug report 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1447327
>>> of a touchpad failure on a Dell Latitude E7370. Testing showed that 
>>> the bad commit was
>>>
>>> commit e7348396c6d51b57c95c6646c390cd078e038e19
>>> Author: Masaki Ota <masaki.ota@jp.alps.com>
>>> Date:   Fri Mar 17 14:10:57 2017 -0700
>>>
>>>     Input: ALPS - fix V8+ protocol handling (73 03 28)
>>>     
>>>     Devices identified as E7="73 03 28" use slightly modified version of V8
>>>     protocol, with lower count per electrode, different offsets, and different
>>>     feature bits in OTP data.
>>>     
>>>     Fixes: aeaa881f9b17 ("Input: ALPS - set DualPoint flag for 74 03 28 devices")
>>>     Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
>>>     Acked-by: Pali Rohar <pali.rohar@gmail.com>
>>>     Tested-by: Paul Donohue <linux-kernel@PaulSD.com>
>>>     Tested-by: Nick Fletcher <nick.m.fletcher@gmail.com>
>>>     Cc: stable@vger.kernel.org
>>>     Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>>
>>> I suspect this particular model needs special handling as well?
>>>
>>> Thanks,
>>> Laura
>>>
>

[toc] | [prev] | [next] | [standalone]

#1666335

FromMasaki Ota <masaki.ota@jp.alps.com>
Date2017-06-15 02:40 +0200
Message-ID<tSqZj-3NT-1@gated-at.bofh.it>
In reply to#1666152
Hi, Paul, Dmitry,

About Laura's test result, it seems like this issue has to do with x_max, y_max, x_res, y_res.
This values are set as following code.
	input_set_abs_params(dev1, ABS_MT_POSITION_X, 0, priv->x_max, 0, 0);
	input_set_abs_params(dev1, ABS_MT_POSITION_Y, 0, priv->y_max, 0, 0);

	input_abs_set_res(dev1, ABS_MT_POSITION_X, priv->x_res);
	input_abs_set_res(dev1, ABS_MT_POSITION_Y, priv->y_res);

For testing this code, I assigned an abnormal value to x_max, y_max , and it seems to effect only cursor speed.
About x_res, y_res , there is no effect, even if I set an abnormal value.(need this code?)
I don't understand why these values have to do with this issue.

Can you guess the root cause of this issue?

Best Regards,
Masaki Ota
-----Original Message-----
From: Laura Abbott [mailto:labbott@redhat.com] 
Sent: Thursday, June 15, 2017 3:53 AM
To: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; Paul Donohue <linux-kernel@PaulSD.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Pali Rohar <pali.rohar@gmail.com>; Nick Fletcher <nick.m.fletcher@gmail.com>; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; scott.s.lowe@gmail.com
Subject: Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")

On 06/11/2017 10:25 PM, Masaki Ota wrote:
> Hi, Laura,
> 
> Could you try to check below modification?
> https://bugzilla.kernel.org/show_bug.cgi?id=195215#c10
> 
> This thread person said, the issue was fixed by this change.
> I guess it's a XY coordinate setting problem, though the code that before the patch is applied also has a problem.
> 

With the previous patch plus the part you suggested:

"it appears as if this resolves all remaining touchpad issues.
Cursor movement works as expected, both on the left-hand and right-hand sides of the touchpad, and I did not see any issues with two-finger scrolling on either side of the touchpad. Behavior with this test build appeared to be identical to 4.10.5, the last "official" kernel release to work with my touchpad."

So it sounds like both parts together fix the issue.

Thanks,
Laura

> Best Regards,
> Masaki Ota
> -----Original Message-----
> From: Laura Abbott [mailto:labbott@redhat.com]
> Sent: Wednesday, June 07, 2017 1:59 AM
> To: Paul Donohue <linux-kernel@PaulSD.com>
> Cc: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; Dmitry Torokhov 
> <dmitry.torokhov@gmail.com>; Pali Rohar <pali.rohar@gmail.com>; Nick 
> Fletcher <nick.m.fletcher@gmail.com>; linux-input@vger.kernel.org; 
> linux-kernel@vger.kernel.org; scott.s.lowe@gmail.com
> Subject: Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: 
> ALPS - fix V8+ protocol handling (73 03 28)")
> 
> On 06/02/2017 09:03 PM, Paul Donohue wrote:
>> This might be related to
>> https://bugzilla.kernel.org/show_bug.cgi?id=195215
>>
>> Could you have the user try this change? 
>> https://bugzilla.kernel.org/show_bug.cgi?id=195215#c12
>>
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1447327#c13
> 
> "Cursor movement seems to work, but there are intermittent two-finger scrolling issues on the right-hand side of the touchpad. There are no issues with cursor movement or two-finger scrolling on the left-hand side of the touchpad."
> 
>> On Fri, Jun 02, 2017 at 10:54:52AM -0700, Laura Abbott wrote:
>>> Hi,
>>>
>>> Fedora got a bug report
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1447327
>>> of a touchpad failure on a Dell Latitude E7370. Testing showed that 
>>> the bad commit was
>>>
>>> commit e7348396c6d51b57c95c6646c390cd078e038e19
>>> Author: Masaki Ota <masaki.ota@jp.alps.com>
>>> Date:   Fri Mar 17 14:10:57 2017 -0700
>>>
>>>     Input: ALPS - fix V8+ protocol handling (73 03 28)
>>>     
>>>     Devices identified as E7="73 03 28" use slightly modified version of V8
>>>     protocol, with lower count per electrode, different offsets, and different
>>>     feature bits in OTP data.
>>>     
>>>     Fixes: aeaa881f9b17 ("Input: ALPS - set DualPoint flag for 74 03 28 devices")
>>>     Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
>>>     Acked-by: Pali Rohar <pali.rohar@gmail.com>
>>>     Tested-by: Paul Donohue <linux-kernel@PaulSD.com>
>>>     Tested-by: Nick Fletcher <nick.m.fletcher@gmail.com>
>>>     Cc: stable@vger.kernel.org
>>>     Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>>
>>> I suspect this particular model needs special handling as well?
>>>
>>> Thanks,
>>> Laura
>>>
>

[toc] | [prev] | [next] | [standalone]

#1669649

FromPaul Donohue <linux-kernel@PaulSD.com>
Date2017-06-19 20:50 +0200
Message-ID<tU9Um-6lI-35@gated-at.bofh.it>
In reply to#1666335
I get the same results as you - x_max and y_max affect cursor speed, and x_res and y_res seem to have no effect.  I can't seem to come up with any values that cause intermittent cursor issues on one side of the touchpad.
Both max and res do get passed up to the X driver, and I do see references to both max and resolution in xf86-input-evdev, although I haven't actually traced it through to see if/where each value is actually consumed with my setup.

Maybe we should ask the user to try a few more tests?
1) Using the original code (without the modifications from bug 195215), add the following before 'return 0' at the end of alps_update_device_area_ss4_v2(), then run `dmesg | grep num-electrodes` after loading the alps kernel module to get the output.  This should tell us what values the user is actually reading from the hardware:
psmouse_err(psmouse,
    "pitch %dx%d num-electrodes %dx%d physical size %dx%dmm res %dx%d max %dx%d\n",
    x_pitch, y_pitch, num_x_electrode, num_y_electrode,
    x_phys / 10, y_phys / 10, priv->x_res, priv->y_res, priv->x_max, priv->y_max);
2) Use the old electrode count code but the new pitch code:
	if (IS_SS4PLUS_DEV(priv->dev_id)) {
		num_x_electrode =
			SS4_NUMSENSOR_XOFFSET + (otp[1][0] & 0x0F);
		num_y_electrode =
			SS4_NUMSENSOR_YOFFSET + ((otp[1][0] >> 4) & 0x0F);

		priv->x_max =
			(num_x_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
		priv->y_max =
			(num_y_electrode - 1) * SS4_COUNT_PER_ELECTRODE;

		x_pitch = (otp[0][1] & 0x0F) + SS4PLUS_MIN_PITCH_MM;
		y_pitch = ((otp[0][1] >> 4) & 0x0F) + SS4PLUS_MIN_PITCH_MM;

	} else {
3) Use the new electrode count code but the old pitch code:
	if (IS_SS4PLUS_DEV(priv->dev_id)) {
		num_x_electrode =
			SS4PLUS_NUMSENSOR_XOFFSET + (otp[0][2] & 0x0F);
		num_y_electrode =
			SS4PLUS_NUMSENSOR_YOFFSET + ((otp[0][2] >> 4) & 0x0F);

		priv->x_max =
			(num_x_electrode - 1) * SS4PLUS_COUNT_PER_ELECTRODE;
		priv->y_max =
			(num_y_electrode - 1) * SS4PLUS_COUNT_PER_ELECTRODE;

		x_pitch = ((otp[1][2] >> 2) & 0x07) + SS4_MIN_PITCH_MM;
		y_pitch = ((otp[1][2] >> 5) & 0x07) + SS4_MIN_PITCH_MM;

	} else {

On Thu, Jun 15, 2017 at 12:33:29AM +0000, Masaki Ota wrote:
> Hi, Paul, Dmitry,
> 
> About Laura's test result, it seems like this issue has to do with x_max, y_max, x_res, y_res.
> This values are set as following code.
> 	input_set_abs_params(dev1, ABS_MT_POSITION_X, 0, priv->x_max, 0, 0);
> 	input_set_abs_params(dev1, ABS_MT_POSITION_Y, 0, priv->y_max, 0, 0);
> 
> 	input_abs_set_res(dev1, ABS_MT_POSITION_X, priv->x_res);
> 	input_abs_set_res(dev1, ABS_MT_POSITION_Y, priv->y_res);
> 
> For testing this code, I assigned an abnormal value to x_max, y_max , and it seems to effect only cursor speed.
> About x_res, y_res , there is no effect, even if I set an abnormal value.(need this code?)
> I don't understand why these values have to do with this issue.
> 
> Can you guess the root cause of this issue?
> 
> Best Regards,
> Masaki Ota
> -----Original Message-----
> From: Laura Abbott [mailto:labbott@redhat.com] 
> Sent: Thursday, June 15, 2017 3:53 AM
> To: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; Paul Donohue <linux-kernel@PaulSD.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Pali Rohar <pali.rohar@gmail.com>; Nick Fletcher <nick.m.fletcher@gmail.com>; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; scott.s.lowe@gmail.com
> Subject: Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")
> 
> On 06/11/2017 10:25 PM, Masaki Ota wrote:
> > Hi, Laura,
> > 
> > Could you try to check below modification?
> > https://bugzilla.kernel.org/show_bug.cgi?id=195215#c10
> > 
> > This thread person said, the issue was fixed by this change.
> > I guess it's a XY coordinate setting problem, though the code that before the patch is applied also has a problem.
> > 
> 
> With the previous patch plus the part you suggested:
> 
> "it appears as if this resolves all remaining touchpad issues.
> Cursor movement works as expected, both on the left-hand and right-hand sides of the touchpad, and I did not see any issues with two-finger scrolling on either side of the touchpad. Behavior with this test build appeared to be identical to 4.10.5, the last "official" kernel release to work with my touchpad."
> 
> So it sounds like both parts together fix the issue.
> 
> Thanks,
> Laura
> 
> > Best Regards,
> > Masaki Ota
> > -----Original Message-----
> > From: Laura Abbott [mailto:labbott@redhat.com]
> > Sent: Wednesday, June 07, 2017 1:59 AM
> > To: Paul Donohue <linux-kernel@PaulSD.com>
> > Cc: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; Dmitry Torokhov 
> > <dmitry.torokhov@gmail.com>; Pali Rohar <pali.rohar@gmail.com>; Nick 
> > Fletcher <nick.m.fletcher@gmail.com>; linux-input@vger.kernel.org; 
> > linux-kernel@vger.kernel.org; scott.s.lowe@gmail.com
> > Subject: Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: 
> > ALPS - fix V8+ protocol handling (73 03 28)")
> > 
> > On 06/02/2017 09:03 PM, Paul Donohue wrote:
> >> This might be related to
> >> https://bugzilla.kernel.org/show_bug.cgi?id=195215
> >>
> >> Could you have the user try this change? 
> >> https://bugzilla.kernel.org/show_bug.cgi?id=195215#c12
> >>
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1447327#c13
> > 
> > "Cursor movement seems to work, but there are intermittent two-finger scrolling issues on the right-hand side of the touchpad. There are no issues with cursor movement or two-finger scrolling on the left-hand side of the touchpad."
> > 
> >> On Fri, Jun 02, 2017 at 10:54:52AM -0700, Laura Abbott wrote:
> >>> Hi,
> >>>
> >>> Fedora got a bug report
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1447327
> >>> of a touchpad failure on a Dell Latitude E7370. Testing showed that 
> >>> the bad commit was
> >>>
> >>> commit e7348396c6d51b57c95c6646c390cd078e038e19
> >>> Author: Masaki Ota <masaki.ota@jp.alps.com>
> >>> Date:   Fri Mar 17 14:10:57 2017 -0700
> >>>
> >>>     Input: ALPS - fix V8+ protocol handling (73 03 28)
> >>>     
> >>>     Devices identified as E7="73 03 28" use slightly modified version of V8
> >>>     protocol, with lower count per electrode, different offsets, and different
> >>>     feature bits in OTP data.
> >>>     
> >>>     Fixes: aeaa881f9b17 ("Input: ALPS - set DualPoint flag for 74 03 28 devices")
> >>>     Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
> >>>     Acked-by: Pali Rohar <pali.rohar@gmail.com>
> >>>     Tested-by: Paul Donohue <linux-kernel@PaulSD.com>
> >>>     Tested-by: Nick Fletcher <nick.m.fletcher@gmail.com>
> >>>     Cc: stable@vger.kernel.org
> >>>     Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> >>>
> >>> I suspect this particular model needs special handling as well?
> >>>
> >>> Thanks,
> >>> Laura
> >>>
> > 
>

[toc] | [prev] | [next] | [standalone]

#1669898

FromLaura Abbott <labbott@redhat.com>
Date2017-06-19 22:10 +0200
Message-ID<tUb9L-7kQ-5@gated-at.bofh.it>
In reply to#1669649
On 06/19/2017 11:43 AM, Paul Donohue wrote:
> I get the same results as you - x_max and y_max affect cursor speed, and x_res and y_res seem to have no effect.  I can't seem to come up with any values that cause intermittent cursor issues on one side of the touchpad.
> Both max and res do get passed up to the X driver, and I do see references to both max and resolution in xf86-input-evdev, although I haven't actually traced it through to see if/where each value is actually consumed with my setup.
> 
> Maybe we should ask the user to try a few more tests?
> 1) Using the original code (without the modifications from bug 195215), add the following before 'return 0' at the end of alps_update_device_area_ss4_v2(), then run `dmesg | grep num-electrodes` after loading the alps kernel module to get the output.  This should tell us what values the user is actually reading from the hardware:
> psmouse_err(psmouse,
>     "pitch %dx%d num-electrodes %dx%d physical size %dx%dmm res %dx%d max %dx%d\n",
>     x_pitch, y_pitch, num_x_electrode, num_y_electrode,
>     x_phys / 10, y_phys / 10, priv->x_res, priv->y_res, priv->x_max, priv->y_max);
> 2) Use the old electrode count code but the new pitch code:
> 	if (IS_SS4PLUS_DEV(priv->dev_id)) {
> 		num_x_electrode =
> 			SS4_NUMSENSOR_XOFFSET + (otp[1][0] & 0x0F);
> 		num_y_electrode =
> 			SS4_NUMSENSOR_YOFFSET + ((otp[1][0] >> 4) & 0x0F);
> 
> 		priv->x_max =
> 			(num_x_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
> 		priv->y_max =
> 			(num_y_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
> 
> 		x_pitch = (otp[0][1] & 0x0F) + SS4PLUS_MIN_PITCH_MM;
> 		y_pitch = ((otp[0][1] >> 4) & 0x0F) + SS4PLUS_MIN_PITCH_MM;
> 
> 	} else {
> 3) Use the new electrode count code but the old pitch code:
> 	if (IS_SS4PLUS_DEV(priv->dev_id)) {
> 		num_x_electrode =
> 			SS4PLUS_NUMSENSOR_XOFFSET + (otp[0][2] & 0x0F);
> 		num_y_electrode =
> 			SS4PLUS_NUMSENSOR_YOFFSET + ((otp[0][2] >> 4) & 0x0F);
> 
> 		priv->x_max =
> 			(num_x_electrode - 1) * SS4PLUS_COUNT_PER_ELECTRODE;
> 		priv->y_max =
> 			(num_y_electrode - 1) * SS4PLUS_COUNT_PER_ELECTRODE;
> 
> 		x_pitch = ((otp[1][2] >> 2) & 0x07) + SS4_MIN_PITCH_MM;
> 		y_pitch = ((otp[1][2] >> 5) & 0x07) + SS4_MIN_PITCH_MM;
> 
> 	} else {
> 

Can you produce patches for these test cases?

> On Thu, Jun 15, 2017 at 12:33:29AM +0000, Masaki Ota wrote:
>> Hi, Paul, Dmitry,
>>
>> About Laura's test result, it seems like this issue has to do with x_max, y_max, x_res, y_res.
>> This values are set as following code.
>> 	input_set_abs_params(dev1, ABS_MT_POSITION_X, 0, priv->x_max, 0, 0);
>> 	input_set_abs_params(dev1, ABS_MT_POSITION_Y, 0, priv->y_max, 0, 0);
>>
>> 	input_abs_set_res(dev1, ABS_MT_POSITION_X, priv->x_res);
>> 	input_abs_set_res(dev1, ABS_MT_POSITION_Y, priv->y_res);
>>
>> For testing this code, I assigned an abnormal value to x_max, y_max , and it seems to effect only cursor speed.
>> About x_res, y_res , there is no effect, even if I set an abnormal value.(need this code?)
>> I don't understand why these values have to do with this issue.
>>
>> Can you guess the root cause of this issue?
>>
>> Best Regards,
>> Masaki Ota
>> -----Original Message-----
>> From: Laura Abbott [mailto:labbott@redhat.com] 
>> Sent: Thursday, June 15, 2017 3:53 AM
>> To: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; Paul Donohue <linux-kernel@PaulSD.com>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Pali Rohar <pali.rohar@gmail.com>; Nick Fletcher <nick.m.fletcher@gmail.com>; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; scott.s.lowe@gmail.com
>> Subject: Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")
>>
>> On 06/11/2017 10:25 PM, Masaki Ota wrote:
>>> Hi, Laura,
>>>
>>> Could you try to check below modification?
>>> https://bugzilla.kernel.org/show_bug.cgi?id=195215#c10
>>>
>>> This thread person said, the issue was fixed by this change.
>>> I guess it's a XY coordinate setting problem, though the code that before the patch is applied also has a problem.
>>>
>>
>> With the previous patch plus the part you suggested:
>>
>> "it appears as if this resolves all remaining touchpad issues.
>> Cursor movement works as expected, both on the left-hand and right-hand sides of the touchpad, and I did not see any issues with two-finger scrolling on either side of the touchpad. Behavior with this test build appeared to be identical to 4.10.5, the last "official" kernel release to work with my touchpad."
>>
>> So it sounds like both parts together fix the issue.
>>
>> Thanks,
>> Laura
>>
>>> Best Regards,
>>> Masaki Ota
>>> -----Original Message-----
>>> From: Laura Abbott [mailto:labbott@redhat.com]
>>> Sent: Wednesday, June 07, 2017 1:59 AM
>>> To: Paul Donohue <linux-kernel@PaulSD.com>
>>> Cc: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; Dmitry Torokhov 
>>> <dmitry.torokhov@gmail.com>; Pali Rohar <pali.rohar@gmail.com>; Nick 
>>> Fletcher <nick.m.fletcher@gmail.com>; linux-input@vger.kernel.org; 
>>> linux-kernel@vger.kernel.org; scott.s.lowe@gmail.com
>>> Subject: Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: 
>>> ALPS - fix V8+ protocol handling (73 03 28)")
>>>
>>> On 06/02/2017 09:03 PM, Paul Donohue wrote:
>>>> This might be related to
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=195215
>>>>
>>>> Could you have the user try this change? 
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=195215#c12
>>>>
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1447327#c13
>>>
>>> "Cursor movement seems to work, but there are intermittent two-finger scrolling issues on the right-hand side of the touchpad. There are no issues with cursor movement or two-finger scrolling on the left-hand side of the touchpad."
>>>
>>>> On Fri, Jun 02, 2017 at 10:54:52AM -0700, Laura Abbott wrote:
>>>>> Hi,
>>>>>
>>>>> Fedora got a bug report
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1447327
>>>>> of a touchpad failure on a Dell Latitude E7370. Testing showed that 
>>>>> the bad commit was
>>>>>
>>>>> commit e7348396c6d51b57c95c6646c390cd078e038e19
>>>>> Author: Masaki Ota <masaki.ota@jp.alps.com>
>>>>> Date:   Fri Mar 17 14:10:57 2017 -0700
>>>>>
>>>>>     Input: ALPS - fix V8+ protocol handling (73 03 28)
>>>>>     
>>>>>     Devices identified as E7="73 03 28" use slightly modified version of V8
>>>>>     protocol, with lower count per electrode, different offsets, and different
>>>>>     feature bits in OTP data.
>>>>>     
>>>>>     Fixes: aeaa881f9b17 ("Input: ALPS - set DualPoint flag for 74 03 28 devices")
>>>>>     Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
>>>>>     Acked-by: Pali Rohar <pali.rohar@gmail.com>
>>>>>     Tested-by: Paul Donohue <linux-kernel@PaulSD.com>
>>>>>     Tested-by: Nick Fletcher <nick.m.fletcher@gmail.com>
>>>>>     Cc: stable@vger.kernel.org
>>>>>     Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>>>>
>>>>> I suspect this particular model needs special handling as well?
>>>>>
>>>>> Thanks,
>>>>> Laura
>>>>>
>>>
>>

[toc] | [prev] | [next] | [standalone]

#1670021

FromPaul Donohue <linux-kernel@PaulSD.com>
Date2017-06-20 01:30 +0200
Message-ID<tUehj-Na-5@gated-at.bofh.it>
In reply to#1669898

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 19, 2017 at 01:02:18PM -0700, Laura Abbott wrote:
> On 06/19/2017 11:43 AM, Paul Donohue wrote:
> > I get the same results as you - x_max and y_max affect cursor speed, and x_res and y_res seem to have no effect.  I can't seem to come up with any values that cause intermittent cursor issues on one side of the touchpad.
> > Both max and res do get passed up to the X driver, and I do see references to both max and resolution in xf86-input-evdev, although I haven't actually traced it through to see if/where each value is actually consumed with my setup.
> > 
> > Maybe we should ask the user to try a few more tests?
> > 1) Using the original code (without the modifications from bug 195215), add the following before 'return 0' at the end of alps_update_device_area_ss4_v2(), then run `dmesg | grep num-electrodes` after loading the alps kernel module to get the output.  This should tell us what values the user is actually reading from the hardware:
> > psmouse_err(psmouse,
> >     "pitch %dx%d num-electrodes %dx%d physical size %dx%dmm res %dx%d max %dx%d\n",
> >     x_pitch, y_pitch, num_x_electrode, num_y_electrode,
> >     x_phys / 10, y_phys / 10, priv->x_res, priv->y_res, priv->x_max, priv->y_max);
> > 2) Use the old electrode count code but the new pitch code:
> > 	if (IS_SS4PLUS_DEV(priv->dev_id)) {
> > 		num_x_electrode =
> > 			SS4_NUMSENSOR_XOFFSET + (otp[1][0] & 0x0F);
> > 		num_y_electrode =
> > 			SS4_NUMSENSOR_YOFFSET + ((otp[1][0] >> 4) & 0x0F);
> > 
> > 		priv->x_max =
> > 			(num_x_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
> > 		priv->y_max =
> > 			(num_y_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
> > 
> > 		x_pitch = (otp[0][1] & 0x0F) + SS4PLUS_MIN_PITCH_MM;
> > 		y_pitch = ((otp[0][1] >> 4) & 0x0F) + SS4PLUS_MIN_PITCH_MM;
> > 
> > 	} else {
> > 3) Use the new electrode count code but the old pitch code:
> > 	if (IS_SS4PLUS_DEV(priv->dev_id)) {
> > 		num_x_electrode =
> > 			SS4PLUS_NUMSENSOR_XOFFSET + (otp[0][2] & 0x0F);
> > 		num_y_electrode =
> > 			SS4PLUS_NUMSENSOR_YOFFSET + ((otp[0][2] >> 4) & 0x0F);
> > 
> > 		priv->x_max =
> > 			(num_x_electrode - 1) * SS4PLUS_COUNT_PER_ELECTRODE;
> > 		priv->y_max =
> > 			(num_y_electrode - 1) * SS4PLUS_COUNT_PER_ELECTRODE;
> > 
> > 		x_pitch = ((otp[1][2] >> 2) & 0x07) + SS4_MIN_PITCH_MM;
> > 		y_pitch = ((otp[1][2] >> 5) & 0x07) + SS4_MIN_PITCH_MM;
> > 
> > 	} else {
> > 
> 
> Can you produce patches for these test cases?

I've reduced it to two test cases.  Patches attached.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web