All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Jonathan Denose <jdenose@chromium.org>,
	LKML <linux-kernel@vger.kernel.org>,
	jefferymiller@google.com, Jonathan Denose <jdenose@google.com>,
	Raul Rangel <rrangel@chromium.org>,
	linux-input@vger.kernel.org, Ike Panhc <ike.pan@canonical.com>,
	platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH] Input: psmouse - add resync_on_resume dmi check
Date: Mon, 5 Aug 2024 09:52:10 -0700	[thread overview]
Message-ID: <ZrEDOnxYzbJpC-pH@google.com> (raw)
In-Reply-To: <b9f08bfb-4c1c-4d1b-9061-8a4b1013497d@redhat.com>

Hi Hans,

On Mon, Aug 05, 2024 at 04:18:57PM +0200, Hans de Goede wrote:
> Hi Dmitry,
> 
> On 3/7/24 7:29 PM, Dmitry Torokhov wrote:
> > On Mon, Mar 04, 2024 at 11:17:31AM -0600, Jonathan Denose wrote:
> >> I disabled the ideapad driver by rebuilding the kernel without the
> >> ideapad_laptop module. That does fix the suspend/resume issue!
> >>
> >> Attached are the logs. Is there a way to make this permanent?
> >>
> >> On Thu, Feb 29, 2024 at 12:23 PM Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >>>
> >>> On Mon, Feb 12, 2024 at 02:57:08PM -0600, Jonathan Denose wrote:
> >>> ...
> >>>> [   50.241235] ideapad_acpi VPC2004:00: PM: calling acpi_subsys_resume+0x0/0x5d @ 4492, parent: PNP0C09:00
> >>>> [   50.242055] snd_hda_intel 0000:00:0e.0: PM: pci_pm_resume+0x0/0xed returned 0 after 13511 usecs
> >>>> [   50.242120] snd_hda_codec_realtek hdaudioC0D0: PM: calling hda_codec_pm_resume+0x0/0x19 [snd_hda_codec] @ 4518, parent: 0000:00:0e.0
> >>>> [   50.247406] i8042: [49434] a8 -> i8042 (command)
> >>>> [   50.247468] ideapad_acpi VPC2004:00: PM: acpi_subsys_resume+0x0/0x5d returned 0 after 6220 usecs
> >>> ...
> >>>> [   50.247883] i8042 kbd 00:01: PM: calling pnp_bus_resume+0x0/0x9d @ 4492, parent: pnp0
> >>>> [   50.247894] i8042 kbd 00:01: PM: pnp_bus_resume+0x0/0x9d returned 0 after 0 usecs
> >>>> [   50.247906] i8042 aux 00:02: PM: calling pnp_bus_resume+0x0/0x9d @ 4492, parent: pnp0
> >>>> [   50.247916] i8042 aux 00:02: PM: pnp_bus_resume+0x0/0x9d returned 0 after 0 usecs
> >>> ...
> >>>> [   50.248301] i8042 i8042: PM: calling platform_pm_resume+0x0/0x41 @ 4492, parent: platform
> >>>> [   50.248377] i8042: [49434] 55 <- i8042 (flush, kbd)
> >>>> [   50.248407] i8042: [49435] aa -> i8042 (command)
> >>>> [   50.248601] i8042: [49435] 00 <- i8042 (return)
> >>>> [   50.248604] i8042: [49435] i8042 controller selftest: 0x0 != 0x55
> >>>
> >>> So here I see the ideapad-laptop driver trying to access i8042 before it
> >>> even starts resuming. I wonder, does it help if you disable
> >>> (temporarily) the ideapad driver?
> > 
> > OK, so I tried to cook up a patch that would allow ideapad-laptop driver
> > to establish device link with i8042 so that the resume will be processed
> > after i8042 resumes, but the longer I think about it, the more I think
> > that ideapad driver should not be messing with the touchpad state
> > directly. The disable event may come up in a middle of the touchpad
> > resume transition, or when we decide to change touchpad mode for one
> > reason or another. It also does not respect inhibit/uninhibit controls
> > for input devices. I think that the proper way for ideapad driver to
> > handle this is to only send KEY_TOUCHPAD_OFF/KEY_TOUCHPAD_ON to
> > userspace and let userspace deal with toggling touchpad input (via
> > inhibit or by other means).
> > 
> > CC-ing ideapad maintainers for their thoughts.
> 
> Sorry for the very slow reply.
> 
> The interesting thing is that sometime ago I already removed the i8042_command()
> command being done on most models now the ideapad driver already only
> sends KEY_TOUCHPAD_OFF/KEY_TOUCHPAD_ON except on the ideapad Z570 for
> which the i8042_command() call was initially added.
> 
> I agree that this should probably just be removed.
> 
> Jonathan, I presume that you are seeing this on an Ideapad Z570 ?
> (since that is the only model where this is still done by default).
> 
> Since the i8042_command() call has already been disabled on all other
> ideapad models I agree that it would be best to just remove it entirely
> relying on userspace filtering out touchpad events after receiving
> a KEY_TOUCHPAD_OFF.
> 
> I have submitted a patch to do just that:
> 
> https://lore.kernel.org/platform-driver-x86/20240805141608.170844-1-hdegoede@redhat.com/
> 
> Jonathan can you give this patch a try (with a kernel with
> the ideapad-laptop module re-enabled) and then confirm that this
> fixes things ?

IIRC Jonathan observed the touchpad being stuck on resume even after
disabling ideapad-laptop module. So we ended up with a69ce592cbe0
("Input: elantech - fix touchpad state on resume for Lenovo N24") that
sends disable and then enable command to the mouse/touchpad on resume
which makes touchpad work after resume.

Thanks.

-- 
Dmitry

  reply	other threads:[~2024-08-05 16:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02 12:52 [PATCH] Input: psmouse - add resync_on_resume dmi check Jonathan Denose
2024-02-06 22:04 ` Dmitry Torokhov
2024-02-07 16:39   ` Jonathan Denose
2024-02-09 19:01     ` Dmitry Torokhov
2024-02-12 20:57       ` Jonathan Denose
2024-02-29 18:23         ` Dmitry Torokhov
2024-03-04 17:17           ` Jonathan Denose
2024-03-05 18:47             ` Dmitry Torokhov
2024-03-05 21:48               ` Jonathan Denose
2024-03-05 23:17                 ` Dmitry Torokhov
2024-03-06 16:43                   ` Jonathan Denose
2024-03-07 18:29             ` Dmitry Torokhov
2024-08-05 14:18               ` Hans de Goede
2024-08-05 16:52                 ` Dmitry Torokhov [this message]
2024-08-09 15:35                   ` Jonathan Denose
2024-08-10 12:59                     ` Hans de Goede

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=ZrEDOnxYzbJpC-pH@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=ike.pan@canonical.com \
    --cc=jdenose@chromium.org \
    --cc=jdenose@google.com \
    --cc=jefferymiller@google.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rrangel@chromium.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.