2

I've got a HP Envy x360 laptop upon an initial boot the touch screen works. but after suspending the touchscreen no longer functions. Doing some research I believe the module responsible for this is hid_multitouch. Reloading the module via rmmod hid_multitouch && modprobe hid_multitouch (as superuser of course) doesn't seem to affect the problem.

lspci: http://pastebin.com/AGkiSp5L lsusb: http://pastebin.com/RNnahs11

I can't seem to even find the device via lsusb or lspci what other ways would I be able to identify the device? Is there a secondary module that would need to be reloaded simultaneously?

Sion
  • 375
  • 3
  • 14

1 Answers1

1

If running sudo rmmod hid_multitouch after a reboot disables your touchscreen try this: 

su -c "echo "SUSPEND_MODULES="hid_multitouch"" >> /etc/pm/config.d/modules"

This will unload that module prior to suspend, hopefully fixing your problem.

If that's not the case, run xinput --list while the touchscreen is working and when the touchscreen is not working, compare the output, if something is missing when you resume from a suspend, you'll have to re.

Example output:

⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ ITE Tech. Inc. ITE Device(8595)           id=11   [slave  pointer  (2)]
⎜   ↳ ITE Tech. Inc. ITE Device(8595) Touchpad  id=12   [slave  pointer  (2)]
⎜   ↳ SYNA7508:00 06CB:77B2                     id=14   [slave  pointer  (2)]

My touchscreen device is SYNA7508:00 06CB:77B2 id=14

Try running xinput set-prop DEVICE_ID "Device Enabled" 0 && xinput set-prop DEVICE_ID "Device Enabled" 1 replacing the ID with your device ID post suspend.

If that command fixes it, try replacing it with the rmmod&&modprobe found here (dont forget to chmod u+x the file making it executable): https://bugs.launchpad.net/ubuntu/+source/xinput/+bug/1275416/comments/28 However, if the device does not show up after suspend, you'll have to reattach it, here's another example: https://bugs.launchpad.net/ubuntu/+source/xinput/+bug/1275416/comments/19

post irony
  • 51
  • 4
  • (Apparently I never noticed I got a response to this question. whoops) The suspend trick didn't work, but I ran a diff on the xinput files and got this back http://pastebin.com/UCN2xv5j Left being post suspend and right post boot. The only thing that looks different is the order of the touchpad and touchscreen. I even tried the disable/ reenable trick on both the touchscreen and on my "pen" device. – Sion Sep 01 '16 at 01:28
  • I feel your pain, which kernel are you running? I had similar issue on pre 4.0 kernels. Also, sorry I didn't realize you mentioned rmmod hid_multitouch doesn't help in your question :P – post irony Sep 08 '16 at 19:29
  • Looks like I'm running "4.4.8-040408-generic", so that solves the pre 4.0 kernel potential. (If people didn't easily miss things the world would be boring.) – Sion Sep 09 '16 at 01:46
  • Hm, does `rmmod hid_multitouch` alone stop your touchscreen and mouse from functioning? Also could you post your logs related to the touchscreen. I'm no expert but I think: `grep -iER "synaptic|hid_multitouch" /var/log/*` should work if thats the correct module. – post irony Sep 12 '16 at 02:49
  • Yep, looks like rmmod hid_multitouch takes down the touchscreen on a fresh boot, then modprobe hid_multitouch happily brings it back up. (mouse/ touchpad is unaffected by unloading and loading the hid_multitouch module) Output from grep meaty, lots of data I'm not even sure how to start sorting through it, what are you looking for?: http://pastebin.com/7wtLZtfU – Sion Sep 12 '16 at 21:06
  • Ok good. I was hoping to find a pm-util error. Turns out `/etc/pm/suspend.d` may not be used. You might want to try http://askubuntu.com/a/615384/583129 but replacing `ExecStart=/bin/systemctl restart network-manager.service` with `ExecStart=/bin/rmmod hid_multitouch && /bin/modprobe hid_multitouch` – post irony Sep 12 '16 at 23:12
  • Another case may be that pm-utils isn't reading the modules file correctly because of permission issues. This would be fixed with `chmod 777 /etc/pm/config.d/modules` or the correct privileges if you're not lazy, `+rw` I think? – post irony Sep 12 '16 at 23:23
  • Checked the permissions on `/etc/pm/config.d/modules` and that looks as it should, root has RW and everyone else has read access. Creating the suggested systemd script didn't seem to have any effect due to taking down and restarting the module before suspending (from my understanding), created a new one here: http://pastebin.com/DWMaBRWp that should take it down before suspending and bring it back up after resume. Sadly that didn't seem to have any effect either. – Sion Sep 14 '16 at 16:48
  • Damn. I was really hoping that would work. Well I'm running out of ideas. Have you tried to live boot into debian, linux mint, fedora, etc? Or tried making a pm-suspend hook? – post irony Sep 14 '16 at 23:56
  • Damn!. I ran out of ideas long ago. I suppose I could Live boot and see if the modules are different, or the xinput list is different, but that'd be all that I could do. From this point it looks like the module might be getting corrupted upon suspending (or something...). Will have to try the pm-suspend hook, but I think systemd at least on ubuntu ignores what pm-utils says. – Sion Sep 15 '16 at 02:33