I can reproduce this on my X230.

If you scroll from the center of the touchpad towards the bottom left corner, there is movement all the way.

However if you start scrolling the other way round, i.e. from the bottom left corner towards the center of the touchpad, then there isn't any response for the first 1 or 2cm.

This happens both in X11 with xf86-input-libinput 0.18.0 and on weston 1.9 with libinput 1.2.3 (tested with the drm backend).

Yeah, moving from the inside to the outside (In reply to Emilio Pozuelo Monfort from comment #1)
> I can reproduce this on my X230.
> 
> If you scroll from the center of the touchpad towards the bottom left
> corner, there is movement all the way.
> 
> However if you start scrolling the other way round, i.e. from the bottom
> left corner towards the center of the touchpad, then there isn't any
> response for the first 1 or 2cm.

Yup, exactly the behaviour I'm seeing.

run libinput-debug-events --verbose and look for the palm detction notices, it's most likely the exclusion zones
http://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html

(In reply to Peter Hutterer from comment #3)
> run libinput-debug-events --verbose and look for the palm detction notices,
> it's most likely the exclusion zones
> http://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html

I'm getting lot's of 
edge state: EDGE_SCROLL_TOUCH_STATE_AREA → SCROLL_EVENT_MOTION → EDGE_SCROLL_TOUCH_STATE_AREA
edge state: EDGE_SCROLL_TOUCH_STATE_AREA → SCROLL_EVENT_MOTION → EDGE_SCROLL_TOUCH_STATE_AREA
edge state: EDGE_SCROLL_TOUCH_STATE_AREA → SCROLL_EVENT_MOTION → EDGE_SCROLL_TOUCH_STATE_AREA
edge state: EDGE_SCROLL_TOUCH_STATE_AREA → SCROLL_EVENT_MOTION → EDGE_SCROLL_TOUCH_STATE_AREA
edge state: EDGE_SCROLL_TOUCH_STATE_AREA → SCROLL_EVENT_MOTION → EDGE_SCROLL_TOUCH_STATE_AREA

events when this happens. Does that help?

no, that's from the edge scroll state. You're looking for the line "palm: palm detected (edge)" - if that is the case, the touch is disabled as an assumed palm.

(In reply to Peter Hutterer from comment #5)
> no, that's from the edge scroll state. You're looking for the line "palm:
> palm detected (edge)" - if that is the case, the touch is disabled as an
> assumed palm.

Hm, no. I didn't spot any of those. The link you referenced mentions the palm exclusion zones to be on the left and right edge. I mostly notice this issue on the lower edge.

(In reply to Michael Biebl from comment #6)
> (In reply to Peter Hutterer from comment #5)
> > no, that's from the edge scroll state. You're looking for the line "palm:
> > palm detected (edge)" - if that is the case, the touch is disabled as an
> > assumed palm.
> 
> Hm, no. I didn't spot any of those. The link you referenced mentions the
> palm exclusion zones to be on the left and right edge. I mostly notice this
> issue on the lower edge.

Possibly related: I do have edge scrolling enabled via
/usr/bin/xinput set-prop 11 --type=int --format=8 290 0 1 0

the palm edge detection zones are on the side, the thumb detection is at the bottom though (see the link above).

(In reply to Michael Biebl from comment #7)
> Possibly related: I do have edge scrolling enabled via
> /usr/bin/xinput set-prop 11 --type=int --format=8 290 0 1 0

right, so what's likely happening here then is that the finger is detected as a horizontal scroll event, but those may be filtered out by the X driver if horizontal scrolling is disabled there. And a finger that generates horiz. scroll events doesn't move the pointer. do you see POINTER_AXIS events in the output?

ping?

Created attachment 123950 [details]
recording from evemu-record

(In reply to Peter Hutterer from comment #9)
> ping?

Hi there, I've been experiencing the same issue on similar hardware, and running libinput-debug-events also results in "edge state: EDGE_SCROLL_TOUCH_STATE_AREA → SCROLL_EVENT_MOTION → EDGE_SCROLL_TOUCH_STATE_AREA", when moving in from the sides of the touchpad. 

What I would like to add is previously attached result from a recording by evemu. When I was recording with evemu, moving my finger from the right off the touchpad to the center would not move the cursor on the screen at all. But, when I would playback the evemu recording, the cursor moved as it should have!

In response to your question about POINTER_AXIS events, I have this snippet:
edge state: EDGE_SCROLL_TOUCH_STATE_AREA → SCROLL_EVENT_MOTION → EDGE_SCROLL_TOUCH_STATE_AREA
gesture state: GESTURE_STATE_UNKNOWN → GESTURE_STATE_SCROLL
event1 	POINTER_AXIS     +17.77s	vert 5.81* horiz -1.73*
edge state: EDGE_SCROLL_TOUCH_STATE_AREA → SCROLL_EVENT_MOTION → EDGE_SCROLL_TOUCH_STATE_AREA
edge state: EDGE_SCROLL_TOUCH_STATE_AREA → SCROLL_EVENT_MOTION → EDGE_SCROLL_TOUCH_STATE_AREA
gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL
event1 	POINTER_AXIS     +17.79s	vert 9.56* horiz -3.37*

I should note that I have edge-scrolling disabled.

Is there anything else I can provide to help? This is only my second time replying to a bug-report, so I apologize if I'm making some kind of bug-report faux pas!

(In reply to Max from comment #11)
> Hi there, I've been experiencing the same issue on similar hardware, and
> running libinput-debug-events also results in "edge state:
> EDGE_SCROLL_TOUCH_STATE_AREA → SCROLL_EVENT_MOTION →
> EDGE_SCROLL_TOUCH_STATE_AREA", when moving in from the sides of the
> touchpad. 

you can ignore any edge state messages if edge scrolling is disabled. especially the AREA state just means "Not an edge, continue normally".

> What I would like to add is previously attached result from a recording by
> evemu. When I was recording with evemu, moving my finger from the right off
> the touchpad to the center would not move the cursor on the screen at all.
> But, when I would playback the evemu recording, the cursor moved as it
> should have!

upgrade to libevdev 1.5. the cause here is that uinput devices don't set the resolution and we rely on that in libinput for the touchpad sizes and to enable a few features. libevdev 1.5 uses the new uinput ioctls (you'll need kernel 4.5) and you'll get the resolution set properly and everything magically works ;)

I replayed your recording here and this shows up:
palm: palm detected (edge)

so the finger is detected as a palm when it stays at the edge for long enough.

I forgot, you can also use libevdev-tweak-device --resolution=XX,YY /dev/input/eventX (where xx/yy is your x and y resolution) once your device is up but that only works if you don't have something immediately hooking onto the device. so it only works for running libinput-debug-events, not for your X session.

you can also replay the recording through your real device's event node, in which case the palm detection should work too.

(In reply to Max from comment #10)
> Created attachment 123950 [details]
> recording from evemu-record

ok, after spending some time on this: Max, this is not the same hardware. I guess you're either on a T440 or later series but it's not obvious, your evemu version is quite old. Please file a separate bug for that. The x220 has a tiny touchpad compared to yours and has different features enabled.


so we're back to the original problem of the pointer not moving in the lower left corner and apparently the left edge. I got my x220 out and I can confirm the lack of movement in lower left corner - that corner overlaps with the software button area where we don't post movements. once you're outside of that area the movement starts. I can't confirm the right edge though, that one moves immediately

ok, one of the problems is: the x220's advertised range is different to what it actually has. This is quite common with synaptics touchpads before the T440 series touchpads and libinput doesn't cater for that (not sure how we could make this generic). As a result the button sizes are huge and misplaced which is why a large part of the touchpad is occupied by software buttons.

I filed this one with systemd:
https://github.com/systemd/systemd/pull/3397

With this the buttons are just over 6mm high and range in from the bottom edge of the touchpad. While the basic problem remains the same (and we won't fix this, no movement in the button areas is required, otherwise you can't click without moving the cursor) it should not be an issue anymore, or at least not much of an issue anymore, once the axis ranges are correct.

commit faf7a6107f5a5eb81a58a3879f7b7034803e043f
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue May 31 14:52:57 2016 +1000

    touchpad: warn if we have invalid touchpad ranges

see also the new documentation page:
https://wayland.freedesktop.org/libinput/doc/latest/absolute_coordinate_ranges.html

Can I disable the palm and/or thumb detection completely to see if that fixes the issue I'm having or have you already concluded that it's not actually related to that?

running touchpad-edge-detector, I get

$ sudo touchpad-edge-detector /dev/input/event5
Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event5
Move one finger around the touchpad to detect the actual edges
Kernel says:	x [1472..5472], y [1408..4448]
Touchpad sends:	x [1316..5626], y [1355..4826] \^C

Touchpad size as listed by the kernel: 53x23mm
Calculate resolution as:
	x axis: 4000/<width in mm>
	y axis: 3040/<height in mm>

Suggested udev rule:
# <Laptop model description goes here>
evdev:name:SynPS/2 Synaptics TouchPad:dmi:bvnLENOVO:bvr8DET72WW(1.42):bd02/18/2016:svnLENOVO:pn42914CG:pvrThinkPadX220:rvnLENOVO:rn42914CG:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:*
 EVDEV_ABS_00=1316:5626:<x resolution>
 EVDEV_ABS_01=1355:4826:<y resolution>
 EVDEV_ABS_35=1316:5626:<x resolution>
 EVDEV_ABS_36=1355:4826:<y resolution>

(In reply to Michael Biebl from comment #17)
> Can I disable the palm and/or thumb detection completely to see if that
> fixes the issue I'm having or have you already concluded that it's not
> actually related to that?

not without hacking the source but if I look at your touchpad output: the problem is that the axis ranges are very different to what the touchpad actually sends so the edge zones would be significantly larger. I suggest you calculate the resolution and put theudev rule in place (locate a 60-evdev.hwdb file and follow the instructions there). I'm a bit surprised though: we already have a hwdb entry for the x220 and that should apply. maybe get your distro to backport it.

https://github.com/systemd/systemd/blob/master/hwdb/60-evdev.hwdb#L210

I pulled that hwdb fix:

$ udevadm info /dev/input/event5
P: /devices/platform/i8042/serio1/input/input5/event5
N: input/event5
S: input/by-path/platform-i8042-serio-1-event-mouse
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse
E: DEVNAME=/dev/input/event5
E: DEVPATH=/devices/platform/i8042/serio1/input/input5/event5
E: EVDEV_ABS_00=1316:5627:58
E: EVDEV_ABS_01=1355:4826:81
E: EVDEV_ABS_35=1316:5627:58
E: EVDEV_ABS_36=1355:4826:81

Looks like it was applied correctly.

The problem still persists though. Sliding in from the bottom, I only get movement of the cursor after 1cm or so. Sliding from top to bottom I get movement of the cursor all the way.

(In reply to Michael Biebl from comment #20)
> The problem still persists though. Sliding in from the bottom, I only get
> movement of the cursor after 1cm or so. Sliding from top to bottom I get
> movement of the cursor all the way.

yep, that's intended. the bottom 10mm are reserved for the buttons (left vs right) and we discard movement when a finger is set down inside that button area. The reason is quite simple: when you press the touchpad to click, your finger shape changes and you'd get a movement before the button press which could cause you to miss the target. see this link for some details:
https://wayland.freedesktop.org/libinput/doc/latest/clickpad_softbuttons.html

when you move into the area from the top then we don't discard the motion.
the only way around this is changing over to clickfinger behaviour.

(In reply to Peter Hutterer from comment #21)
> yep, that's intended. the bottom 10mm are reserved for the buttons (left vs
> right) and we discard movement when a finger is set down inside that button
> area. 

Aha, thanks for the clarification. I guess we are getting to the bottom of this.
I assume the synaptics driver did not do something similar like libinput?

Since I use the (upper) hardware button and tap-to-click, can I disable the softbutton? I basically never use them and I would rather use all of my (small) touchpad when moving then mouse.

(In reply to Michael Biebl from comment #22)
> (In reply to Peter Hutterer from comment #21)
> > yep, that's intended. the bottom 10mm are reserved for the buttons (left vs
> > right) and we discard movement when a finger is set down inside that button
> > area. 
> 
> Aha, thanks for the clarification. I guess we are getting to the bottom of
> this.
> I assume the synaptics driver did not do something similar like libinput?

it should have, see synaptics commit 3adaf4623845d. same approach.

> Since I use the (upper) hardware button and tap-to-click, can I disable the
> softbutton?

yep, just change to the clickfinger method. see man libinput for the xorg.conf option to do so, or gsettings set org.gnome.desktop.peripherals.touchpad click-method 'fingers'. not sure what other DEs use, sorry

(In reply to Peter Hutterer from comment #23)
> gsettings set > org.gnome.desktop.peripherals.touchpad click-method 'fingers'. 

That did the trick. Thanks for being so patient!