Created attachment 124095 [details] changing window and trying to scroll one line of text Dear libinput devs, since Debian testing uses libinput by default the touchpad on my Lenovo ThinkPad L430 is very hard to use. It is super sensitive. I had another person use the touchpad for some minutes and it resulted in a pained hand. If you want to scroll one line of text e.g. in your web browser you have to roll your finger tips with a resolution of 1/2 or 1/3 of a millimeter. And you have to keep them there, or you scroll a bit back when lifting the fingers. And when scrolling in some applications (e.g. gnome terminal 3.20) holding the touchpad will give you a jittery scrolling (10 - 20 pix up and down). I heard the approach of libinput is to have a great default configuration upstream instead of configurability. I like that. So here i am. Wanting to make sure the touchpad is usable for 90% of the people. Although your bug reporting guide only talks about bugs in the traditional sense of misbehaviour i completed all the steps and here my results: ---- Version: 1.3.0-2 (Debian Testing/Stretch) ---- # libinput settings: $ xinput list-props 4 Device 'Virtual core XTEST pointer': Device Enabled (138): 1 Coordinate Transformation Matrix (140): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 XTEST Device (257): 1 --- # Laptop: Lenovo ThinkPad L430 cat /sys/class/dmi/id/modalias dmi:bvnLENOVO:bvrG3ETA5WW(2.65):bd10/20/2015:svnLENOVO:pn2464A26:pvrThinkPadL430:rvnLENOVO:rn2464A26:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable: --- Touchpad dimensions: 76mm width, 45mm height Attached is the evemu file. I changed the window and tried to scroll one line only. I hope it helps you to understand how finicky the touchpad is.
Created attachment 124096 [details] evemu of laying two fingers on the touchpad without moving Here the evemu recording of me puting two fingers on the touchpad without moving them on top of gnome-terminal 3.20 which runs the debug events command.
Created attachment 124097 [details] trying to scroll one line (evemu recording) Sorry, attached the debug output before. Here are now the evemu recordings.
Created attachment 124098 [details] just touching the touchpad as before (evemu recording)
And here the correct xinput-list-props command: --- $ xinput list-props 11 [0:37:39] Device 'ETPS/2 Elantech Touchpad': Device Enabled (138): 1 Coordinate Transformation Matrix (140): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (277): 1 libinput Tapping Enabled Default (278): 0 libinput Tapping Drag Enabled (279): 1 libinput Tapping Drag Enabled Default (280): 1 libinput Tapping Drag Lock Enabled (281): 0 libinput Tapping Drag Lock Enabled Default (282): 0 libinput Accel Speed (283): -0.493617 libinput Accel Speed Default (284): 0.000000 libinput Natural Scrolling Enabled (285): 0 libinput Natural Scrolling Enabled Default (286): 0 libinput Send Events Modes Available (261): 1, 1 libinput Send Events Mode Enabled (262): 0, 0 libinput Send Events Mode Enabled Default (263): 0, 0 libinput Left Handed Enabled (287): 0 libinput Left Handed Enabled Default (288): 0 libinput Scroll Methods Available (289): 1, 1, 0 libinput Scroll Method Enabled (290): 1, 0, 0 libinput Scroll Method Enabled Default (291): 1, 0, 0 libinput Disable While Typing Enabled (292): 1 libinput Disable While Typing Enabled Default (293): 1 Device Node (264): "/dev/input/event6" Device Product ID (265): 2, 14 libinput Drag Lock Buttons (294): <no items> libinput Horizonal Scroll Enabled (266): 1
run the touchpad-edge-detector tool please and attach the output here, thanks.
judging by comment 0 and the evemu recordings, the resolutions are out, instead of 31x31 this should be 30x26. That make account for some of the extreme behaviour. add these two lines to your 90-libinput-models-quirks.hwdb, then run sudo udevadm hwdb --update, then sudo udevadm test /sys/class/input/eventXX (with the correct event node number). If the tag shows up in the test output, reboot. libinput:name:*ETPS/2 Elantech Touchpad*:dmi:*svnLENOVO:*pvrThinkPadL430* LIBINPUT_ATTR_RESOLUTION_HINT=30x26
Before applying the changes recommended in comment 6: The touchpad-edge-detector tool is part of the libevdev-tools package on Debian and Ubuntu. sudo touchpad-edge-detector /dev/input/event6 Touchpad ETPS/2 Elantech Touchpad on /dev/input/event6 Move one finger around the touchpad to detect the actual edges Kernel says: x [0..2204], y [0..1160] Touchpad sends: x [23..2176], y [23..1134] \^C Touchpad size as listed by the kernel: 71x37mm Calculate resolution as: x axis: 2204/<width in mm> y axis: 1160/<height in mm> Suggested udev rule: # <Laptop model description goes here> evdev:name:ETPS/2 Elantech Touchpad:dmi:bvnLENOVO:bvrG3ETA5WW(2.65):bd10/20/2015:svnLENOVO:pn2464A26:pvrThinkPadL430:rvnLENOVO:rn2464A26:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:* EVDEV_ABS_00=23:2176:<x resolution> EVDEV_ABS_01=23:1134:<y resolution> EVDEV_ABS_35=23:2176:<x resolution> EVDEV_ABS_36=23:1134:<y resolution>
Did the same again and now the touchpad sends different values. Is this normal? lof:~/ $ sudo touchpad-edge-detector /dev/input/event6 Touchpad ETPS/2 Elantech Touchpad on /dev/input/event6 Move one finger around the touchpad to detect the actual edges Kernel says: x [0..2204], y [0..1160] Touchpad sends: x [20..2183], y [24..1157] -^C Touchpad size as listed by the kernel: 71x37mm Calculate resolution as: x axis: 2204/<width in mm> y axis: 1160/<height in mm> Suggested udev rule: # <Laptop model description goes here> evdev:name:ETPS/2 Elantech Touchpad:dmi:bvnLENOVO:bvrG3ETA5WW(2.65):bd10/20/2015:svnLENOVO:pn2464A26:pvrThinkPadL430:rvnLENOVO:rn2464A26:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:* EVDEV_ABS_00=20:2183:<x resolution> EVDEV_ABS_01=24:1157:<y resolution> EVDEV_ABS_35=20:2183:<x resolution> EVDEV_ABS_36=24:1157:<y resolution> lof:~/ $ sudo touchpad-edge-detector /dev/input/event6 Touchpad ETPS/2 Elantech Touchpad on /dev/input/event6 Move one finger around the touchpad to detect the actual edges Kernel says: x [0..2204], y [0..1160] Touchpad sends: x [22..2184], y [15..1151] -^C-- Touchpad size as listed by the kernel: 71x37mm Calculate resolution as: x axis: 2204/<width in mm> y axis: 1160/<height in mm> Suggested udev rule: # <Laptop model description goes here> evdev:name:ETPS/2 Elantech Touchpad:dmi:bvnLENOVO:bvrG3ETA5WW(2.65):bd10/20/2015:svnLENOVO:pn2464A26:pvrThinkPadL430:rvnLENOVO:rn2464A26:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:* EVDEV_ABS_00=22:2184:<x resolution> EVDEV_ABS_01=15:1151:<y resolution> EVDEV_ABS_35=22:2184:<x resolution> EVDEV_ABS_36=15:1151:<y resolution>
When i add the two lines i get and error and when i test it i still get the old dimensions. $ sudo vim /lib/udev/hwdb.d/90-libinput-model-quirks.hwdb […] ########################################## # Elantech ########################################## libinput:name:*ETPS/2 Elantech Touchpad*:dmi:* LIBINPUT_ATTR_RESOLUTION_HINT=31x31 LIBINPUT_MODEL_ELANTECH_TOUCHPAD=1 libinput:name:*ETPS/2 Elantech Touchpad*:dmi:*svnLENOVO:*pvrThinkPadL430* LIBINPUT_ATTR_RESOLUTION_HINT=30x26 […] $ sudo udevadm hwdb --update Error, DATA expected but got 'libinput:name:*ETPS/2 Elantech Touchpad*:dmi:*svnLENOVO:*pvrThinkPadL430*' in '/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb': Error, MATCH expected but got ' LIBINPUT_ATTR_RESOLUTION_HINT=30x26' in '/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb': $ sudo udevadm test /sys/class/input/event6 […] DEVPATH=/devices/platform/i8042/serio1/input/input5/event6 ID_INPUT=1 ID_INPUT_HEIGHT_MM=37 ID_INPUT_TOUCHPAD=1 ID_INPUT_TOUCHSCREEN=1 ID_INPUT_WIDTH_MM=71 ID_PATH=platform-i8042-serio-1 ID_PATH_TAG=platform-i8042-serio-1 ID_SERIAL=noserial LIBINPUT_ATTR_RESOLUTION_HINT=31x31 […]
(In reply to lightonflux from comment #8) > Did the same again and now the touchpad sends different values. Is this > normal? yes, because as your finger changes angle/pressure/shape you may reach or not reach different coordinates. Run the finger around the touchpad multiple times, the tool only takes the min/max it sees anyway so once you can't get the numbers to change anymore you can stop. as for the hwdb: you need an empty line before your addition.
ping?
Created attachment 125344 [details] xinput list-props 11 output for Elantech touchpad
Created attachment 125345 [details] udevadm test Command: sudo udevadm test /sys/class/input/event6 File of stdout without stderr.
Because of the LIBINPUT_ATTR_RESOLUTION_HINT=31x31 when running udevadm i don't think that the changes are applied. And i don't really feel a difference in the touchpad.
yeah, looks like it's not applied. what does your current hwdb file look like?
Created attachment 125569 [details] hwdb file 2016-08-05 It now looks like this.
looks correct, I can't spot any obvious typos. but now we're at the basic problem: I can't debug this from here. You'll need to figure out why it doesn't apply by looking at the sudo udevadm test /sys/class/input/eventX output. if there are any error messages that's a hint. otherwise what I usually do is add a FOO=1 property and check if that shows up - if it does but the other one doesn't it's overwritten by some other rule. increase the foo value between testing to make sure you're looking at the latest rules too and of course, always remember to rebuild the hwdb with sudo udevadm hwdb --update
Thanks for pinging. So i did some further testing. With these settings: ########################################## # Elantech ########################################## libinput:name:*ETPS/2 Elantech Touchpad*:dmi:* LIBINPUT_ATTR_RESOLUTION_HINT=31x31 LIBINPUT_MODEL_ELANTECH_TOUCHPAD=1 FOO=1 libinput:name:*ETPS/2 Elantech Touchpad*:dmi:*svnLENOVO:*pvrThinkPadL430* LIBINPUT_ATTR_RESOLUTION_HINT=30x26 FOO=2 Error log of the test command attached.
Created attachment 126124 [details] output of sudo udevadm test /sys/class/input/event6
ok, I found the issue. if multiple matches apply to a device, udevadm hwdb only returns the first one. this is a bit of a problem, I'll have to figure out how to work around this.
let's do the right thing and push this into systemd then we don't have to worry about the ATTR_RESOLUTION property anyway. run the touchpad-edge-detector tool again and make sure you really get all the extents (i.e. max/min values) for the touchpad x and y axes. Move the ringer around the outside a few times, that should do it. Then attach the output here again, I'll write the rule we can push to systemd to fix this.
Created attachment 126130 [details] touchpad-edge-detector output Here the output from sudo touchpad-edge-detector /dev/input/event6 Spend a good 2 minutes coming from all directions at the edges and moving around it.
submitted to systemd. Have a look at your 60-evdev.hwdb file, at the top it contains instructions to apply this locally. Once that's done, restart and you should see the new axis ranges and resolutions show up with evemu-describe. Once that happens, we can check if the touchpad still misbehaves. https://github.com/systemd/systemd/pull/4074
Thanks for pinging again. I used the new values in the last month and it worked well. Just reverted the changes and checked the default values (pre-commit). With the old defaults moving the finger in a circle made the cursor move in an oval. With the new values (i used for a month) the path of the cursor was very close to a circle. Although not perfect. Not sure if this is the quality of the pad, the irregular wear of the touchpad surface, my own inability to move in circles or another feature that got a tiny bit in the way (acceleration?). So as far as i know this touchpad works as well as it can in terms of right dimensions. I think we can change the status to resolved.
I'd say it's a combination of all of the above :) but acceleration is the biggest factor, with the current acceleration profile it decelerates when you move slowly so you'd have to move the circle at an extremely low speed to make sure that it always stays the same. sometimes an easier way to test is to run a 45 degree line on the touchpad and compare that with the output in a drawing program. Any skew is easier detected and pointer acceleration shouldn't be detrimental here since the direction remains the same. Thanks for testing again, I'll close this one.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.