Pls file this bug at https://gitlab.freedesktop.org/libinput/libinput/issues, libinput has moved to gitlab and this is the xorg driver component, it doesn't modify the events so it cannot fix this issue.

The one thing I noticed though

  libinput Accel Speed (287):	0.000000

you're still on the default acceleration value. This one has a value in the -1 ... +1 range, you should try whether any of them work better.

Thanks for your hint to modify Acceleration Speed, I could set it with xinput:

xinput --set-prop 10 287 -0.7

results in a similar speed as with evdev without any tuning. So at least I found a way to make my trackball usable with libinput. You see how significant the change in behavior compared to evdev is! A good indicator is to check how the pointer performs in a x-term:
if you are able to cover the whole window with one stroke (which rotates the ball roughly by 1 inch), and at the same time are able to select/mark text with the precision of 1 letter at the same settings, you have a good compromise.

What I am now missing for fine tuning is some kind of acceleration/deceleration to allow even better precision (I now use a mouse for such cases).

Unfortunately the naming of the parameters is a bit misleading, so understanding functionality is not self-explaining. Example:

acceleration = speed(change)/time [m/s²]
speed = distance/time [m/s]

what does "acceleration speed" mean?

In fact to have a clear understanding and to avoid confusion I would suggest to have 3 values for tuning/adjusting:

1. minimum speed (for highest precision)
2. maximum speed (for accelerated moves)
3. transition profile for a smooth changeover (within a given number of pixels)

With the current settings as described above I did not find any way to influence the speed I have set, not with deconf-editor, not with xinput.

I do not know if this can be realized with the currently offered tuning knobs of libinput, but in general the same applies to mice. As those settings should be possible on a per user basis - isn't it a task for xorg as well?

One thing however seems clear: a trackball needs different settings/profile compared to mice.

Best regards

(In reply to alf.debianfan from comment #2)
> Thanks for your hint to modify Acceleration Speed, I could set it with
> xinput:
> 
> xinput --set-prop 10 287 -0.7

fwiw, http://who-t.blogspot.com/2016/07/xinput-resolves-device-names-and.html

but a -0.7 setting is "unusual" and usually requires a libinput fix.

[..]

> what does "acceleration speed" mean?

It's a magic variable between "slowest" and "fastest" that we can then treat in code depending on the device. see the documentation for libinput itself and its pointer accel documentation
https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html

> 
> In fact to have a clear understanding and to avoid confusion I would suggest
> to have 3 values for tuning/adjusting:
> 
> 1. minimum speed (for highest precision)
> 2. maximum speed (for accelerated moves)
> 3. transition profile for a smooth changeover (within a given number of
> pixels)

Start here:
https://who-t.blogspot.com/2018/05/x-server-pointer-acceleration-analysis-part1.html

It's a 5 part series.
 
> With the current settings as described above I did not find any way to
> influence the speed I have set, not with deconf-editor, not with xinput.

libinput only has the single knob, no other configurations. everything else is internal implementation only.

> I do not know if this can be realized with the currently offered tuning
> knobs of libinput, but in general the same applies to mice. As those
> settings should be possible on a per user basis - isn't it a task for xorg
> as well?

not really. with the libinput driver, everything is now done in libinput so we can have the same behaviour across xorg and the wayland compositors. X doesn't touch the pointer data with libinput.

the xorg libinput driver exposes those settings on a *per device* basis. That's the only granularity you'll get and it's the same that all other xorg drivers do. per-user is on a higher level and would have to be managed by the desktop environment (all the big ones do this)
 
> One thing however seems clear: a trackball needs different settings/profile
> compared to mice.

maybe. that would have to be tracked in libinput's issue tracking but given that I never receive useful feedback on any pointer acceleration patches but plenty of abuse later, you'll have to come up with an implementation yourself.\

I also cannot test every single piece of hardware out there, so things that work just fine for one device can be broken for another. libinput has all the hooks in place to get this fixed, it just needs people to care enough to actually fix it. So far, this has rarely happened.

Many thanks for your explanations and background information, Peter.

With my limited knowledsge I am afraid I cannot supply any valuable input/contribution to libinput - so I have to manage with dirty hacks.

I did play a bit further with the single knob "Accel Speed (287):" and found that -0.8 or even -0.9 is even better. At least it's a possibility to get it work with libinput.

From my understanding a similar effect could be achieved by cheating the dpi or polling frequency of the device. I did try to set different values in
/lib/udev/hwdb.d/70-mouse.hwdb for
MOUSE_DPI=540@125

Changing those by factors of 2 and above does not result in any different beheavior - don't understand that, hardware data base seems to be ignorend?

Is there any such variable elsewhere to which I can apply such a correction?

Best regards

MOUSE_DPI should be read for trackballs. Otherwise, there are no other settings you can toggle to get the behaviour, libinput intentionally keeps the ability to apply random settings to a minimum to have defined behaviour across the board.

Either way, gitlab please to continue.

Peter, I finally found a very simple solution for my trackball!

> MOUSE_DPI should be read for trackballs. Otherwise, there are no other settings you can toggle to get the behaviour

Studying the documentation yo linket some posts above I learned that libinput does not recognize the udev-parameter "ID_INPUT_TRACKBALL=1" in hwdb and therefor does not respect any tuning via DPI-spoofing. Setting it to "ID_INPUT_MOUSE=1" instead lets me tune unaccelerated speed to my preferences.

Created a "corrected" hwdb enty for the M570 like:

created /etc/udev/hwdb.d/71-mouse-local.hwdb

# Logitech Wireless Trackball M570
mouse:usb:v046dp1028:name:Logitech M570:
mouse:usb:v046dpc52b:name:Logitech Unifying Device. Wireless PID:1028:
# Cheating hwdb to make the trackball compatible with libinput
#
# Declaring it as a MOUSE instead of TRACKBALL causes libinput to
# respect the DPI-settings in the hardware database,
# Faking DPI to a 1000 causes pointer to slow down to a comfortable speed
# with reasonable precision for placement.
# Setting "Accel Speed (287)" to -0.4 to -0.6  with xinput still
# provides a moderate and comfortable acceleration for longer moves.
# This can be done on a per user basis in ~/.xsessionrc
# MOUSE_DPI=540@125
# ID_INPUT_TRACKBALL=1
 MOUSE_DPI=1000@125
 ID_INPUT_MOUSE=1

There is no further fine tuning necessary, it's at least as good as with evdev.

The only thing which would make sense is to convince libinput team to allow for and recognize "ID_INPUT_TRACKBALL=1" and treat it the same way as mice. Without that the trackball is handled like some "default input device?" and makes it unusable.

Spoofing DPI is a personal fine tuning, and if you only apply none or light acceleration, the trackball will at least be usable.

So, in fact we have 2 tuning parameters:
a) base speed (unaccelerated) via DPI
b) acceleration via "Accel Speed (287)"

Best regards and thanks for your support,
Ingo

Filed the issue at gitlab:

https://gitlab.freedesktop.org/libinput/libinput/issues/91

Please comment if something is missing,
Ingo