|Summary:||After resuming, I need to reload the module hid_multitouch to recover touchscreen usage|
|Product:||Drivers||Reporter:||Julien Wajsberg (felash)|
|Component:||I2C||Assignee:||Drivers/I2C virtual user (drivers-i2c)|
|Severity:||normal||CC:||bastienphilbert, its.muhammadosama, mario.diraimondo|
lsusb -v output
Description Julien Wajsberg 2015-07-05 12:22:02 UTC
After suspending/resuming, my touchscreen doesn't work anymore. I realized that merely unloading and reloading the module hid_multitouch make it work again. I now have a workaround to do that at resume, but likely this could be done in the kernel instead.
Comment 1 Julien Wajsberg 2015-07-05 12:23:34 UTC
Created attachment 181881 [details] lsusb -v output
Comment 2 Mario 2016-04-10 18:56:28 UTC
The same with a Dell XPS 13 (9350) with QHD touchscreen.
Comment 3 [account disabled by administrator] 2016-05-23 01:06:46 UTC
Can you check and see if your kernel has this commit id, d3e69b9a04f8e42de1b4132218567b027d368bb5 and if not try a newer kernel that does as this commit may fix your problem.
Comment 4 Mario 2016-06-21 17:41:57 UTC
To reply to comment #3: the problem is still present on XPS 13 using kernel 4.6.2 (including patch d3e69b9a04f8e42de1b4132218567b027d368bb5). The problem happens on the touchscreen upon standby-resume on battery.
Comment 5 [account disabled by administrator] 2016-06-21 20:00:18 UTC
Did this every work before as if it did I would like to bisect it as I can't see anything not working with the resume functions in that driver. Either there was a change that broke your touchscreen or your touchscreen id is not in the kernel source for being able to resume.
Comment 6 Mario 2016-06-22 10:14:41 UTC
It never worked for me but I got my laptop since few months. What should be the id of my touchscreen? The output of lsusb is: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 005: ID 0c45:670c Microdia Bus 001 Device 004: ID 04f3:20d0 Elan Microelectronics Corp. Bus 001 Device 010: ID 8087:0a2b Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Comment 7 [account disabled by administrator] 2016-06-22 13:21:26 UTC
First thing is do you actually have CONFIG_PM set in your config. If not try the below patch in order for me to get a actual function trace.
Comment 8 [account disabled by administrator] 2016-06-22 13:25:47 UTC
Created attachment 221011 [details] Test Patch
Comment 9 Mario 2016-06-22 13:29:52 UTC
I got the CONFIG_PM option activated in my kernel config. Your last sentence is not clear for me: do I need to patch my kernel with your patch anyway?
Comment 10 [account disabled by administrator] 2016-06-22 19:47:14 UTC
Yes, I can't use what's wrong as the resume function is only one line a wrapper of sorts around another function. I would like to see the trace up to that function if it indeed happens or maybe it doesn't, the function trace will tell.
Comment 11 Mario 2016-06-23 16:48:31 UTC
I did a rebuild of a 4.6.2 kernel with your dump_stack() function. I can't note any extra output in the dmesg output upon suspend/resume. Is it normal?
Comment 12 [account disabled by administrator] 2016-06-23 17:26:21 UTC
Actually when building your kernel, can you check you have under the kernel debugging menu the item verbose kernel debugging messages as you may not have it enabled making the function dump_stack useless if not enabled. If they not enabled try adding them and you may see a stack trace when calling the resume function for your touchscreen driver.
Comment 13 Mario 2016-11-08 15:07:08 UTC
I can confirm that this problem is fixed for me (Dell XPS 13 9350): I'm using kernel 4.8.6.
Comment 14 Julien Wajsberg 2016-11-09 14:20:45 UTC
I still have the issue with Debian's kernel 4.7.0-1.
Comment 15 Mario 2016-11-09 14:47:07 UTC
Indeed 4.8.6>4.7.0... Using Arch Linux.
Comment 16 Julien Wajsberg 2016-11-09 20:29:47 UTC
yes, I know your kernel version is higher. I just wanted to bring another point of information.