linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, Dell.Client.Kernel@dell.com,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>
Subject: Re: Dell XPS 13 9310 2-in-1: psmouse serio1: synaptics: Unable to query device: -5
Date: Tue, 16 Aug 2022 07:00:55 +0200	[thread overview]
Message-ID: <f9181b2b-c593-f845-5663-6154d4041360@molgen.mpg.de> (raw)
In-Reply-To: <DM6PR19MB2636B8F9DB38079722EA0397FACE0@DM6PR19MB2636.namprd19.prod.outlook.com>

[Resend without attachment as linux-input@ bounced it due to exceeding 
the size limit.]

[Cc: -Mario as he works at AMD now.; +Dell.Client.Kernel@dell.com, but I 
never received a response from them.; +Benjamin]

Dear Dmitry,


Am 07.12.20 um 22:09 schrieb Limonciello, Mario:

>>> 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.

Today I have seen this also on a Dell XPS 13 9370 (system firmware 
1.15.0, 06/07/2021) with Linux 5.18.16. The message is logged on the 
screen even with `quiet` passed – as it’s log level error, and the user 
sees it when entering the LUKS passphrase.

Which one of Mario’s suggestions do the developers prefer?


Kind regards,

Paul

      reply	other threads:[~2022-08-16  7:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <a075a4f7-21f6-54cf-8d97-af7f55ff4b91@molgen.mpg.de>
2020-12-07 17:40 ` Dell XPS 13 9310 2-in-1: psmouse serio1: synaptics: Unable to query device: -5 Limonciello, Mario
2020-12-07 20:52   ` Paul Menzel
2020-12-07 21:09     ` Limonciello, Mario
2022-08-16  5:00       ` Paul Menzel [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=f9181b2b-c593-f845-5663-6154d4041360@molgen.mpg.de \
    --to=pmenzel@molgen.mpg.de \
    --cc=Dell.Client.Kernel@dell.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.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 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).