Other infos:

$ sudo touchpad-edge-detector 108x42 /dev/input/event13
Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event13
Move one finger around the touchpad to detect the actual edges
Kernel says:    x [1330..5652], y [1094..4846]
Touchpad sends: x [1351..5635], y [1103..4718] -^C

Touchpad size as listed by the kernel: 108x42mm
User-specified touchpad size: 108x42mm
Calculated ranges: 4284/3615

Suggested udev rule:
# <Laptop model description goes here>
evdev:name:SynPS/2 Synaptics TouchPad:dmi:bvnInsyde:bvrF.13:bd07/21/2016:svnHewlett-Packard:pnHP255G5NotebookPC:pvrType1ProductConfigId:rvnHewlett-Packard:rn81F5:rvr66.26:cvnHewlett-Packard:ct10:cvrChassisVersion:*
 EVDEV_ABS_00=1351:5635:40
 EVDEV_ABS_01=1103:4718:86
 EVDEV_ABS_35=1351:5635:40
 EVDEV_ABS_36=1103:4718:86

Kernel edges are quite real. Even if I add the reported udev rule, the behavior is the same stated in the first comment.
Data reported in the first comment are without custom udev rules.

touchpads don't have configurable acceleration profiles, so the option being ignored is expected.

as for pointer movement: the pointer should stay "attached" to your finger for all but quite fast movement. i.e. a movement of ca 30mm on the touchpad should result in a movement of ca 30mm on the screen. is that not the case?

Guiseppe, I asked for an acceleration setting here but was turned down: https://bugs.freedesktop.org/show_bug.cgi?id=99000

Your best bet is to try to work with Peter to get the default tuned more to your liking.

