Synaptics touchpad reset issue

Synaptics touchpad reset issue

[Tuomas Räsänen]

Hi

We've noticed a quite bizarre touchpad behavior on one specific laptop
model, namely Acer TravelMate B115-M: occasionally the touchpad gets
really confused under normal usage and begins to emit events
autonomously, i.e. without any object touching the surface, which
results in a totally uncontrollable jumpy pointer. On some occasions,
the end result is a completely unresponsive, stationary pointer.

Disabling and enabling the touchpad via Fn+F7 (the touchpad toggle
function) or suspend+resume resets the condition back to normal.

The touchpad is handled by psmouse driver. Removing and re-adding
psmouse module does not fix the issue.

Reproducing the symptoms under normal usage is quite difficult, but
fortunately we (or to be more precise, Petri Toivola) found out that
sliding a moist paper (a cleaning wipe) on the touchpad to make a full
circle triggers the exactly same behavior (to be really precise, it does
not trigger when the surface gets moist, but when it dries up, around
1-2 seconds). We call it The Wet Circle of Death.

Similar behavior can be observed also on Windows 7:
https://www.youtube.com/watch?v=nDLIVuBmTOY

To me it seems like the touchpad somehow recalibrates itself and becomes
highly sensitive and begins to emits touch events even when there's no
one touching it. The sensitiveness can be observed by looking at MT_ABS
values: in normal conditions maximum values are around 120, but in
confused state they are around 190.

Now, I wonder if there's anything I can do to fix this
"programmatically"?

I ftraced during Fn+F7 and it seemed to make just several ACPI reads and
writes, the driver was not involved, and on the other hand, quite
obviously, no ACPI calls were involved when modprobing, which explains
why modprobing did not fix issue.

Are those ACPI spells something the driver could be expanded to make?

Is there anything the driver could do more to make the touchpad reset
"properly"?

On `modprobe psmouse`, dmesg says:

  [87072.953080] psmouse serio2: synaptics: queried max coordinates: x [..5662], y [..4728]
  [87072.982742] psmouse serio2: synaptics: queried min coordinates: x [1322..], y [1190..]
  [87073.040285] psmouse serio2: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd40123/0x840300/0x126800, board id: 2991, fw id: 1626681
  [87073.077169] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input88

I've tested on different kernel versions, 4.2.5 and 4.0.6 (and also on
Ubuntu 3.13.0-55.94-generic), all behave the same.

-- 
Tuomas

Re: Synaptics touchpad reset issue

[Andrew Duggan]

Hi Tuomas,

It looks like some other people have reported similar issues with this
particular touchpad module. I think there might be a hardware issue
with some touchpads with the board/product id of 2991. Since this
maybe a hardware issue there might not be a fix, but there might be a
work around. This touchpad has a HID/I2C interface in addition to the
PS/2 interface.

You should see a line in dmesg which looks something like this:
hid-multitouch 0018:06CB:2991.0001: input,hidraw0: <UNKNOWN> HID v1.00
Mouse [SYN1B7F:00 06CB:2991] on

If you download and build rmihidtool
(https://github.com/aduggan/rmi4utils), you can manually reset the
touchpad and hopefully return it to a working state. The Fn+F7 on
Windows is probably doing something similar by either cutting power to
the touchpad or forcing a reset.

Running this command will reset the touchpad:
$ sudo rmihidtool -e /dev/hidraw0

If the touchpad stops working completely then you may need to rebind
the driver so that the touchpad is put back into PTP mode:
$ sudo rmihidtool -b /dev/hidraw0


On Mon, Nov 23, 2015 at 1:43 AM, Tuomas Räsänen
<tuomasjjrasanen@opinsys.fi> wrote:
> Hi
>
> We've noticed a quite bizarre touchpad behavior on one specific laptop
> model, namely Acer TravelMate B115-M: occasionally the touchpad gets
> really confused under normal usage and begins to emit events
> autonomously, i.e. without any object touching the surface, which
> results in a totally uncontrollable jumpy pointer. On some occasions,
> the end result is a completely unresponsive, stationary pointer.
>
> Disabling and enabling the touchpad via Fn+F7 (the touchpad toggle
> function) or suspend+resume resets the condition back to normal.
>
> The touchpad is handled by psmouse driver. Removing and re-adding
> psmouse module does not fix the issue.
>
> Reproducing the symptoms under normal usage is quite difficult, but
> fortunately we (or to be more precise, Petri Toivola) found out that
> sliding a moist paper (a cleaning wipe) on the touchpad to make a full
> circle triggers the exactly same behavior (to be really precise, it does
> not trigger when the surface gets moist, but when it dries up, around
> 1-2 seconds). We call it The Wet Circle of Death.
>
> Similar behavior can be observed also on Windows 7:
> https://www.youtube.com/watch?v=nDLIVuBmTOY
>
> To me it seems like the touchpad somehow recalibrates itself and becomes
> highly sensitive and begins to emits touch events even when there's no
> one touching it. The sensitiveness can be observed by looking at MT_ABS
> values: in normal conditions maximum values are around 120, but in
> confused state they are around 190.
>

Do you mean EV_ABS? I'm not quite sure which values would have a
normal max of around 120. Generally, these types of situations where
false contacts are being reported are hard to distinguish in the
firmware or driver from real contacts. Even if you notice a specific
pattern on your particular system it might manifest itself differently
on other systems.

Andrew

> Now, I wonder if there's anything I can do to fix this
> "programmatically"?
>
> I ftraced during Fn+F7 and it seemed to make just several ACPI reads and
> writes, the driver was not involved, and on the other hand, quite
> obviously, no ACPI calls were involved when modprobing, which explains
> why modprobing did not fix issue.
>
> Are those ACPI spells something the driver could be expanded to make?
>
> Is there anything the driver could do more to make the touchpad reset
> "properly"?
>
> On `modprobe psmouse`, dmesg says:
>
>   [87072.953080] psmouse serio2: synaptics: queried max coordinates: x [..5662], y [..4728]
>   [87072.982742] psmouse serio2: synaptics: queried min coordinates: x [1322..], y [1190..]
>   [87073.040285] psmouse serio2: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd40123/0x840300/0x126800, board id: 2991, fw id: 1626681
>   [87073.077169] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input88
>
> I've tested on different kernel versions, 4.2.5 and 4.0.6 (and also on
> Ubuntu 3.13.0-55.94-generic), all behave the same.
>
> --
> Tuomas
> --
> 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
--
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

