Sure thing!

Attached is the dmesg output with the i8042.debug option and without
the change in this patch.

On Fri, Feb 9, 2024 at 1:02 PM Dmitry Torokhov
[off-list ref] wrote:

On Wed, Feb 07, 2024 at 10:39:03AM -0600, Jonathan Denose wrote:

quoted

Hi Dmitry,

Thanks for your reply.

On Tue, Feb 6, 2024 at 4:04 PM Dmitry Torokhov
[off-list ref] wrote:

quoted

Hi Jonathan,

On Thu, Nov 02, 2023 at 07:52:47AM -0500, Jonathan Denose wrote:

quoted

Some elantech touchpads consistently fail after resuming from
suspend at sanity_check in elantech_packet_check_v4. This means
the touchpad is completely unusable after suspend resume.

With different permutations of i8042 nomux, nopnp, reset, and noloop
kernel options enabled, and with crc_enabled the touchpad fails in
the same way.

Resyncing the touchpad after receiving the
PACKET_UNKNOWN/PSMOUSE_BAD_DATA return code allows the touchpad to
function correctly on resume. The touchpad fails to reconnect with
the serio reconnect no matter how many times it retries, so this
change skips over that retry sequence and goes directly to resync.

Why can't we do this in elantech_reconnect()? I am sure we can make it
simpler and more robust than what the generic handler is trying to do
with polling and everything.

Thanks.

--
Dmitry

I am fine with anything that would be simpler and more robust, though
I'm not sure how to implement what you are describing.

Are you suggesting that in this PSMOUSE_BAD_DATA case, instead of
using psmouse_set_state and psmouse_queue_work to call
psmouse->reconnect (which calls elantech_reconnect)?

No. From the description it sounds like the device sends wrong/extra
data right after resume. I think you can handle it in
elantech_reconnect() method by draining the buffer or issuing poll
request or something similar.

Can you post the i8042 data stream that happens on suspend/resume?
Toggling i8042.debug option will cause the driver to dump the data to
dmesg.

Thanks.

--
Dmitry