(In reply to Peter Hutterer from comment #2)
> touchpads don't have configurable acceleration profiles, so the option being
> ignored is expected.
> 
> as for pointer movement: the pointer should stay "attached" to your finger
> for all but quite fast movement. i.e. a movement of ca 30mm on the touchpad
> should result in a movement of ca 30mm on the screen. is that not the case?

That's not the case. When I reach the target sometimes I need to correct the position by a small movement, but most of the time this occurs the pointer moves too fast and the target is exceeded/overtaken. That's not the behavior I expect and this issue is not present in synaptics. I don't know why, maybe because synaptics has more configurable options like noise cancelation or deceleration factor added to acceleration speed. 

Can't you introduce acceleration profiles flat/adaptive for my touchpad in libinput? I would try to use flat profile and see if it will resolve this issue. 
In the current behavior I feel a certain acceleration when I move my finger fast and longer and that's not a problem. The only problem is when I move my finger shorter and it seems that acceleration gives the pointer a boost which overtakes the target. 

Thanks and sorry if my English is bad, I'm from Italy.

(In reply to giuseppemargarita from comment #4)
> That's not the case. When I reach the target sometimes I need to correct the
> position by a small movement, but most of the time this occurs the pointer
> moves too fast and the target is exceeded/overtaken. That's not the behavior
> I expect and this issue is not present in synaptics. I don't know why, maybe
> because synaptics has more configurable options like noise cancelation or
> deceleration factor added to acceleration speed. 

which ones of those did you actually configure though? just because libinput doesn't have an option doesn't mean it doesn't exist, e.g. the noise cancellation in libinput is basically the same as synaptics. as for the actual speed, it's a bit hard to figure out what synaptics does...

> Can't you introduce acceleration profiles flat/adaptive for my touchpad in
> libinput? I would try to use flat profile and see if it will resolve this
> issue. 

the current profile is the 'adaptive' profile, same as the mouse profile.
You can quite easily hack the source to use the flat profile instead but tbh
I doubt that's the behaviour you want either.

> In the current behavior I feel a certain acceleration when I move my finger
> fast and longer and that's not a problem. The only problem is when I move my
> finger shorter and it seems that acceleration gives the pointer a boost
> which overtakes the target. 

the question is *why* this happens, since the acceleration itself should be
the same on any device, regardless of the resolution. So far I only found a
possible issue with the sampling rate but yours is within the same range as
my touchpad here, so shouldn't be affected by that. Any help in identifying
why your touchpad appears to accelerate when it shouldn't would be
appreciated.

(In reply to Peter Hutterer from comment #5) 
> which ones of those did you actually configure though? just because libinput
> doesn't have an option doesn't mean it doesn't exist, e.g. the noise
> cancellation in libinput is basically the same as synaptics. as for the
> actual speed, it's a bit hard to figure out what synaptics does...

I've actually configured libinput because I opened this bug report and want to help you to find the solution. The options are listed in the first comment.
I wrote the configuration in a .conf file in xorg directory because I can't configure libinput from Plasma desktop. Unfortunately Plasma 5 has not a full support to libinput, so I can't configure it properly from system settings.
In system setting I can't change some options and others are grayed. There's also a bug which I can't set the right acceleration speed. 
I talked about that here: https://bbs.archlinux.org/viewtopic.php?id=222388
And found a workaround setting the right acceleration speed from an executable script run by Plasma at its startup.

Anyway, libinput is too problematic for me and I will use synaptics because it's more comfortable.  

When using synaptics, the options used are the following (all configured by system setting in Plasma 5; no text xorg .conf file and no scripts are used):  
Device 'SynPS/2 Synaptics TouchPad':
        Device Enabled (142):   1
        Coordinate Transformation Matrix (144): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Accel Profile (270):     1
        Device Accel Constant Deceleration (271):       2.500000
        Device Accel Adaptive Deceleration (272):       1.000000
        Device Accel Velocity Scaling (273):    12.500000
        Synaptics Edges (274):  1632, 5350, 1356, 4584
        Synaptics Finger (275): 25, 30, 0
        Synaptics Tap Time (276):       180
        Synaptics Tap Move (277):       254
        Synaptics Tap Durations (278):  180, 180, 100
        Synaptics ClickPad (279):       0
        Synaptics Middle Button Timeout (280):  75
        Synaptics Two-Finger Pressure (281):    282
        Synaptics Two-Finger Width (282):       7
        Synaptics Scrolling Distance (283):     116, 116
        Synaptics Edge Scrolling (284): 0, 0, 0
        Synaptics Two-Finger Scrolling (285):   1, 1
        Synaptics Move Speed (286):     1.000000, 1.750000, 0.034947, 0.000000
        Synaptics Off (287):    2
        Synaptics Locked Drags (288):   0
        Synaptics Locked Drags Timeout (289):   5000
        Synaptics Tap Action (290):     0, 0, 0, 0, 1, 2, 3
        Synaptics Click Action (291):   1, 1, 1
        Synaptics Circular Scrolling (292):     0
        Synaptics Circular Scrolling Distance (293):    0.100007
        Synaptics Circular Scrolling Trigger (294):     0
        Synaptics Circular Pad (295):   0
        Synaptics Palm Detection (296): 0
        Synaptics Palm Dimensions (297):        10, 200
        Synaptics Coasting Speed (298): 20.000000, 50.000000
        Synaptics Pressure Motion (299):        30, 160
        Synaptics Pressure Motion Factor (300): 1.000000, 1.000000
        Synaptics Grab Event Device (301):      0
        Synaptics Gestures (302):       1
        Synaptics Capabilities (303):   1, 0, 1, 1, 1, 1, 1
        Synaptics Pad Resolution (304): 89, 40
        Synaptics Area (305):   0, 0, 0, 0                                                          
        Synaptics Noise Cancellation (306):     28, 28                                              
        Device Product ID (266):        2, 7                                                        
        Device Node (265):      "/dev/input/event13"

It would be great if you can reproduce the behavior of these options in libinput. But I can't configure noise cancellation and don't know if deceleration is available in libinput.
 
> the current profile is the 'adaptive' profile, same as the mouse profile.
> You can quite easily hack the source to use the flat profile instead but tbh
> I doubt that's the behaviour you want either.

Okay, but why can't I set the flat profile from the configuration?

> the question is *why* this happens, since the acceleration itself should be
> the same on any device, regardless of the resolution. So far I only found a
> possible issue with the sampling rate but yours is within the same range as
> my touchpad here, so shouldn't be affected by that. Any help in identifying
> why your touchpad appears to accelerate when it shouldn't would be
> appreciated.

I don't know how, I gave you all I could report. Can't you find anything from evemu record?

(In reply to giuseppemargarita from comment #6)
> I've actually configured libinput because I opened this bug report and want
> to help you to find the solution. The options are listed in the first
> comment.

fwiw, I was referring to the synaptics options that are there but often unused.

> It would be great if you can reproduce the behavior of these options in
> libinput. But I can't configure noise cancellation and don't know if
> deceleration is available in libinput.

synaptics pointer acceleration is... complicated and almost impossible to
reproduce. Amongst other things, it depends on your screen resolution.
https://who-t.blogspot.com.au/2016/09/synaptics-pointer-acceleration.html

> Okay, but why can't I set the flat profile from the configuration?

we only expose config options when there's something to configure. In this
case we only have one profile, so no point to expose an option.

> I don't know how, I gave you all I could report. Can't you find anything
> from evemu record?

maybe. it's always hard to infer "feel" from pure recording and on top of
that i'm bottlenecking quite badly, so any help is appreciated. The
acceleration code is all in src/filter.c and it's not that hard to
understand (there are plenty of comments, anyway).

(In reply to Peter Hutterer from comment #7)
> synaptics pointer acceleration is... complicated and almost impossible to
> reproduce. Amongst other things, it depends on your screen resolution.
> https://who-t.blogspot.com.au/2016/09/synaptics-pointer-acceleration.html

I don't understand because I'm not a developer. I could understand that synaptic was written in a confusing and complicated way, but his behavior is better then libinput.
You have your reason from developer point of view, but I'm not a developer. I'm a user. I don't care about code. I care about things work on my system in a good and comfortable way.
libinput works, but it's not comfortable. And it's less customizable. I can only set the acceleration speed (that's even broken on Plasma desktop, but I know that's KDE developers fault). If I set it higher, the pointer is too reactive. If I set it lower, the pointer is good for short movements, but not for large ones. If a find the right value in the middle, the pointer is good for large movements, but not for short ones. And I can't even disable the acceleration. 
I thought updates was an improvement, but I don't see any improvement moving from synaptics to libinput.
I would not even care about that issue, but synaptics became deprecated and in the future it will not work with further updates (especially on Arch Linux since it's a rolling release distro). So I'm not really free to use synaptics because libinput is the default supported touchpad driver and sooner or later I have to use it permanently.

Please, don't take these words like an offense, I'm only trying to explain my point of view.

> we only expose config options when there's something to configure. In this
> case we only have one profile, so no point to expose an option.

Are you saying my touchpad has only "accelerated profile"?
I don't remember (I'm using libinput now because I'm trying to get used to its behavior) but I'm pretty sure that I could disable the acceleration on synaptics. Even on Windows by Synaptycs proprietary driver.
Maybe I'm wrong but I think my touchpad could work without acceleration, so it seems more a libinput missing feature.  

> maybe. it's always hard to infer "feel" from pure recording and on top of
> that i'm bottlenecking quite badly, so any help is appreciated. The
> acceleration code is all in src/filter.c and it's not that hard to
> understand (there are plenty of comments, anyway).

Don't know how to do and, as I said before, I'm not a developer. :(

ok, let me rephrase this: without implementing half the xserver acceleration code in libinput, I cannot reproduce the synaptics behavior in libinput. even then there is no guarantee it will behave the same way because it scales depending on screen size and libinput does not have access to that. So it's nice that you don't care how it's done, but I do and it's virtually impossible.

right now, most of what I get is people telling me how it doesn't work and how scandalous this situation is, but what I really need is people who are willing to help out *fixing* it. because right now, I'm virtually the only person working on libinput, and time is not infinite.

> Are you saying my touchpad has only "accelerated profile"?

yes. you can try to switch profiles around or even effectively disable the acceleration for testing but it does require some developer skills.

note that short of relatively fast movements, no acceleration should be applied [1]. in fact, we still slow down the touchpad by a magic factor 0.4 anyway (compared to just forwarding device units). so if slow motions are too fast, then something else weird is going on.

[1] https://who-t.blogspot.com.au/2016/12/libinput-touchpad-pointer-acceleration.html

(In reply to Peter Hutterer from comment #9)
> ok, let me rephrase this: without implementing half the xserver acceleration
> code in libinput, I cannot reproduce the synaptics behavior in libinput.
> even then there is no guarantee it will behave the same way because it
> scales depending on screen size and libinput does not have access to that.
> So it's nice that you don't care how it's done, but I do and it's virtually
> impossible.
> 
> right now, most of what I get is people telling me how it doesn't work and
> how scandalous this situation is, but what I really need is people who are
> willing to help out *fixing* it. because right now, I'm virtually the only
> person working on libinput, and time is not infinite.

Okay, I understand. Anyway I didn't switch back to synaptics and have to say that after using libinput in the last days I'm getting used to its behavior and it's not scandalous as I thought in the first times.
Synaptics remains better to me, but I won't use it anymore because sooner or later I have to switch to libinput. So right now I think the best thing to do is sticking to libinput, getting used to its behavior and forget synaptics.

> yes. you can try to switch profiles around or even effectively disable the
> acceleration for testing but it does require some developer skills.

I can't do it and don't think that flat profile is what I really need because I always used accelerated profiles (in synaptics and on MS Windows). I wanted to try flat profile to see if I could get closer to synaptics behavior or just to have an extra option for testing the movements.
But is there a chance to introduce flat profile in the future also for touchpads? You said "touchpads don't have configurable acceleration profiles", so that's not only my touchpad (first I thought it was an hardware issue, but was wrong), but all touchpads managed by libinput.
It's a libinput lack and it would be a great improvement if a user could enable or disable it by choice. Then maybe I will choose adaptive profile as I'm doing now,  but maybe other users don't.

> note that short of relatively fast movements, no acceleration should be
> applied [1]. in fact, we still slow down the touchpad by a magic factor 0.4
> anyway (compared to just forwarding device units). so if slow motions are
> too fast, then something else weird is going on.
> 
> [1]
> https://who-t.blogspot.com.au/2016/12/libinput-touchpad-pointer-acceleration.
> html

No, I don't think it's an issue. I thought it was, but talking to you and understanding how libinput works I figured out this is its behavior, not something weird.
Since synaptics behavior is not reproducible, the only thing I can do is getting used to libinput. It's only a matter of habit.
Yesterday I came back to use Windows after lots of days to watch a streaming service not available on Linux and the touchpad was quite unusable to me, just because I was getting used to libinput behavior and proprietary driver has another way to accelerate the pointer on Windows (even different to synaptics on Linux, but much closer to it than libinput).

So that's all, I think this bug could be closed. In wish only Plasma desktop could have full support to libinput, not forcing me to adjust acceleration speed at the start of any session, but that's not your problem. 

Thank you anyway. 
Best regards.

grab this branch here:
https://github.com/whot/libinput/tree/wip/touchpad-accel-debug-output

build it:
https://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html

then run sudo ./tools/event-debug --verbose

Move your finger on the touchpad and look at the "touch movement" message whenever you lift a finger. What acceleration factor do you usually get?
Note that this sums up the deltas, so stick to straight lines to make it mentally easier to map to the distance traveled.

Also make sure that the mm distance is correct, just in case.

(In reply to Peter Hutterer from comment #11)
> grab this branch here:
> https://github.com/whot/libinput/tree/wip/touchpad-accel-debug-output
> 
> build it:
> https://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html
> 
> then run sudo ./tools/event-debug --verbose
> 
> Move your finger on the touchpad and look at the "touch movement" message
> whenever you lift a finger. What acceleration factor do you usually get?
> Note that this sums up the deltas, so stick to straight lines to make it
> mentally easier to map to the distance traveled.
> 
> Also make sure that the mm distance is correct, just in case.

I usually get avg factor 0.3. Sometimes 0.2 and other times 0.4.

The distance traveled is quite real. The total width is about 108 mm. When I touch the edges (left or right) I get:
palm: palm detected (edge)

And in this case when I move the finger to the center, the pointer doesn't move:
palm: palm detected (edge)
button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA
button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event12: touch movement 0.0mm, pixels 0.0, raw px 0.0, avg factor -nan

But when I touch closer to the edge and move the finger horizontally across the touchpad, the pointer moves and I get:
button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event12: touch movement 100.4mm, pixels 1459.0, raw px 3951.9, avg factor 0.4

Physical width is 108 mm.

"palm: palm detected (edge)" is not shown when I touch up and down edges. Moving vertically from up to down edges gives me:
button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event12: touch movement 39.2mm, pixels 570.1, raw px 1542.4, avg factor 0.4

39 mm traveled, but physical height is 42 mm.

These are the lines about my touchpad when I start the debug:
event12: tagged as LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD
input device 'SynPS/2 Synaptics TouchPad', /dev/input/event12 is tagged by udev as: Touchpad
SynPS/2 Synaptics TouchPad: using pressure-based touch detection
input device 'SynPS/2 Synaptics TouchPad', /dev/input/event12 is a touchpad
palm: dwt activated with SynPS/2 Synaptics TouchPad<->AT Translated Set 2 keyboard
-event12  DEVICE_ADDED     SynPS/2 Synaptics TouchPad        seat0 default group6  cap:pg  size 108x42mm tap(dl off) left scroll-nat scroll-2fg-edge dwt-on

Ah, forget to mention, I have the following custom udev rules (got them from touchpad-edge-detector):
# HP 255 G5
evdev:name:SynPS/2 Synaptics TouchPad:dmi:bvnInsyde:bvrF.13:bd07/21/2016:svnHewlett-Packard:pnHP255G5NotebookPC:pvrType1ProductConfigId:rvnHewlett-Packard:rn81F5:rvr66.26:cvnHewlett-Packard:ct10:cvrChassisVersion:*
 EVDEV_ABS_00=1349:5629:40
 EVDEV_ABS_01=1098:4718:86
 EVDEV_ABS_35=1349:5629:40
 EVDEV_ABS_36=1098:4718:86

(In reply to giuseppemargarita from comment #12)
> I usually get avg factor 0.3. Sometimes 0.2 and other times 0.4.

that's weird. 0.3 is deceleration, 0.4 should be the factor for "map to straight movement" and for all but very slow movements that should be the one you see. Very strange that you see 0.3 or less here.

the edge behaviour is expected, that's palm detection kicking in.

> Ah, forget to mention, I have the following custom udev rules (got them from
> touchpad-edge-detector):
> # HP 255 G5
> evdev:name:SynPS/2 Synaptics
> TouchPad:dmi:bvnInsyde:bvrF.13:bd07/21/2016:svnHewlett-Packard:
> pnHP255G5NotebookPC:pvrType1ProductConfigId:rvnHewlett-Packard:rn81F5:rvr66.
> 26:cvnHewlett-Packard:ct10:cvrChassisVersion:*
>  EVDEV_ABS_00=1349:5629:40
>  EVDEV_ABS_01=1098:4718:86
>  EVDEV_ABS_35=1349:5629:40
>  EVDEV_ABS_36=1098:4718:86

If these are correct, they should be added to systemd's hwdb so other owners of that device get to benefit too. How far out are min/max ranges, is it enough to just set the resolution?

(In reply to Peter Hutterer from comment #13)
> (In reply to giuseppemargarita from comment #12)
> that's weird. 0.3 is deceleration, 0.4 should be the factor for "map to
> straight movement" and for all but very slow movements that should be the
> one you see. Very strange that you see 0.3 or less here.
So? Was I right or that's really something wrong? 
I'm with smartphone now, but I remember that short movements were usually with 0.3, sometimes with 0.2. Long movements usually with 0.4.
I could try again tomorrow.

Anyway as time passing by I'm getting used to libinput behavior and pointer movement is not very problematic to me. 

> > Ah, forget to mention, I have the following custom udev rules (got them from
> > touchpad-edge-detector):
> > # HP 255 G5
> > evdev:name:SynPS/2 Synaptics
> > TouchPad:dmi:bvnInsyde:bvrF.13:bd07/21/2016:svnHewlett-Packard:
> > pnHP255G5NotebookPC:pvrType1ProductConfigId:rvnHewlett-Packard:rn81F5:rvr66.
> > 26:cvnHewlett-Packard:ct10:cvrChassisVersion:*
> >  EVDEV_ABS_00=1349:5629:40
> >  EVDEV_ABS_01=1098:4718:86
> >  EVDEV_ABS_35=1349:5629:40
> >  EVDEV_ABS_36=1098:4718:86
> 
> If these are correct, they should be added to systemd's hwdb so other owners
> of that device get to benefit too. How far out are min/max ranges, is it
> enough to just set the resolution?
I didn't remember how far they were. Maybe I should delete these rules and reload default ones, then rerun touchpad edge detector. 
And, sorry for my ignorance, I don't know what you mean for setting the resolution. 
I'll do it tomorrow.

The touchpad-edge-detector will give you the correct rules for what you measured, but sometimes the kernel e.g. announces 1350:5630:30 and you measured 1349:5629:40. In that case, changing the min/max values (the first two values) isn't necessary, the real ones are close enough. Only the resolution is off by some significant factor, so the udev rules becomes merely ::40 (i.e. only overwriting the resolution).

(In reply to giuseppemargarita from comment #14)
> So? Was I right or that's really something wrong? 
> I'm with smartphone now, but I remember that short movements were usually
> with 0.3, sometimes with 0.2. Long movements usually with 0.4.
> I could try again tomorrow.

please, try to spend the time and effort in collecting data that's useful to act on. I can't fix bugs based on guesswork. I don't mind if you take a day longer to reply, but without data I can't do anything and I can't guess what your touchpad does.

(In reply to Peter Hutterer from comment #15)
> The touchpad-edge-detector will give you the correct rules for what you
> measured, but sometimes the kernel e.g. announces 1350:5630:30 and you
> measured 1349:5629:40. In that case, changing the min/max values (the first
> two values) isn't necessary, the real ones are close enough. Only the
> resolution is off by some significant factor, so the udev rules becomes
> merely ::40 (i.e. only overwriting the resolution).
> 
> (In reply to giuseppemargarita from comment #14)
> > So? Was I right or that's really something wrong? 
> > I'm with smartphone now, but I remember that short movements were usually
> > with 0.3, sometimes with 0.2. Long movements usually with 0.4.
> > I could try again tomorrow.
> 
> please, try to spend the time and effort in collecting data that's useful to
> act on. I can't fix bugs based on guesswork. I don't mind if you take a day
> longer to reply, but without data I can't do anything and I can't guess what
> your touchpad does.

Understood, I'll try when have the laptop under my hands.

Reset default rules. I run touchpad-edge-detector several times and got these results:

Kernel says:    x [1330..5652], y [1094..4846]
Touchpad sends: x [1350..5620], y [1090..4714] /
1350:5620:40
1090:4714:86

Kernel says:    x [1330..5652], y [1094..4846]
Touchpad sends: x [1350..5630], y [1085..4718] |
1350:5630:40
1085:4718:87

Kernel says:    x [1330..5652], y [1094..4846]
Touchpad sends: x [1352..5623], y [1085..4713] /
1352:5623:40
1085:4713:86

Kernel says:    x [1330..5652], y [1094..4846]
Touchpad sends: x [1350..5626], y [1094..4714] \
1350:5626:40
1094:4714:86

Kernel says:    x [1330..5652], y [1094..4846]
Touchpad sends: x [1354..5625], y [1079..4718] -
1354:5625:40
1079:4718:87

Kernel says:    x [1330..5652], y [1094..4846]
Touchpad sends: x [1352..5633], y [1094..4718] |
1352:5633:40
1094:4718:86

All edges are quite closer to kernel values, except bottom edge far about 120.
x resolution is always 40, y resolution varies from 86 to 87.

I adopted the following custom rule as an average:
evdev:name:SynPS/2 Synaptics TouchPad:dmi:bvnInsyde:bvrF.13:bd07/21/2016:svnHewlett-Packard:pnHP255G5NotebookPC:pvrType1ProductConfigId:rvnHewlett-Packard:rn81F5:rvr66.26:cvnHewlett-Packard:ct10:cvrChassisVersion:*
 EVDEV_ABS_00=1350:5626:40
 EVDEV_ABS_01=1088:4716:86
 EVDEV_ABS_35=1350:5626:40
 EVDEV_ABS_36=1088:4716:86

Now event-debug. These are the strings from shorts movements, after I lift the finger from the touchpad:

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 2.2mm, pixels 15.2, raw px 86.6, avg factor 0.2

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 1.6mm, pixels 13.6, raw px 63.0, avg factor 0.2

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 5.7mm, pixels 70.8, raw px 226.4, avg factor 0.3

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 2.8mm, pixels 31.0, raw px 109.3, avg factor 0.3

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 2.5mm, pixels 33.6, raw px 99.4, avg factor 0.3

Sometimes 0.3, other times 0.2. But I noticed that If I move 1 mm or less, I get also 0.1:

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 1.0mm, pixels 5.6, raw px 38.4, avg factor 0.1

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 0.8mm, pixels 5.5, raw px 29.5, avg factor 0.2

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 0.8mm, pixels 4.0, raw px 29.5, avg factor 0.1

All these above are recorded for slow, normal and fast movement.

If the distance covered is more, the results varies on the speed. 

The following are for quite half touchpad distance, normal speed:

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 50.1mm, pixels 713.4, raw px 1973.4, avg factor 0.4

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 56.0mm, pixels 810.9, raw px 2204.9, avg factor 0.4

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 56.8mm, pixels 811.9, raw px 2237.3, avg factor 0.4

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 60.6mm, pixels 866.8, raw px 2385.4, avg factor 0.4

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 58.5mm, pixels 850.1, raw px 2303.0, avg factor 0.4

These for same distance, fast speed:

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 43.9mm, pixels 818.4, raw px 1729.4, avg factor 0.5

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 51.5mm, pixels 1169.0, raw px 2029.0, avg factor 0.6

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 54.7mm, pixels 2146.6, raw px 2154.8, avg factor 1.0

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 56.3mm, pixels 1741.9, raw px 2214.8, avg factor 0.8

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 56.2mm, pixels 1615.6, raw px 2212.1, avg factor 0.7

Same distance for slow speed is always 0.4.

Hope this helps. For more debug, ask me.
Best regards

Ping?

still working on this. for movements less than 1mm i'm not surprised that the speed is small, that's an intended feature to enhance precision.
There is also a hysteresis that can swallow the first 0.5mm of movement (to avoid pointer jitter).

For the rest:
event13: touch movement 5.7mm, pixels 70.8, raw px 226.4, avg factor 0.3

for a <6mm movement you get a 70 pixel movement. That seems about alright compared to what I have here (with the default 0.0 setting).
fwiw, the 'flat' acceleration profile would give you 226 pixels - clearly not useful.

a factor of 0.4 should be a roughly 1:1 movement between the finger and the pointer on the screen, is this correct? If that's not the case, do different-length movements reflect this?

(In reply to Peter Hutterer from comment #20)
> for a <6mm movement you get a 70 pixel movement. That seems about alright
> compared to what I have here (with the default 0.0 setting).
> fwiw, the 'flat' acceleration profile would give you 226 pixels - clearly
> not useful.
Wait, I have -0.4 acceleration speed as stated in the previous comments (I can't set it from Plasma system settings, but I set it from an autostart script).
Default 0.0 is too fast for me.

> a factor of 0.4 should be a roughly 1:1 movement between the finger and the
> pointer on the screen, is this correct? If that's not the case, do
> different-length movements reflect this?
This is often correct, but sometimes I get 0.3.

If I do a >6mm movement with always the same speed, I get always 0.4.
But when the speed is not the same, maybe if I slow it on the end of the movement, sometimes I get 0.3. 

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 8.0mm, pixels 103.3, raw px 314.3, avg factor 0.3

button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 12.1mm, pixels 165.0, raw px 474.4, avg factor 0.3

 event13  POINTER_MOTION    +8.62s        0.35/  0.00
 event13  POINTER_MOTION    +8.63s        0.54/  0.00
 event13  POINTER_MOTION    +8.64s        0.64/  0.00
 event13  POINTER_MOTION    +8.65s        1.11/  0.00
 event13  POINTER_MOTION    +8.66s        1.29/  0.00
 event13  POINTER_MOTION    +8.67s        1.44/  0.00
 event13  POINTER_MOTION    +8.68s        1.58/  0.00
 event13  POINTER_MOTION    +8.69s        1.70/  0.00
 event13  POINTER_MOTION    +8.70s        1.81/  0.00
 event13  POINTER_MOTION    +8.71s        2.58/  0.00
 event13  POINTER_MOTION    +8.72s        2.77/  0.00
 event13  POINTER_MOTION    +8.73s        2.17/  0.00
 event13  POINTER_MOTION    +8.74s        2.91/  0.00
 event13  POINTER_MOTION    +8.75s        2.91/  0.00
 event13  POINTER_MOTION    +8.76s        2.91/  0.00
 event13  POINTER_MOTION    +8.77s        2.91/  0.00
 event13  POINTER_MOTION    +8.78s        2.55/  0.00
 event13  POINTER_MOTION    +8.79s        3.64/  0.00
 event13  POINTER_MOTION    +8.80s        2.91/  0.00
 event13  POINTER_MOTION    +8.81s        3.64/  0.00
 event13  POINTER_MOTION    +8.82s        4.37/  0.00
 event13  POINTER_MOTION    +8.83s        3.64/  0.00
 event13  POINTER_MOTION    +8.84s        3.64/  0.00
 event13  POINTER_MOTION    +8.85s        4.01/  0.00
 event13  POINTER_MOTION    +8.86s        2.91/  0.00
 event13  POINTER_MOTION    +8.87s        2.91/  0.00
 event13  POINTER_MOTION    +8.88s        2.19/  0.00
 event13  POINTER_MOTION    +8.89s        2.19/  0.00
 event13  POINTER_MOTION    +8.90s        2.19/  0.00
 event13  POINTER_MOTION    +8.91s        1.46/  0.00
 event13  POINTER_MOTION    +8.92s        1.46/  0.00
 event13  POINTER_MOTION    +8.93s        0.73/  0.00
 event13  POINTER_MOTION    +8.94s        0.73/  0.00
 event13  POINTER_MOTION    +8.95s        0.73/  0.00
 event13  POINTER_MOTION    +8.96s        0.73/  0.00
 event13  POINTER_MOTION    +8.97s        0.73/  0.34
 event13  POINTER_MOTION    +8.98s        0.36/  0.83
button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 14.2mm, pixels 194.7, raw px 557.2, avg factor 0.3

event13  POINTER_MOTION   +36.72s        0.48/  0.00
 event13  POINTER_MOTION   +36.73s        3.58/  0.00
 event13  POINTER_MOTION   +36.74s        3.48/  0.00
 event13  POINTER_MOTION   +36.75s        4.87/  0.00
 event13  POINTER_MOTION   +36.76s        3.64/  0.00
 event13  POINTER_MOTION   +36.77s        3.64/  0.00
 event13  POINTER_MOTION   +36.78s        3.64/  0.00
 event13  POINTER_MOTION   +36.79s        3.64/  0.00
 event13  POINTER_MOTION   +36.80s        3.64/  0.17
 event13  POINTER_MOTION   +36.81s        4.37/  0.00
 event13  POINTER_MOTION   +36.82s        4.37/  0.00
 event13  POINTER_MOTION   +36.83s        5.10/  0.00
 event13  POINTER_MOTION   +36.84s        4.37/  0.00
 event13  POINTER_MOTION   +36.85s        3.64/  0.00
 event13  POINTER_MOTION   +36.86s        3.64/  0.00
 event13  POINTER_MOTION   +36.87s        3.64/  0.00
 event13  POINTER_MOTION   +36.88s        2.91/  0.00
 event13  POINTER_MOTION   +36.89s        2.91/  0.00
 event13  POINTER_MOTION   +36.90s        2.91/  0.00
 event13  POINTER_MOTION   +36.91s        2.91/  0.00
 event13  POINTER_MOTION   +36.92s        2.91/  0.00
 event13  POINTER_MOTION   +36.93s        2.91/  0.00
 event13  POINTER_MOTION   +36.94s        2.91/  0.00
 event13  POINTER_MOTION   +36.95s        2.91/  0.00
 event13  POINTER_MOTION   +36.96s        2.91/  0.00
 event13  POINTER_MOTION   +36.97s        2.91/  0.00
 event13  POINTER_MOTION   +36.98s        2.91/  0.00
 event13  POINTER_MOTION   +36.99s        2.91/  0.00
 event13  POINTER_MOTION   +37.00s        2.91/  0.00
 event13  POINTER_MOTION   +37.01s        2.91/  0.00
 event13  POINTER_MOTION   +37.02s        2.55/  1.02
 event13  POINTER_MOTION   +37.03s        2.91/  0.68
 event13  POINTER_MOTION   +37.04s        2.19/  0.00
 event13  POINTER_MOTION   +37.05s        2.19/  0.00
 event13  POINTER_MOTION   +37.06s        2.19/  0.00
 event13  POINTER_MOTION   +37.07s        2.19/  0.00
 event13  POINTER_MOTION   +37.08s        2.19/  0.51
 event13  POINTER_MOTION   +37.09s        1.46/  0.68
 event13  POINTER_MOTION   +37.10s        2.19/  0.17
 event13  POINTER_MOTION   +37.11s        1.46/  0.00
 event13  POINTER_MOTION   +37.12s        1.46/  0.68
 event13  POINTER_MOTION   +37.13s        1.46/  0.00
 event13  POINTER_MOTION   +37.14s        2.55/  0.85
 event13  POINTER_MOTION   +37.15s        0.73/  0.17
 event13  POINTER_MOTION   +37.16s        1.46/  0.68
 event13  POINTER_MOTION   +37.17s        0.73/  0.00
 event13  POINTER_MOTION   +37.18s        0.72/  0.67
 event13  POINTER_MOTION   +37.19s        0.65/  0.00
 event13  POINTER_MOTION   +37.20s        0.65/  0.60
 event13  POINTER_MOTION   +37.21s        0.65/  0.00
 event13  POINTER_MOTION   +37.22s        0.33/  0.93
 event13  POINTER_MOTION   +37.23s        0.67/  0.00
 event13  POINTER_MOTION   +37.23s        0.67/  0.63
 event13  POINTER_MOTION   +37.24s        0.65/  0.00
 event13  POINTER_MOTION   +37.26s        0.65/  0.61
 event13  POINTER_MOTION   +37.27s        0.65/  0.00
 event13  POINTER_MOTION   +37.27s        0.65/  0.61
 event13  POINTER_MOTION   +37.28s        0.65/  0.00
 event13  POINTER_MOTION   +37.30s        0.59/  0.00
 event13  POINTER_MOTION   +37.30s        0.59/  0.00
 event13  POINTER_MOTION   +37.33s        0.54/  0.00
 event13  POINTER_MOTION   +37.33s        0.50/  0.00
 event13  POINTER_MOTION   +37.87s        0.38/  0.00
button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event13: touch movement 29.3mm, pixels 398.9, raw px 1154.8, avg factor 0.3

Is this correct? Should I get always 0.4 in these cases?

Anyway I'm getting used to libinput behavior, but don't know why I feel that very shorts movements are still strange, not always precise. 
I felt synaptics was more precise. Also proprietary synaptics on Windows, even if I generally don't like its behavior.

it's an average. with the speed setting 0.0 I get 0.4 for almost everything, anything less is hard. so 0.3 indicates that it is slower, but I guess the configurable range is too narrow.

I think I know what you mean with the short motions overshooting though, not sure what the cause for that is yet.

(In reply to Peter Hutterer from comment #22)
> I think I know what you mean with the short motions overshooting though, not
> sure what the cause for that is yet.
Are you experiencing the same behavior on your touchpad?
I'd like to know if it's only me or others are affected...

I'm playing with the event-debug and noticed an odd thing.
If I stick the finger in any point and don't slide it, but move it up and down/left and right remaining always in the same point, the pointer moves roughly 4-5 mm.

Is this behavior normal? Shouldn't the pointer be fixed or move less? 
I expect it moves less, maybe not over 1 mm, but I see it moves more that it should do.

button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA
-event12  POINTER_MOTION    +1.92s        0.00/  0.16
 event12  POINTER_MOTION    +1.94s        0.00/  0.22
 event12  POINTER_MOTION    +1.97s        0.00/  0.23
 event12  POINTER_MOTION    +2.00s        0.00/  0.23
 event12  POINTER_MOTION    +2.02s        0.00/  0.24
 event12  POINTER_MOTION    +2.06s        0.00/  0.37
 event12  POINTER_MOTION    +2.08s        0.00/  0.25
 event12  POINTER_MOTION    +2.08s        0.00/  0.26
 event12  POINTER_MOTION    +2.11s        0.00/  0.26
 event12  POINTER_MOTION    +2.12s        0.00/  0.40
 event12  POINTER_MOTION    +2.14s        0.00/  0.27
 event12  POINTER_MOTION    +2.16s        0.00/  0.28
 event12  POINTER_MOTION    +2.17s        0.00/  0.28
 event12  POINTER_MOTION    +2.28s        0.00/  0.42
 event12  POINTER_MOTION    +2.68s        0.00/ -0.31
 event12  POINTER_MOTION    +2.69s        0.00/ -1.02
 event12  POINTER_MOTION    +2.70s        0.00/ -1.69
 event12  POINTER_MOTION    +2.71s        0.00/ -0.68
 event12  POINTER_MOTION    +2.72s        0.00/ -0.68
 event12  POINTER_MOTION    +2.73s        0.00/ -1.02
 event12  POINTER_MOTION    +2.74s        0.00/ -0.68
 event12  POINTER_MOTION    +2.75s        0.00/ -0.67
 event12  POINTER_MOTION    +2.76s        0.00/ -0.65
 event12  POINTER_MOTION    +2.77s        0.00/ -0.97
 event12  POINTER_MOTION    +2.79s        0.00/ -0.62
 event12  POINTER_MOTION    +2.80s        0.00/ -0.59
 event12  POINTER_MOTION    +2.83s        0.00/ -0.56
 event12  POINTER_MOTION    +2.87s        0.00/ -0.51
 event12  POINTER_MOTION    +2.88s        0.00/ -0.73
 event12  POINTER_MOTION    +2.92s        0.00/ -0.47
 event12  POINTER_MOTION    +2.96s        0.00/ -0.43
 event12  POINTER_MOTION    +3.38s        0.00/  0.15
 event12  POINTER_MOTION    +3.40s        0.00/  0.49
 event12  POINTER_MOTION    +3.41s        0.00/  0.46
 event12  POINTER_MOTION    +3.42s        0.00/  0.48
 event12  POINTER_MOTION    +3.43s        0.00/  0.49
 event12  POINTER_MOTION    +3.46s        0.00/  0.70
 event12  POINTER_MOTION    +3.52s        0.00/  0.40
 event12  POINTER_MOTION    +3.56s        0.00/  0.35
 event12  POINTER_MOTION    +3.61s        0.00/  0.34
 event12  POINTER_MOTION    +3.76s        0.00/  0.08
 event12  POINTER_MOTION    +3.85s       -0.14/  0.00
 event12  POINTER_MOTION    +3.87s       -0.40/  0.00
 event12  POINTER_MOTION    +3.87s       -0.58/  0.00
 event12  POINTER_MOTION    +3.88s       -0.59/  0.00
 event12  POINTER_MOTION    +3.89s       -0.59/  0.00
 event12  POINTER_MOTION    +3.90s       -0.59/  0.00
 event12  POINTER_MOTION    +3.91s       -0.59/  0.00
 event12  POINTER_MOTION    +3.93s       -0.56/  0.00
 event12  POINTER_MOTION    +3.94s       -0.54/  0.00
 event12  POINTER_MOTION    +3.95s       -0.55/  0.00
 event12  POINTER_MOTION    +4.41s        0.39/  0.00
 event12  POINTER_MOTION    +4.42s        0.41/  0.00
 event12  POINTER_MOTION    +4.45s        0.50/  0.00
 event12  POINTER_MOTION    +4.46s        0.42/  0.00
 event12  POINTER_MOTION    +4.48s        0.43/  0.00
 event12  POINTER_MOTION    +4.49s        0.44/  0.00
 event12  POINTER_MOTION    +4.52s        0.43/  0.00
 event12  POINTER_MOTION    +4.53s        0.43/  0.00
 event12  POINTER_MOTION    +4.59s        0.41/  0.00
 event12  POINTER_MOTION    +4.61s        0.38/  0.00
 event12  POINTER_MOTION    +4.63s        0.39/  0.00
 event12  POINTER_MOTION    +5.16s        0.00/  0.28
 event12  POINTER_MOTION    +5.17s        0.00/  0.65
 event12  POINTER_MOTION    +5.18s        0.00/  0.63
 event12  POINTER_MOTION    +5.19s        0.00/  0.58
 event12  POINTER_MOTION    +5.20s        0.00/  0.56
 event12  POINTER_MOTION    +5.21s        0.00/  0.86
 event12  POINTER_MOTION    +5.22s        0.00/  0.58
 event12  POINTER_MOTION    +5.23s        0.00/  1.19
 event12  POINTER_MOTION    +5.24s        0.00/  1.59
 event12  POINTER_MOTION    +5.25s        0.00/  1.34
 event12  POINTER_MOTION    +5.26s        0.00/  0.67
 event12  POINTER_MOTION    +5.27s        0.00/  1.00
 event12  POINTER_MOTION    +5.28s        0.00/  1.35
 event12  POINTER_MOTION    +5.29s        0.00/  0.67
 event12  POINTER_MOTION    +5.30s        0.00/  1.69
 event12  POINTER_MOTION    +5.31s        0.00/  1.36
 event12  POINTER_MOTION    +5.32s        0.00/  1.02
 event12  POINTER_MOTION    +5.33s        0.00/  0.68
 event12  POINTER_MOTION    +5.34s        0.00/  0.68
 event12  POINTER_MOTION    +5.35s        0.00/  0.68
 event12  POINTER_MOTION    +5.36s        0.00/  0.68
 event12  POINTER_MOTION    +5.37s        0.00/  1.02
 event12  POINTER_MOTION    +5.38s        0.00/  0.68
 event12  POINTER_MOTION    +5.39s        0.00/  0.66
 event12  POINTER_MOTION    +5.40s        0.00/  0.64
 event12  POINTER_MOTION    +5.41s        0.00/  0.95
 event12  POINTER_MOTION    +5.63s        0.00/ -0.87
 event12  POINTER_MOTION    +5.64s        0.00/ -2.11
 event12  POINTER_MOTION    +5.65s        0.00/ -1.36
 event12  POINTER_MOTION    +5.66s        0.00/ -1.69
 event12  POINTER_MOTION    +5.67s        0.00/ -1.36
 event12  POINTER_MOTION    +5.68s        0.00/ -1.69
 event12  POINTER_MOTION    +5.69s        0.00/ -0.68
 event12  POINTER_MOTION    +5.70s        0.00/ -1.36
 event12  POINTER_MOTION    +5.71s        0.00/ -1.02
 event12  POINTER_MOTION    +5.72s        0.00/ -1.36
 event12  POINTER_MOTION    +5.73s        0.00/ -0.68
 event12  POINTER_MOTION    +5.74s        0.00/ -1.02
 event12  POINTER_MOTION    +5.75s        0.00/ -0.68
 event12  POINTER_MOTION    +5.76s        0.00/ -1.36
 event12  POINTER_MOTION    +5.77s        0.00/ -0.68
 event12  POINTER_MOTION    +5.78s        0.00/ -2.37
 event12  POINTER_MOTION    +5.79s        0.00/ -1.69
 event12  POINTER_MOTION    +5.80s        0.00/ -0.68
 event12  POINTER_MOTION    +5.81s        0.00/ -0.68
 event12  POINTER_MOTION    +5.82s        0.00/ -0.68
 event12  POINTER_MOTION    +5.83s        0.00/ -1.02
 event12  POINTER_MOTION    +5.84s        0.00/ -0.68
 event12  POINTER_MOTION    +5.85s        0.00/ -0.68
 event12  POINTER_MOTION    +5.86s        0.00/ -0.68
 event12  POINTER_MOTION    +5.87s        0.00/ -0.66
 event12  POINTER_MOTION    +5.89s        0.00/ -0.96
 event12  POINTER_MOTION    +6.07s       -0.23/  0.00
 event12  POINTER_MOTION    +6.08s       -0.75/  0.00
 event12  POINTER_MOTION    +6.09s       -0.72/  0.00
 event12  POINTER_MOTION    +6.10s       -0.67/  0.00
 event12  POINTER_MOTION    +6.11s       -0.31/  0.00
 event12  POINTER_MOTION    +6.12s       -0.59/  0.00
 event12  POINTER_MOTION    +6.13s       -0.59/  0.00
 event12  POINTER_MOTION    +6.14s       -0.59/  0.00
 event12  POINTER_MOTION    +6.15s       -0.90/  0.00
 event12  POINTER_MOTION    +6.16s       -0.61/  0.00
 event12  POINTER_MOTION    +6.17s       -0.61/  0.00
 event12  POINTER_MOTION    +6.18s       -0.61/  0.00
 event12  POINTER_MOTION    +6.19s       -0.60/  0.00
 event12  POINTER_MOTION    +6.20s       -0.60/  0.00
 event12  POINTER_MOTION    +6.21s       -0.60/  0.00
 event12  POINTER_MOTION    +6.22s       -0.60/  0.00
 event12  POINTER_MOTION    +6.23s       -0.59/  0.00
 event12  POINTER_MOTION    +6.24s       -0.59/  0.00
 event12  POINTER_MOTION    +6.25s       -0.59/  0.00
 event12  POINTER_MOTION    +6.26s       -0.59/  0.00
 event12  POINTER_MOTION    +6.27s       -0.60/  0.00
 event12  POINTER_MOTION    +6.28s       -0.60/  0.00
 event12  POINTER_MOTION    +6.29s       -0.60/  0.00
 event12  POINTER_MOTION    +6.30s       -0.59/  0.00
 event12  POINTER_MOTION    +6.34s       -0.56/  0.00
 event12  POINTER_MOTION    +6.65s        0.38/  0.00
 event12  POINTER_MOTION    +6.66s        0.42/  0.00
 event12  POINTER_MOTION    +6.67s        0.60/  0.00
 event12  POINTER_MOTION    +6.68s        0.59/  0.00
 event12  POINTER_MOTION    +6.69s        0.59/  0.00
 event12  POINTER_MOTION    +6.70s        0.59/  0.00
 event12  POINTER_MOTION    +6.71s        0.59/  0.00
 event12  POINTER_MOTION    +6.72s        0.59/  0.00
 event12  POINTER_MOTION    +6.73s        0.59/  0.00
 event12  POINTER_MOTION    +6.74s        0.59/  0.00
 event12  POINTER_MOTION    +6.75s        0.90/  0.00
 event12  POINTER_MOTION    +6.76s        0.61/  0.42
 event12  POINTER_MOTION    +6.77s        0.60/  0.14
 event12  POINTER_MOTION    +6.78s        0.60/  0.42
 event12  POINTER_MOTION    +6.79s        0.60/  0.14
 event12  POINTER_MOTION    +6.80s        0.60/  0.00
 event12  POINTER_MOTION    +6.81s        0.60/  0.00
 event12  POINTER_MOTION    +6.82s        0.60/  0.00
 event12  POINTER_MOTION    +6.83s        0.60/  0.00
 event12  POINTER_MOTION    +6.84s        0.60/  0.00
 event12  POINTER_MOTION    +6.85s        0.60/  0.00
 event12  POINTER_MOTION    +6.86s        0.60/  0.00
 event12  POINTER_MOTION    +6.87s        0.60/  0.00
 event12  POINTER_MOTION    +6.88s        0.60/  0.42
 event12  POINTER_MOTION    +6.89s        0.60/  0.14
 event12  POINTER_MOTION    +7.18s       -0.21/  0.00
 event12  POINTER_MOTION    +7.19s       -1.13/  0.00
 event12  POINTER_MOTION    +7.20s       -1.46/  0.00
 event12  POINTER_MOTION    +7.21s       -0.73/  0.00
 event12  POINTER_MOTION    +7.22s       -0.73/  0.00
 event12  POINTER_MOTION    +7.23s       -0.73/  0.00
 event12  POINTER_MOTION    +7.24s       -1.46/  0.00
 event12  POINTER_MOTION    +7.25s       -0.73/  0.00
 event12  POINTER_MOTION    +7.25s       -0.73/  0.00
 event12  POINTER_MOTION    +7.27s       -0.72/  0.00
 event12  POINTER_MOTION    +7.28s       -0.71/  0.00
 event12  POINTER_MOTION    +7.29s       -0.69/  0.00
 event12  POINTER_MOTION    +7.29s       -0.68/  0.00
 event12  POINTER_MOTION    +7.30s       -0.68/  0.00
 event12  POINTER_MOTION    +7.32s       -0.67/  0.00
 event12  POINTER_MOTION    +7.32s       -0.67/  0.00
 event12  POINTER_MOTION    +7.33s       -0.65/  0.00
 event12  POINTER_MOTION    +7.36s       -0.61/  0.00
 event12  POINTER_MOTION    +7.36s       -0.59/  0.00
 event12  POINTER_MOTION    +7.67s        0.00/  0.48
 event12  POINTER_MOTION    +7.68s        0.00/  1.16
 event12  POINTER_MOTION    +7.69s        0.00/  0.68
 event12  POINTER_MOTION    +7.70s        0.00/  0.67
 event12  POINTER_MOTION    +7.71s        0.00/  0.80
 event12  POINTER_MOTION    +7.72s        0.00/  0.63
 event12  POINTER_MOTION    +7.73s        0.00/  0.61
 event12  POINTER_MOTION    +7.74s        0.00/  0.75
 event12  POINTER_MOTION    +7.75s        0.00/  1.57
 event12  POINTER_MOTION    +7.76s        0.00/  1.32
 event12  POINTER_MOTION    +7.77s        0.00/  1.01
 event12  POINTER_MOTION    +7.78s        0.00/  0.67
 event12  POINTER_MOTION    +7.79s        0.00/  0.65
 event12  POINTER_MOTION    +7.80s        0.00/  0.48
 event12  POINTER_MOTION    +7.81s        0.00/  0.63
 event12  POINTER_MOTION    +7.82s        0.00/  0.94
 event12  POINTER_MOTION    +7.83s        0.00/  0.61
 event12  POINTER_MOTION    +7.84s        0.00/  0.60
 event12  POINTER_MOTION    +7.85s        0.00/  0.60
 event12  POINTER_MOTION    +7.86s        0.00/  0.91
 event12  POINTER_MOTION    +7.87s        0.00/  0.61
 event12  POINTER_MOTION    +8.16s        0.00/ -0.73
 event12  POINTER_MOTION    +8.16s        0.00/ -2.26
 event12  POINTER_MOTION    +8.18s        0.00/ -1.36
 event12  POINTER_MOTION    +8.19s        0.00/ -1.69
 event12  POINTER_MOTION    +8.19s        0.00/ -1.36
 event12  POINTER_MOTION    +8.21s        0.00/ -0.68
 event12  POINTER_MOTION    +8.21s        0.00/ -1.69
 event12  POINTER_MOTION    +8.22s        0.00/ -1.36
 event12  POINTER_MOTION    +8.23s        0.00/ -1.69
 event12  POINTER_MOTION    +8.24s        0.00/ -0.68
 event12  POINTER_MOTION    +8.25s        0.00/ -1.36
 event12  POINTER_MOTION    +8.26s        0.00/ -1.02
 event12  POINTER_MOTION    +8.27s        0.00/ -0.68
 event12  POINTER_MOTION    +8.28s        0.00/ -0.68
 event12  POINTER_MOTION    +8.29s        0.00/ -0.68
 event12  POINTER_MOTION    +8.30s        0.00/ -0.68
 event12  POINTER_MOTION    +8.31s        0.00/ -1.02
 event12  POINTER_MOTION    +8.32s        0.00/ -0.68
 event12  POINTER_MOTION    +8.33s        0.00/ -0.68
 event12  POINTER_MOTION    +8.34s        0.00/ -0.66
 event12  POINTER_MOTION    +8.35s        0.00/ -0.98
 event12  POINTER_MOTION    +8.56s        0.00/  0.89
 event12  POINTER_MOTION    +8.57s        0.00/  1.37
 event12  POINTER_MOTION    +8.58s        0.00/  2.20
 event12  POINTER_MOTION    +8.59s        0.00/  1.69
 event12  POINTER_MOTION    +8.60s        0.00/  2.03
 event12  POINTER_MOTION    +8.61s        0.00/  1.52
 event12  POINTER_MOTION    +8.62s        0.00/  1.36
 event12  POINTER_MOTION    +8.63s        0.00/  1.86
 event12  POINTER_MOTION    +8.64s        0.00/  1.36
 event12  POINTER_MOTION    +8.65s        0.00/  1.52
 event12  POINTER_MOTION    +8.66s        0.00/  1.36
 event12  POINTER_MOTION    +8.67s        0.00/  0.68
 event12  POINTER_MOTION    +8.68s        0.00/  1.02
 event12  POINTER_MOTION    +8.69s        0.00/  0.68
 event12  POINTER_MOTION    +8.70s        0.00/  0.68
 event12  POINTER_MOTION    +8.71s        0.00/  0.68
 event12  POINTER_MOTION    +8.72s        0.00/  1.02
 event12  POINTER_MOTION    +8.73s        0.00/  0.68
 event12  POINTER_MOTION    +8.74s        0.00/  0.68
 event12  POINTER_MOTION    +8.95s        0.00/ -0.47
 event12  POINTER_MOTION    +8.96s        0.00/ -0.98
 event12  POINTER_MOTION    +8.97s        0.00/ -1.36
 event12  POINTER_MOTION    +8.98s        0.00/ -1.69
 event12  POINTER_MOTION    +8.99s        0.00/ -1.36
 event12  POINTER_MOTION    +8.99s        0.00/ -1.69
 event12  POINTER_MOTION    +9.01s        0.00/ -2.03
 event12  POINTER_MOTION    +9.02s        0.00/ -2.37
 event12  POINTER_MOTION    +9.03s        0.00/ -1.69
 event12  POINTER_MOTION    +9.04s        0.00/ -1.36
 event12  POINTER_MOTION    +9.04s        0.00/ -1.69
 event12  POINTER_MOTION    +9.05s        0.00/ -0.68
 event12  POINTER_MOTION    +9.06s        0.00/ -0.68
 event12  POINTER_MOTION    +9.07s        0.00/ -0.68
 event12  POINTER_MOTION    +9.09s        0.00/ -0.68
 event12  POINTER_MOTION    +9.09s        0.00/ -1.02
 event12  POINTER_MOTION    +9.10s        0.00/ -0.68
 event12  POINTER_MOTION    +9.11s        0.00/ -0.68
 event12  POINTER_MOTION    +9.12s        0.00/ -0.68
 event12  POINTER_MOTION    +9.37s        0.00/  0.72
 event12  POINTER_MOTION    +9.38s        0.00/  1.43
 event12  POINTER_MOTION    +9.39s        0.00/  1.36
 event12  POINTER_MOTION    +9.40s        0.00/  1.69
 event12  POINTER_MOTION    +9.41s        0.00/  1.36
 event12  POINTER_MOTION    +9.42s        0.00/  0.68
 event12  POINTER_MOTION    +9.43s        0.00/  1.69
 event12  POINTER_MOTION    +9.44s        0.00/  1.36
 event12  POINTER_MOTION    +9.45s        0.00/  1.02
 event12  POINTER_MOTION    +9.46s        0.00/  0.68
 event12  POINTER_MOTION    +9.47s        0.00/  0.68
 event12  POINTER_MOTION    +9.48s        0.00/  0.68
 event12  POINTER_MOTION    +9.50s        0.00/  1.02
 event12  POINTER_MOTION    +9.51s        0.00/  0.68
 event12  POINTER_MOTION    +9.58s        0.00/  0.15
 event12  POINTER_MOTION    +9.80s       -0.40/  0.00
 event12  POINTER_MOTION    +9.83s       -0.29/  0.00
 event12  POINTER_MOTION    +9.85s       -0.35/  0.00
 event12  POINTER_MOTION    +9.89s       -0.17/  0.00
 event12  POINTER_MOTION    +9.89s       -0.33/  0.00
 event12  POINTER_MOTION    +9.92s       -0.17/  0.00
 event12  POINTER_MOTION    +9.96s        0.00/ -0.30
 event12  POINTER_MOTION    +9.97s        0.00/ -0.31
 event12  POINTER_MOTION    +9.98s        0.00/ -0.35
 event12  POINTER_MOTION    +9.99s        0.00/ -0.37
 event12  POINTER_MOTION   +10.01s        0.00/ -0.66
 event12  POINTER_MOTION   +10.03s        0.00/ -0.47
 event12  POINTER_MOTION   +10.10s        0.00/ -0.10
 event12  POINTER_MOTION   +10.15s        0.00/ -0.24
 event12  POINTER_MOTION   +10.16s        0.00/ -0.32
 event12  POINTER_MOTION   +10.17s        0.00/ -0.50
 event12  POINTER_MOTION   +10.18s        0.00/ -0.34
 event12  POINTER_MOTION   +10.19s        0.00/ -0.09
 event12  POINTER_MOTION   +10.20s        0.00/ -0.35
 event12  POINTER_MOTION   +10.22s        0.00/ -0.26
 event12  POINTER_MOTION   +10.23s        0.38/ -0.09
 event12  POINTER_MOTION   +10.24s        0.48/  0.00
 event12  POINTER_MOTION   +10.25s        0.58/  0.00
 event12  POINTER_MOTION   +10.26s        0.58/  0.00
 event12  POINTER_MOTION   +10.27s        0.58/  0.00
 event12  POINTER_MOTION   +10.28s        1.24/  0.00
 event12  POINTER_MOTION   +10.29s        0.65/  0.00
 event12  POINTER_MOTION   +10.30s        0.64/  0.00
 event12  POINTER_MOTION   +10.31s        0.63/  0.00
 event12  POINTER_MOTION   +10.32s        0.63/  0.00
 event12  POINTER_MOTION   +10.33s        0.62/  0.00
 event12  POINTER_MOTION   +10.34s        0.62/  0.00
 event12  POINTER_MOTION   +10.35s        0.62/  0.00
 event12  POINTER_MOTION   +10.36s        0.62/  0.00
 event12  POINTER_MOTION   +10.37s        0.61/  0.00
 event12  POINTER_MOTION   +10.38s        0.61/  0.00
 event12  POINTER_MOTION   +10.66s        0.00/  0.29
 event12  POINTER_MOTION   +10.67s        0.00/  0.25
 event12  POINTER_MOTION   +10.68s        0.00/  0.10
 event12  POINTER_MOTION   +10.69s        0.00/  0.50
 event12  POINTER_MOTION   +10.70s        0.00/  0.11
button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event12: touch movement 19.5mm, pixels 243.4, raw px 768.9, avg factor 0.3

It says the pointer moved 19,5 mm, but the finger has been fixed in the same point all the time.

(In reply to Giuseppe Margarita from comment #24)
> I'm playing with the event-debug and noticed an odd thing.
> If I stick the finger in any point and don't slide it, but move it up and
> down/left and right remaining always in the same point, the pointer moves
> roughly 4-5 mm.

so you're not moving the pointer but effectively roling the finger around?
If so, some pointer movement is expected because what the touchpad detects
as the center of your finger moves around. The exact amount of pointer
movement obviously changes as you move but this seems about alright. If I do
the same here I can pretty much position the pointer on any pixel I want.

> button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to
> BUTTON_STATE_AREA
> -event12  POINTER_MOTION    +1.92s        0.00/  0.16

please don't post these directly, add them as attachment. It gets hard
keeping a grasp on the bug when the relevant information requires scrolling
by a kilometer.

(In reply to Peter Hutterer from comment #25)
> (In reply to Giuseppe Margarita from comment #24)
> > I'm playing with the event-debug and noticed an odd thing.
> > If I stick the finger in any point and don't slide it, but move it up and
> > down/left and right remaining always in the same point, the pointer moves
> > roughly 4-5 mm.
> 
> so you're not moving the pointer but effectively roling the finger around?
> If so, some pointer movement is expected because what the touchpad detects
> as the center of your finger moves around. The exact amount of pointer
> movement obviously changes as you move but this seems about alright. If I do
> the same here I can pretty much position the pointer on any pixel I want.
No, the pointer is moving and I'm rolling the finger. But the finger is not sliding on the touchpad, so I expect that the pointer moves less than it does. 
I say this because I remember that the pointer moved less with synaptics in this case. I felt it more precise on the target. 

> please don't post these directly, add them as attachment. It gets hard
> keeping a grasp on the bug when the relevant information requires scrolling
> by a kilometer.
Okay.

Try this one please: https://github.com/whot/libinput/tree/wip/touchpad-pointer-accel-v4

Yes! I feel it more accurate. Thank you!
What did you do?
In long movements it's quicker, seems it has an additional acceleration factor. But in short movements it is slower, so more accurate.
I like it! Fast with long movements and slower with shorts one.  
Can it be the default behavior for upstream package on Arch Linux?

a couple of things, but reducing the base speed is the main feature. Still waiting on more testers' feedback. thanks for testing though.

regarding Arch: i suspect they'll take it once libinput 1.7 is released which is what I'm aiming for given enough positive test results.

(In reply to Peter Hutterer from comment #29)
> a couple of things, but reducing the base speed is the main feature. Still
> waiting on more testers' feedback. thanks for testing though.
Well, I tried with other acceleration values.
Above 0 is unusable, too sensitive and too fast.
0 is quite unusable. 
-0.2 is usable and below is usable but slower.

I changed the acceleration speed to -0.2 in the startup script.

> regarding Arch: i suspect they'll take it once libinput 1.7 is released
> which is what I'm aiming for given enough positive test results.
Okay, I blacklisted libinput package and will upgrade it when 1.7 come out.

fwiw, the range comes with double precision, so -0.23801 would be a valid setting if you find that e.g -0.2 is close but -0.3 is too slow.

(In reply to Peter Hutterer from comment #31)
> fwiw, the range comes with double precision, so -0.23801 would be a valid
> setting if you find that e.g -0.2 is close but -0.3 is too slow.

I knew, tried also values like -0,25 and -0,35.

1.7 is out on ArchLinux and libinput works fine. This bug can be closed.
Thank you.

interesting... 1.7 didn't end up with any pointer acceleration specific patches.

(In reply to Peter Hutterer from comment #34)
> interesting... 1.7 didn't end up with any pointer acceleration specific
> patches.

I tried it for a couple of minutes and seems it had the same behavior.

the same behaviour as what? 1.6. and 1.7 should be identical, but this bug was filed against 1.6. so you either got used to the 1.6 behaviour or something else is going on.

(In reply to Peter Hutterer from comment #36)
> the same behaviour as what? 1.6. and 1.7 should be identical, but this bug
> was filed against 1.6. so you either got used to the 1.6 behaviour or
> something else is going on.

The same behavior of the version you got me to install. 
Anyway, I see now that shorts movements are less accurate. Didn't notice it because I did only few minutes of test before shut down the system. 
When will the new acceleration profile be introduced? 

I'll try to use upstream version, it doesn't seem very bad for now. If I'll see some bad behavior, I'll recompile the version with the different acceleration profile.

Closing this because it's over a year old now, we've added new touchpad acceleration code and if it's still broken you should probably join in Bug 101139 instead.