Re: Synaptics touchpad reset issue

[Tuomas Räsänen]

On Wed, Nov 25, 2015 at 05:15:44PM -0800, Andrew Duggan wrote:
> Hi Tuomas,
> 

Hi Andrew and thanks for the reply,

> It looks like some other people have reported similar issues with this
> particular touchpad module. I think there might be a hardware issue
> with some touchpads with the board/product id of 2991. Since this
> maybe a hardware issue there might not be a fix, but there might be a
> work around. This touchpad has a HID/I2C interface in addition to the
> PS/2 interface.
> 

Yes, I agree it's definitely a hardware issue. I'm just trying gather up
all bits and pieces to make an ugly but simple workaround:

 1. detect a malfunction by observing pressure values (just a simple threshold heuristic)
 2. reset the device when it's malfunctioning

> You should see a line in dmesg which looks something like this:
> hid-multitouch 0018:06CB:2991.0001: input,hidraw0: <UNKNOWN> HID v1.00
> Mouse [SYN1B7F:00 06CB:2991] on
> 

Yes, I just had to visit BIOS and set the touchpad operation mode to
"advanced".

> If you download and build rmihidtool
> (https://github.com/aduggan/rmi4utils), you can manually reset the
> touchpad and hopefully return it to a working state. The Fn+F7 on
> Windows is probably doing something similar by either cutting power to
> the touchpad or forcing a reset.
> 
> Running this command will reset the touchpad:
> $ sudo rmihidtool -e /dev/hidraw0
> 

Seems to work as expected.

> If the touchpad stops working completely then you may need to rebind
> the driver so that the touchpad is put back into PTP mode:
> $ sudo rmihidtool -b /dev/hidraw0
> 

Yes, rebind was required after a reset.

> >
> > To me it seems like the touchpad somehow recalibrates itself and becomes
> > highly sensitive and begins to emits touch events even when there's no
> > one touching it. The sensitiveness can be observed by looking at MT_ABS
> > values: in normal conditions maximum values are around 120, but in
> > confused state they are around 190.
> >
> 
> Do you mean EV_ABS?

I actually meant ABS_MT_PRESSURE.

> I'm not quite sure which values would have a
> normal max of around 120.

ABS_MT_PRESSURE values when synaptics PS/2 driver is managing the
device.

> Generally, these types of situations where
> false contacts are being reported are hard to distinguish in the
> firmware or driver from real contacts. Even if you notice a specific
> pattern on your particular system it might manifest itself differently
> on other systems.
> 

Yes, but here I'm trying to come up with an ugly workaround for this
specific device model. I guess it's quite safe to assume that all
devices with identical hardware generate sufficiently similar values,
no?

All in all, reseting the device via hidraw turned out to fix the
malfunction reliably. Thanks!!

But.

When the device is in HID/I2C mode, ABS_MT_PRESSURE events are not
available via the input device because hid-multitouch does not emit them
probably because device's report descriptor is missing
HID_DG_TIPPRESSURE usage? Otherwise it would have been mapped to
ABS_MT_PRESSURE, according to hid-multitouch.c.

On the other hand, in PS/2 mode, synaptics psmouse delivers pressure
events, but I don't know how to reset the device.

Perhaps I'll check raw HID reports if they contain pressure values, but
if they don't, I'm probably going to give up working around the problem.

One additional, probably silly, question though: because Fn+F7 always
fixes the problem under the hood, is it handled by the hardware or by
the kernel?

I decompiled DSDT and looked for methods of the device (TPD8), but
didn't see anything interesting, other than _DSM, which is probably a
standard ACPI method, Device Specific Method?. So I was wondering if it's
possible to reset the touchpad using some special ACPI method?

-- 
Tuomas

Re: Synaptics touchpad reset issue

[Andrew Duggan]

On Thu, Nov 26, 2015 at 7:12 AM, Tuomas Räsänen
<tuomasjjrasanen@opinsys.fi> wrote:
> On Wed, Nov 25, 2015 at 05:15:44PM -0800, Andrew Duggan wrote:
>> Hi Tuomas,
>>
>
> Hi Andrew and thanks for the reply,
>
>> It looks like some other people have reported similar issues with this
>> particular touchpad module. I think there might be a hardware issue
>> with some touchpads with the board/product id of 2991. Since this
>> maybe a hardware issue there might not be a fix, but there might be a
>> work around. This touchpad has a HID/I2C interface in addition to the
>> PS/2 interface.
>>
>
> Yes, I agree it's definitely a hardware issue. I'm just trying gather up
> all bits and pieces to make an ugly but simple workaround:
>
>  1. detect a malfunction by observing pressure values (just a simple threshold heuristic)
>  2. reset the device when it's malfunctioning
>
>> You should see a line in dmesg which looks something like this:
>> hid-multitouch 0018:06CB:2991.0001: input,hidraw0: <UNKNOWN> HID v1.00
>> Mouse [SYN1B7F:00 06CB:2991] on
>>
>
> Yes, I just had to visit BIOS and set the touchpad operation mode to
> "advanced".

Interesting, I thought it would be enabled by default.

>
>> If you download and build rmihidtool
>> (https://github.com/aduggan/rmi4utils), you can manually reset the
>> touchpad and hopefully return it to a working state. The Fn+F7 on
>> Windows is probably doing something similar by either cutting power to
>> the touchpad or forcing a reset.
>>
>> Running this command will reset the touchpad:
>> $ sudo rmihidtool -e /dev/hidraw0
>>
>
> Seems to work as expected.
>
>> If the touchpad stops working completely then you may need to rebind
>> the driver so that the touchpad is put back into PTP mode:
>> $ sudo rmihidtool -b /dev/hidraw0
>>
>
> Yes, rebind was required after a reset.
>
>> >
>> > To me it seems like the touchpad somehow recalibrates itself and becomes
>> > highly sensitive and begins to emits touch events even when there's no
>> > one touching it. The sensitiveness can be observed by looking at MT_ABS
>> > values: in normal conditions maximum values are around 120, but in
>> > confused state they are around 190.
>> >
>>
>> Do you mean EV_ABS?
>
> I actually meant ABS_MT_PRESSURE.
>
>> I'm not quite sure which values would have a
>> normal max of around 120.
>
> ABS_MT_PRESSURE values when synaptics PS/2 driver is managing the
> device.
>
>> Generally, these types of situations where
>> false contacts are being reported are hard to distinguish in the
>> firmware or driver from real contacts. Even if you notice a specific
>> pattern on your particular system it might manifest itself differently
>> on other systems.
>>
>
> Yes, but here I'm trying to come up with an ugly workaround for this
> specific device model. I guess it's quite safe to assume that all
> devices with identical hardware generate sufficiently similar values,
> no?
>

Touchpads can be influenced by environmental factors so its not always
safe to assume that problems will manifest themselves in the same way
even when the hardware is the same. However, pressure values of 190 do
seem to be outside the values which we usually report. Doing a reset
on large pressure values reported by this particular touchpad could be
a reasonable workaround.

> All in all, reseting the device via hidraw turned out to fix the
> malfunction reliably. Thanks!!
>
> But.
>
> When the device is in HID/I2C mode, ABS_MT_PRESSURE events are not
> available via the input device because hid-multitouch does not emit them
> probably because device's report descriptor is missing
> HID_DG_TIPPRESSURE usage? Otherwise it would have been mapped to
> ABS_MT_PRESSURE, according to hid-multitouch.c.
>
> On the other hand, in PS/2 mode, synaptics psmouse delivers pressure
> events, but I don't know how to reset the device.
>

Unfortunately, there isn't a way to send the reset command via the
PS/2 interface.

> Perhaps I'll check raw HID reports if they contain pressure values, but
> if they don't, I'm probably going to give up working around the problem.
>

No, we don't report pressure in the HID reports in PTP mode. There is
a way to get the pressure data if you run it in RMI mode. I'm working
on a driver which would support this touchpad running in RMI mode so
when that driver is ready we could add something that does a reset in
there.

> One additional, probably silly, question though: because Fn+F7 always
> fixes the problem under the hood, is it handled by the hardware or by
> the kernel?
>

I think Fn+F7 is disabling the touchpad in the bios. I'm not an expert
on how this works, but I would assume that the ACPI commands are
telling the bios to do that. If the bios may be cutting power to the
touchpad which would get it out of that state.

Andrew

> I decompiled DSDT and looked for methods of the device (TPD8), but
> didn't see anything interesting, other than _DSM, which is probably a
> standard ACPI method, Device Specific Method?. So I was wondering if it's
> possible to reset the touchpad using some special ACPI method?
>
> --
> Tuomas
--
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