From: Laura Abbott <labbott@redhat.com>
To: Paul Donohue <linux-kernel@PaulSD.com>,
Masaki Ota <masaki.ota@jp.alps.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-input@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"scott.s.lowe@gmail.com" <scott.s.lowe@gmail.com>
Subject: Re: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")
Date: Mon, 19 Jun 2017 13:02:18 -0700 [thread overview]
Message-ID: <0995261b-8d19-64af-9b66-e1eab579a3d4@redhat.com> (raw)
In-Reply-To: <20170619184315.GF1855@TopQuark.net>
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
>>>>>
>>>
>>
next prev parent reply other threads:[~2017-06-19 20:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-02 17:54 Laura Abbott
2017-06-03 4:03 ` Paul Donohue
2017-06-06 16:59 ` Laura Abbott
2017-06-12 5:25 ` Masaki Ota
2017-06-14 18:52 ` Laura Abbott
2017-06-15 0:33 ` Masaki Ota
2017-06-19 18:43 ` Paul Donohue
2017-06-19 20:02 ` Laura Abbott [this message]
2017-06-19 23:20 ` Paul Donohue
2017-07-11 15:50 ` Takashi Iwai
2017-07-11 19:58 ` Paul Donohue
2017-07-12 7:16 ` Takashi Iwai
2017-07-12 16:28 ` Paul Donohue
2017-07-19 8:57 ` Takashi Iwai
2017-07-20 9:20 ` Masaki Ota
2017-07-20 9:35 ` Takashi Iwai
2017-07-20 10:02 ` Masaki Ota
2017-07-20 10:43 ` Takashi Iwai
2017-07-22 18:57 ` Paul Donohue
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=0995261b-8d19-64af-9b66-e1eab579a3d4@redhat.com \
--to=labbott@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@PaulSD.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masaki.ota@jp.alps.com \
--cc=nick.m.fletcher@gmail.com \
--cc=pali.rohar@gmail.com \
--cc=scott.s.lowe@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®