Bug 100951
| 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) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | bastienphilbert, its.muhammadosama, mario.diraimondo |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 4.1 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
lsusb -v output
Test Patch |
||
|
Description
Julien Wajsberg
2015-07-05 12:22:02 UTC
Created attachment 181881 [details]
lsusb -v output
The same with a Dell XPS 13 (9350) with QHD touchscreen. 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. 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. 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. 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 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. Created attachment 221011 [details]
Test Patch
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? 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. 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? 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. I can confirm that this problem is fixed for me (Dell XPS 13 9350): I'm using kernel 4.8.6. I still have the issue with Debian's kernel 4.7.0-1. Indeed 4.8.6>4.7.0... Using Arch Linux. yes, I know your kernel version is higher. I just wanted to bring another point of information. |