Created attachment 292145 [details] dmesg on Linux 5.8.1 with reverted commits Hello! Elantech touchpad on Acer Aspire 7560G started to behave erratically since Linux 5.3.0. After comparison of evtest output on Linux 5.2 and 5.3 I found that Y-axis coordinates is reported correctly on Linux 5.2, however since Linux 5.3 upper half of touchpad report negative coordinates, while lower half report positive coordinates. I wasn't able to find any issues with X-axis on Linux 5.3. Issue was still reproducible on Linux 5.8, so I tried to perform which lead me to commit 37548659bb223563797584c752274b81326d3f3c I tried to revert following commits on Linux 5.8.1 to verify if it helps: 66f4c7765ad336c49243a4fd78de502fba5e9188 3abcc5329aecda19be1b9f91af51a257d23ccfe3 fd1cf11f7130977d44fc19bf7ced63a4b6f1fc30 88463497dd1f64eef9f21c6bbd19acabd0d8f88e 37548659bb223563797584c752274b81326d3f3c This indeed help - issue is not reproducible when these commits is reverted. Touchpad is detected like this: [ 3.497730] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x450f01) [ 3.527176] psmouse serio1: elantech: Synaptics capabilities query result 0x68, 0x15, 0x0a. [ 3.556686] psmouse serio1: elantech: Elan sample query result 04, 0b, 00
Thanks for the bug report. Can you attach logs from `sudo libinput record` with both your working and non-working kernels? Right now it's kind of hard to know why this commit messes up with your touchpad.
Created attachment 292721 [details] libinput record from Linux 5.8.0 upstream (non-working)
Created attachment 292723 [details] libinput record from Linux 5.8.1 with reverted commits (working)
Thanks for the quick logs. So it seems both X and Y have a wrong reported max in the non working case: the values of X are also divided by 2 and the computed dimension is wrong. I'll need some other logs (with working and non working kernel). Can you provide logs from ps2-record from https://github.com/Lyude/ps2emu? This will give me the raw traces of your touchpad, and I'll be able to reinject them locally to see if I can do something. I just hope that we are not hitting a bug where the firmware requires a particular sequence in the requests, in which cases, that will be not very nice to solve. Also, there is a tool that allows to see if the touchpad ranges are correct: https://wayland.freedesktop.org/libinput/doc/1.10.2//absolute_coordinate_ranges.html The tool also gives you a udev rule you can set to fix the problem from userspace. But I'd rather fix the regression in the first place :)
Created attachment 292743 [details] ps2emu build log > Can you provide logs from ps2-record from https://github.com/Lyude/ps2emu? Trying to build it, but getting a bunch of build errors. See attached log. Yes libglib2.0-dev is installed. Host is Ubuntu 20.04. > But I'd rather fix the regression in the first place :) Understood. Just in case, this tool produce following output: ~$ sudo touchpad-edge-detector 45x85 /dev/input/event7 Touchpad ETPS/2 Elantech Touchpad on /dev/input/event7 Move one finger around the touchpad to detect the actual edges Kernel says: x [0..1254], y [0..528] Touchpad sends: x [0..2480], y [-496..528] |^C/ Touchpad size as listed by the kernel: 40x17mm User-specified touchpad size: 45x85mm Calculated ranges: 2480/1024 Suggested udev rule: # <Laptop model description goes here> evdev:name:ETPS/2 Elantech Touchpad:dmi:bvnAcer:bvrV2.04:bd02/13/2012:br4.240:svnAcer:pnPXXX5:pvrV2.04:rvnAcer:rnTorpedo:rvrBaseBoardVersion:cvnChassisManufacturer:ct10:cvrV2.04:* EVDEV_ABS_00=0:2480:55 EVDEV_ABS_01=-496:528:12 EVDEV_ABS_35=0:2480:55 EVDEV_ABS_36=-496:528:12
right, there is something wrong here. The following patch helps compiling the tool: diff --git a/src/Makefile.am b/src/Makefile.am index c90c0c7..7ccb103 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1,5 +1,5 @@ AM_CFLAGS = -std=gnu11 $(GLIB_CFLAGS) -Wall -I$(top_srcdir)/ps2emu-kmod -AM_LDFLAGS = $(GLIB_LIBS) $(GLIB_LDFLAGS) +LIBS = $(GLIB_LIBS) $(GLIB_LDFLAGS) sbin_PROGRAMS = ps2emu-record \ ps2emu-replay --- I'll submit a PR to include this
Created attachment 292769 [details] ps2emu record from Linux 5.8.0 upstream (non-working)
Created attachment 292771 [details] ps2emu record from Linux 5.8.1 with reverted commits (working) > right, there is something wrong here. The following patch helps compiling the > tool Thanks! This works out.
Created attachment 292775 [details] 0001-input-elantech-force-query-info-after-absolute-mode-.patch Thanks for the logs. So there is only one difference between working and non-working: In the working case, the `ETP_FW_ID_QUERY` command is issued *after* the call to `elantech_set_absolute_mode()`, while on the non-working case, the command is sent before. I'll have to double check on the P52, but I know that inverting those 2 commands breaks the SMBus capabilities of the Synaptics touchpad. Let's hope that this does not affect Elantech in the same way. If you want to play around, instead of reverting those patches, you can try to see if using the attached patch helps. I would be curious to see the difference in the ps2record logs too. (note the patch is compiled only, not tested on Elantech HW)
Created attachment 292781 [details] ps2emu record from Linux 5.8.12 with patch > you can try to see if using the attached patch helps. I would be curious to > see the difference in the ps2record logs too. (note the patch is compiled > only, not tested on Elantech HW) I tested this patch and unfortunately it didn't help. ps2emu log is attached.
Created attachment 292829 [details] v2-0001-input-elantech-force-query-info-after-absolute-mode-.patch Can you try the updated patch? This time I managed to test it on the P52, so it's safe on a HW v4 as well.
Created attachment 292845 [details] ps2emu record from Linux 5.8.13 with v2 patch > Can you try the updated patch? Thank you! With v2 patch it's seems like there is no issues. I attached new ps2emu log if you would like to verify that.
Created attachment 292849 [details] v3-0001-input-elantech-force-query-XY-range-after-absolut.patch Thanks a lot for the test and the logs. So it seems only the last command (QUERY_FW_ID, which contains min/max) is changing after the call to set_absolute_mode(). I changed the patch to only issue this call, to speed up the initialization of the touchpad. Would you mind giving a last test? If the results are good, I'll send the patch to the list with your Tested-by if you don't mind.
Created attachment 292881 [details] ps2emu record from Linux 5.8.13 with v3 patch > Would you mind giving a last test? If the results are good, I'll send the > patch to the list with your Tested-by if you don't mind. Sure. New patch works too. ps2emu log is attached, just in case.
Thanks for the tests! patch submitted (sorry for the delay): https://patchwork.kernel.org/patch/11835053/
Somehow Comment 15 e-mail slipped into spam. Sorry for didn't noticing it earlier. Once again, thank you for fixing this! :)