Bug 1075885 - Plymouth update leads to errors in X11 <-> Elantech touchpad interaction
Plymouth update leads to errors in X11 <-> Elantech touchpad interaction
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
x86-64 openSUSE Factory
: P5 - None : Major (vote)
: ---
Assigned To: Cliff Zhao
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-13 21:55 UTC by Hadrien Grasland
Modified: 2018-03-26 14:11 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hadrien Grasland 2018-01-13 21:55:04 UTC
After upgrading my laptop from Tumbleweed 20171211 to Tumbleweed 20171223, I noticed it ended up having two cores constantly spinning due to X11 running at > 100% CPU and systemd-journald running at 100% CPU. A closer looks at journalctl reveals that this is caused by X11 spamming the logs at an extremely high rate with the following message, indicating some kind of problem in the interaction between X11 and the touchpad driver (the touchpad otherwise works normally):

        "(EE) ETPS/2 Elantech Touchpad: Read error 9"

Obviously, this is not good. I don't want my laptop to make fan noise, run hot, and eat through its battery like crazy. Moreover, these errors in the logs, whatever they mean, do not sound very reassuring either.

Through some long investigation involving Jimmy Berry's awesome Tumbleweed snapshots (to narrow down the problem to the 20171220 -> 20171222 time period), and a lot of snapper-backed trial and error, all of which made me appreciate how Tumbleweed is the best Linux rolling release ever built, I managed to narrow down the precise trigger of this problem...

...which, surprisingly enough, turned out to be the upgrade from plymouth 0.9.2+git20170424.6fd5c6b-2.1 to 0.9.3+git20171130.fa66a5b-1.1.

If I do an otherwise full system upgrade with all plymouth-related packages locked, the problem does not manifest. And if I do upgrade plymouth, but disable it via the kernel command line option "plymouth.enable=0", my X server will stay quiet as well. The evidence is pretty incriminating: plymouth is definitely involved somehow in this issue.

Now, it is beyond my technical ability to explain how a relatively small upgrade (just checked the git log) to a piece of software which displays fancy splash screens at boot time can possibly bork the interaction between X11 and a touchpad driver. But if you have any clue, or any suggestion of something I could do to diagnose this problem further, please tell me! :)
Comment 1 Stefan Dirsch 2018-01-14 05:49:58 UTC
Sorry, no clue, no. But it seems you're still using evdev or synaptics driver. Maybe things go away with libinput driver, which is our default meanwhile on TW. Just uninstall xf86-input-evdev and/or xf86-input-synaptics driver packages.
Comment 2 Hadrien Grasland 2018-01-14 09:36:30 UTC
(In reply to Stefan Dirsch from comment #1)
> Sorry, no clue, no. But it seems you're still using evdev or synaptics
> driver. Maybe things go away with libinput driver, which is our default
> meanwhile on TW. Just uninstall xf86-input-evdev and/or xf86-input-synaptics
> driver packages.

I can confirm that the issue goes away if I force use of libinput by removing the legacy input drivers.
Comment 3 Cliff Zhao 2018-01-15 09:06:31 UTC
I think this problem only happens in the special hardware, and I have tried to test 3 different hardware environment with the latest Tumbleweed, and this problem didn't appear.
According to your description, what I understand that Plymouth is the necessary condition for this error, but the legacy input drivers is also the same, Maybe it a problem by race.
I will keep following this issue. If there's someone else who also hit this bug and found the way to reproduce on a general hardware platform will help a lot to shrink the cycle of problem-solving.
Thanks!
Comment 4 Cliff Zhao 2018-01-19 04:22:38 UTC
(In reply to Hadrien Grasland from comment #2)
> (In reply to Stefan Dirsch from comment #1)
> > Sorry, no clue, no. But it seems you're still using evdev or synaptics
> > driver. Maybe things go away with libinput driver, which is our default
> > meanwhile on TW. Just uninstall xf86-input-evdev and/or xf86-input-synaptics
> > driver packages.
> 
> I can confirm that the issue goes away if I force use of libinput by
> removing the legacy input drivers.

Hi Hadrien:
I want to re-test this step, So how do you "removing the legacy input drivers", could you give me some detailed information you used with?
Comment 5 Hadrien Grasland 2018-01-19 07:46:36 UTC
(In reply to Zhao Qiang 赵强 from comment #4)
> (In reply to Hadrien Grasland from comment #2)
> > (In reply to Stefan Dirsch from comment #1)
> > > Sorry, no clue, no. But it seems you're still using evdev or synaptics
> > > driver. Maybe things go away with libinput driver, which is our default
> > > meanwhile on TW. Just uninstall xf86-input-evdev and/or xf86-input-synaptics
> > > driver packages.
> > 
> > I can confirm that the issue goes away if I force use of libinput by
> > removing the legacy input drivers.
> 
> Hi Hadrien:
> I want to re-test this step, So how do you "removing the legacy input
> drivers", could you give me some detailed information you used with?

Hi Zhao,

Since I do not need the evdev and synaptics X11 input drivers, as my hardware is well supported by their libinput successor, I just followed Stefan's advice and did a "zypper rm xf86-input-evdev xf86-input-synaptics". This forced X11 to switch to libinput, where given the choice it favored synaptics.

(By the way, Stefan, if libinput is the newer and preferred alternative, would there be a way to make sure that X11 uses it by default, and only switches to synaptics if that fails? Or is some hardware still too badly handled by libinput for this change of priority order to be practical?)

If this can be of any help in narrowing down the hardware configuration that reproduces the bug, my hardware is a Gigabyte P35X v3 laptop (the Haswell-based generation). Please do not hesitate to ask me for more hardware and system specifics that would be useful to you, I don't know enough about the Linux input and graphics stack to tell what exactly could help.
Comment 6 Stefan Dirsch 2018-01-19 10:55:21 UTC
(In reply to Hadrien Grasland from comment #5)
> (By the way, Stefan, if libinput is the newer and preferred alternative,
> would there be a way to make sure that X11 uses it by default, and only
> switches to synaptics if that fails? Or is some hardware still too badly
> handled by libinput for this change of priority order to be practical?)

libinput is our default, since we no longer install -evdev and -synaptics driver packages by default. Of course if you update your system and have it installed before, we don't remove the packages during upgrade. I guess that's your situation.

synaptics driver has a lot of features, which libinput driver doesn't have and likely will never have, so I didn't want to drop it completely for users relying on it.

Current versions of desktops like GNOME no longer support configuration of input drivers other than -libinput. In addtition -synaptics and -evdev drivers are no longer in development.