[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALNJtpV0KsOusPQeGv8bQ3jKy2sUj+k=mPHc172f+vMaTDYPfg@mail.gmail.com>
Date: Wed, 7 Feb 2024 10:39:03 -0600
From: Jonathan Denose <jdenose@...omium.org>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, jefferymiller@...gle.com,
Jonathan Denose <jdenose@...gle.com>, Raul Rangel <rrangel@...omium.org>, linux-input@...r.kernel.org
Subject: Re: [PATCH] Input: psmouse - add resync_on_resume dmi check
Hi Dmitry,
Thanks for your reply.
On Tue, Feb 6, 2024 at 4:04 PM Dmitry Torokhov
<dmitry.torokhov@...il.com> 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)?
Jonathan
Powered by blists - more mailing lists