Bug 81141 - Synaptics RMI4 touchpad - XPS 13 9333: data are processed even with no touches
Summary: Synaptics RMI4 touchpad - XPS 13 9333: data are processed even with no touches
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-26 16:37 UTC by Gabriele Mazzotta
Modified: 2020-07-03 09:41 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.16-rc6
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Single tap trace log (123.77 KB, text/x-log)
2014-07-26 16:37 UTC, Gabriele Mazzotta
Details
No touches trace log (117.69 KB, text/x-log)
2014-07-26 16:41 UTC, Gabriele Mazzotta
Details
crash unloading hid-rmi (28.14 KB, text/plain)
2014-08-27 12:30 UTC, Gabriele Mazzotta
Details
crash unloading i2c-designware-platform (40.89 KB, text/plain)
2014-08-27 12:31 UTC, Gabriele Mazzotta
Details

Description Gabriele Mazzotta 2014-07-26 16:37:25 UTC
Created attachment 144271 [details]
Single tap trace log

The new hid rmi driver seems to cause a high power consumption on the Dell XPS13 9333.

powertop reports an high number of events per second. Here the two usually on the top of the list:

                Usage       Events/s    Category       Description
             18,6 ms/s     3322,4       Interrupt      [7] INT33C3:00
              4,6 ms/s     334,0        Process        [irq/39-DLL060A:]
                ...

Interestingly, right after a reboot powertop reports the two above only when the touchpad is used, but after some time, they are constantly there, even when the touchpad is not used.

After some tests, I noticed that "[7] INT33C3:00" and "irq/39-DLL060A:" are constantly on the top of the list with an high number of events once ABS_MT_TOUCH_MAJOR reaches 12.


Attached the output of the following commands when a simple tap on the touchpad is done:
   cd /sys/kernel/debug/tracing
   echo function > current_tracer
   echo :mod:hid_rmi > set_ftrace_filter
   cat trace_pipe
Comment 1 Gabriele Mazzotta 2014-07-26 16:41:24 UTC
Created attachment 144281 [details]
No touches trace log

Here the output of the same commands above, taken when powertop reports an high number of events.

The touchpad was never touched.

The output of trace_pipe was blocked after few seconds.
Comment 2 Gabriele Mazzotta 2014-08-07 23:09:56 UTC
Could the faulty component be I2C?

If I try to unload i2c-hid while the events are generated continuously, my laptop freezes.
If I unload hid-rmi and then i2c-hid, the kernel crashses. I will try to get some logs.

However, if I disable the touchpad with xinput, I can unload i2c-hid and reload it. Once reloaded, the events are generated only on touch until I trigger the bug again covering a wide area of the touchpad with one of my fingers.
Comment 3 Gabriele Mazzotta 2014-08-27 12:30:32 UTC
Created attachment 148471 [details]
crash unloading hid-rmi

I tried to use evdev with 3.15 (for some reason I can't make the touchpad work
with it when I used 3.16, why?) and although the number of events is still
pretty high, there's no way for me to trigger the bug.

When I press on a wide area (using evdev), the cursor doesn't move. Running
hexdump on /dev/hidraw* reveals that my hand is indeed detected, but a flow of
zeros is shown and it stops as soon as I remove my hand from the touchpad.

If I do the same with hid-rmi, it seems that the same data is repeated over and
over when I'm not touching the touchpad and it never stops.

If I try to unload hid-rmi or i2-designware-platform after the bug, the kernel
crashes.
Comment 4 Gabriele Mazzotta 2014-08-27 12:31:17 UTC
Created attachment 148481 [details]
crash unloading i2c-designware-platform
Comment 5 Benjamin Tissoires 2014-12-11 18:36:53 UTC
FWIW, bugs related to the input subsystem are better handled on the linux-input LKML (like you did on the other i2c-hid report).

Can you give a shot at this patch that was posted back in May:
https://patchwork.kernel.org/patch/4133771/

I refused it upstream but I think this might be related to your problem if it appears after a long time.
Comment 6 Gabriele Mazzotta 2015-02-25 11:53:12 UTC
Sorry for not updating this report.

The patch here suggested does not work.

The problem had been identified and the following should fix it: https://patchwork.kernel.org/patch/5876831/

Also the crash that happens unload the modules had been fixed:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b44c53aeb791757072be4a267255cedfff594fd

Note You need to log in before you can comment on or make changes to this bug.