On Wed, Feb 07, 2024 at 10:39:03AM -0600, Jonathan Denose wrote: > Hi Dmitry, > > Thanks for your reply. > > On Tue, Feb 6, 2024 at 4:04 PM Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > > > Hi Jonathan, > > > > On Thu, Nov 02, 2023 at 07:52:47AM -0500, Jonathan Denose wrote: > > > 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
