Dear Dmitry, dear Mario,
Am 21.02.18 um 10:22 schrieb Paul Menzel:
Am 15.02.2018 um 16:22 schrieb Mario.Limonciello@xxxxxxxx:
-----Original Message-----
From: Paul Menzel [mailto:pmenzel+linux-input@xxxxxxxxxxxxx]
Sent: Thursday, February 15, 2018 2:26 AM
On 02/14/18 18:11, Mario.Limonciello@xxxxxxxx wrote:
-----Original Message-----
From: Paul Menzel [mailto:pmenzel+linux-input@xxxxxxxxxxxxx]
Sent: Wednesday, February 14, 2018 10:41 AM
On 01/30/18 19:07, Dmitry Torokhov wrote:
On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
I do not know, when it started, but with Linux 4.14-rc8 and 4.15,
benchmarking suspend and resume time with `sleepgraph.py` [1][2], there is a
regression, that i8042 AUX port [serio1] suspend takes a second on Dell XPS
13 9360 and TUXEDO Book 1406.
It would be really helpful to know when the regression started.
So the reason it takes longer is because the touchpad does not
want to talk to us for some reason and we wait until commands time out:
[ 94.591636] calling serio1+ @ 2299, parent: i8042
[ 94.794292] psmouse serio1: Failed to disable mouse on isa0060/serio1
[ 95.593303] call serio1+ returned 0 after 974280 usecs
but it is not clear why it happens, I do not think we changed anything
in that path for a while, so it might be some other change affecting
things indirectly. I'm afraid you'll have to narrow the scope, and
ideally bisect.
Please keep in mind the XPS 9360 has a touchpad that can operate in I2C
or PS2 modes. It's connected to both buses and with the right initialization
sequence will come up in I2C mode.
Assuming Paul M. has compiled and used hid-multitouch and i2c-hid the
touchpad should be operating in I2C mode.
When this happens I expect that the touchpad shouldn't be responding
to PS2 commands.
As a debugging tactic, you may consider to unload psmouse before
suspend and still see the touchpad operational.
Thank you! Unloading *psmouse* with `sudo modprobe -r psmouse` indeed
worked on the Dell XPS 13 9360, that means, the cursor is still
functioning.
Thank you for your replies. First of all, it looks like *only* the Dell
system is effected as I was unable to reproduce it on the TUXEDO Book
1406. I have to verify that by finding old log files.
Does this other laptop you are drawing a comparison to also have a
touchpad that can operate in multiple modes?
To make an accurate comparison you should determine what mode it's in.
Yeah, removing the module *psmouse*, the cursor didn’t work there
anymore. I was really sure, that I saw that problem once on the TUXEDO
device too, but must have been mistaken, that’s why I corrected it.
Sorry for the misunderstanding.
So, why does *psmouse* get loaded on the Dell XPS 13 9360 since at least
Linux 4.13? Or where the modules added causing the touchpad to operate
in I2C mode, which causes PS2 to stop to work?
It was like that before this laptop even launched to the market.
It's been like that since way before 4.13. I want to say maybe
3.13ish is when
I2C mode would come up instead.
Indeed, analyzing the behavior on the current 8th generation Dell XPS 13
93*7*0 with the shipped Ubuntu with Linux 4.4.0-112-generic, the same
delay is visible.
The order of events goes something like this:
1) Touchpad is initially in PS2 mode
2) psmouse loads
3) It reports that it may be supportable by a different bus
4) The sequence to switch to I2C mode happens
5) i2c-hid and hid-multitouch get loaded
6) psmouse is no longer functional
Dmitry is there a way that we can connect the two events? When
i2c-hid finds
the touchpad notify psmouse to unload or at least stop trying to
access it to prevent
the problem Paul is talking about with suspend?
That would be great. Please tell me, if there is a bug tracker, where
this issue should reported to to track it.
The issue is still present with Linux 5.8-rc4. Does Mario’s plan sound
feasible?
Kind regards,
Paul
