linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Limonciello, Mario" <Mario.Limonciello@dell.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: "linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: RE: Dell XPS 13 9310 2-in-1: psmouse serio1: synaptics: Unable to query device: -5
Date: Mon, 7 Dec 2020 21:09:56 +0000	[thread overview]
Message-ID: <DM6PR19MB2636B8F9DB38079722EA0397FACE0@DM6PR19MB2636.namprd19.prod.outlook.com> (raw)
In-Reply-To: <1fe43de4-61e1-82ac-2a17-fe2adfea252a@molgen.mpg.de>



> Dear Mario,
> 
> 
> As always thank you for your quick reply.

😊

> 
> > The messages you're seeing are harmless in this laptop.
> >
> > The laptop input is supported using the hid-multitouch and i2c-hid drivers as
> > noted in your messages.
> >
> > [  393.280115] input: DLL09FF:01 06CB:CE39 Touchpad as
> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-
> DLL09FF:01/0018:06CB:CE39.0002/input/input21
> > [  393.280221] hid-multitouch 0018:06CB:CE39.0002: input,hidraw1: I2C HID
> v1.00 Mouse [DLL09FF:01 06CB:CE39] on i2c-DLL09FF:01
> 
> Where is
> 
>      input: PS/2 Synaptics TouchPad as
> /devices/platform/i8042/serio1/input/input2
> 
> coming from then, and what touchpad is that supposed to be?
> 
> If it’s harmless, should the log level be decreased from error to debug?
> 

There are two common scenarios that happen on Dell's laptops.
1) Touchpads are connected to 2 buses.  Such as PS2 and i2c.
2) Touchpads are connected only to 1 bus, but the EC can emulate
a PS/2 touchpad in the PS/2 bus until OS drivers have started up.
This allows using it in BIOS setup for example without an UEFI DXE
driver for I2C.  It's not generally safe for using it this way in
a general purpose operating system.

I don't have the schematics for the model you referred to confirm it,
but I suspect it's likely the second case.  In the first case you should
see some sort of message along the lines that the touchpad supports
another bus, you should make sure you have those drivers enabled.

The key however is that the PS/2 driver and i2c-hid drivers don't have
any handshake here whatsoever about what happened.  This has come
up several times over the years, but because there is "no negative
impact" to a ghost touchpad device there has been no effort by
anyone to fix it.  You can compile your kernel without psmouse and it
should then not be present.

In systems with the first scenario pretty much when the I2C driver
starts up, the PS/2 mode is turned off and you won't get traffic on
the bus. Because of kernel probing order you would end up with psmouse
mentioning it's supported by another bus probably, and then later in
startup the i2c one starts up.  The I2C driver can't just notify psmouse
it's supporting something because it can't prove the device it supports
now is the same one that was supported by psmouse.

In the second scenario you're talking about a virtual device from the EC
and a real device on the I2C bus.  So the notification flow is even more
confusing.

Here's my two low effort ideas:
1) Adjust this so when kernel is compiled with the support for both can we
make psmouse wait to initialize until after i2c-hid and hid-multitouch
have finished?  This is probably a question for Benjamin if that would
actually work and it's as low effort as I think it would be.

2) Downgrade all psmouse messaging to debug. Realistically modern
machines are no longer using psmouse in the first place. The messaging
benefits no one except those that have a problem with older hardware,
which can then be told to boot with dyndebug turned on for psmouse.


      reply	other threads:[~2020-12-07 21:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <a075a4f7-21f6-54cf-8d97-af7f55ff4b91@molgen.mpg.de>
2020-12-07 17:40 ` Limonciello, Mario
2020-12-07 20:52   ` Paul Menzel
2020-12-07 21:09     ` Limonciello, Mario [this message]

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=DM6PR19MB2636B8F9DB38079722EA0397FACE0@DM6PR19MB2636.namprd19.prod.outlook.com \
    --to=mario.limonciello@dell.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --subject='RE: Dell XPS 13 9310 2-in-1: psmouse serio1: synaptics: Unable to query device: -5' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).