3

On my Lenovo S340 Ideapad with Xubuntu 19.10, I'm having a strange issue with my touchpad, apparently a 'MSFT0001:02 04F3:304B Touchpad' using a Synaptics driver. For no reason that I can find, the touchpad sometimes loses its ability to move the mouse. Despite this:

  • The touchpad can still left-click and right-click.
  • The keyboard works as normal.
  • The mouse works fine on the lock screen (reached via the terminal); issues only return after an unlock.
  • Logging out and back in fixes the problem.
  • No method of disabling and renabling the touchpad that I know of fixes the problem. For example, I've had no success with sudo modprobe psmouse, sudo modprobe -r psmouse, or the otherwise-working Fn+F6.
  • Of what is listed here, I have not tried sudo rmmod psmouse or installing the Synaptics program.
  • Gestures no longer work.
  • I know of no gestures that could cause this.

Where can I investigate this problem further? Is there a less extreme temporary solution than logging out? So far, I have only noticed that I might have ACPI issues.

Update: The past two times that my mouse has failed, it has been through plugging in my USB headphone and turning it on. This doesn't always happen, but it's the only causal link that I've found.

Improve this question
21
  • Sounds like some sort of hardware problem. Or overload (the machine just can't keep up with mouse pointer movement/display).
    – vonbrand
    Commented Feb 23, 2020 at 17:37
  • @vonbrand So you're suggesting killing tasks as a solution?
    – J. Mini
    Commented Feb 23, 2020 at 20:54
  • Sounds like this problem. Try if the solutions there work for you. This is probably a driver problem. What exactly is your touchpad model?
    – harrymc
    Commented Mar 16, 2020 at 21:01
  • @harrymc Thanks, I really should've mentioned the specs. Edited to reflect, with a list of what I have and have not tried form your link.
    – J. Mini
    Commented Mar 16, 2020 at 22:17
  • 1
    Without a better driver the most you can do are workarounds. Maybe try sudo modprobe -r i2c_hid && sudo i2c_hid.
    – harrymc
    Commented Mar 17, 2020 at 10:11

1 Answer 1

Reset to default
2
+50

The following command was effective for the last couple of days for the poster:

sudo modprobe -r i2c_hid && sudo i2c_hid

Waiting for more feedback from the poster as to how long it will continue on working.

Regarding the errors of "duplicate WMI GUID": Your system might really have WMI devices with duplicate GUID ids.

This bug report says:

WMI is not really a part of ACPI specification, but a Microsoft specific standard.

Strangely enough, in that bug report one finds the same Ask Ubuntu link you found as the only claim for it causing suspend problems.

Looking in the Linux sources for wmi.c, I found this comment:

 * Because we historically didn't track the relationship  
 * between GUIDs and ACPI nodes, we don't know whether  
 * we need to suppress GUIDs that are unique on a  
 * given node but duplicated across nodes.

Or another:

 * Some WMI devices, like those for nVidia hooks, have a  
 * duplicate GUID. It's not clear what we should do in this  
 * case yet, so for now, we'll just ignore the duplicate  
 * for device creation.

The code around the last message just ignores such devices. So if all your devices work well before the problem, then I don't think that this is the cause for it.

I have not found any Linux tools for listing WMI GUIDs, only in Windows, so I can't tell how to find which one of your devices is presenting duplicate WMI GUIDs.

Improve this answer
6
  • I just got the problem again. The line you've used throws the error sudo: i2c_hid: command not found. However, using sudo modprobe i2c_hid after that has fixed the problem.
    – J. Mini
    Commented Mar 22, 2020 at 20:20
  • This is then a good workaround but not a solution. It's too consistent to be hardware, so is probably a driver problem. I think the most you can do is keep everything updated. You could also open a bug report on the Xubuntu forum.
    – harrymc
    Commented Mar 22, 2020 at 20:32
  • Update: The past two times that my mouse has failed, it has been through plugging in my USB mic and turning it on. This doesn't always happen, but it's the only causal link that I've found.
    – J. Mini
    Commented Mar 30, 2020 at 23:51
  • It's possible that if you a device with duplicate WMI GUID, this causes one of the duplicates to be lost. I have found a couple of WMI implementations on Linux. You could try Wmic-linux or WMI from Linux and Python.
    – harrymc
    Commented Mar 31, 2020 at 6:19
  • Those looks so old that I wouldn't be surprised if they've already been implemented.
    – J. Mini
    Commented Mar 31, 2020 at 13:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .