Bug 1227182

can you run xinput list-props on the device please?

looks like a fairly simple problem: libinput's behaviour is that if a device defaults to button scrolling, the default button is the middle button. On all other devices where button scrolling is available but disabled by default the button is unset by default.

so to enable button scrolling you need to enable the method _and_ set the button you want to trigger the scroll method. if you run xinput set-prop <device name> "libinput Button Scrolling Button" 2, this should enable the middle button and make it work.

though I guess having this as 0 is a bit pointless, I'll get this fixed upstream.

libinput-0.16.0-4.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libinput-0.16.0-4.fc22

Here is the xinput list-props output:
Device 'Lenovo ThinkPad Compact USB Keyboard with TrackPoint':
	Device Enabled (149):	1
	Coordinate Transformation Matrix (151):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	libinput Accel Speed (281):	0.000000
	libinput Accel Speed Default (282):	0.000000
	libinput Natural Scrolling Enabled (283):	0
	libinput Natural Scrolling Enabled Default (284):	0
	libinput Send Events Modes Available (266):	1, 0
	libinput Send Events Mode Enabled (267):	0, 0
	libinput Send Events Mode Enabled Default (268):	0, 0
	libinput Left Handed Enabled (285):	0
	libinput Left Handed Enabled Default (286):	0
	libinput Scroll Methods Available (287):	0, 0, 1
	libinput Scroll Method Enabled (288):	0, 0, 0
	libinput Middle Emulation Enabled (289):	0
	libinput Middle Emulation Enabled Default (290):	0
	Device Node (269):	"/dev/input/event4"
	Device Product ID (270):	6127, 24647

Meanwhile I was a bit unclear on what was meant about enabling the middle button, etc. The trouble is not that middle-click scrolling doesn't work, it's just that the computer always insists on pasting as soon as the middle button is hit rather than after the button is released within the appropriate timeout.

oh, you need to update xorg-x11-drv-libinput to 0.10.0-5, the property was missing before then thanks to a bug. so I can't actually see if that was the problem, sorry.

(In reply to Alex Richert from comment #4)
> Meanwhile I was a bit unclear on what was meant about enabling the middle
> button, etc. The trouble is not that middle-click scrolling doesn't work,
> it's just that the computer always insists on pasting as soon as the middle
> button is hit rather than after the button is released within the
> appropriate timeout.

wait, it's pasting _and_ middle button scrolling works? in the tests here I didn't see the middle button scrolling activate at all.

what libinput does: you have two toggles, one is the scroll method and one is the scroll button. if you change the scroll method to button-scrolling, libinput will attempt scrolling once the selected button is pressed. But that button defaulted to 0 on your device (i.e. disabled), so despite the scroll method being selected, you couldn't activate it.
Once the button is set to a real button (the fix in -4) it can now activate.

If the button is unset, the press event will just be delivered to the client when it happens. Note that the actual paste functionality is a client-side thing, libinput doesn't control it. So if a client decides to paste on button press there's nothing we can do about this in libinput. and indeed this appears to be the default behaviour in X.

The latest version on F22 (as far as I can tell) is 0.10.0-2, and the latest on rawhide is -3, but I'll keep my eye out for the update.

Meanwhile, if the paste-on-press behavior is an issue with X11, any idea why the middle click pasting was working with evdev in F21 but not with libinput? Maybe X11 has also changed..?

https://admin.fedoraproject.org/updates/FEDORA-2015-9310/xorg-x11-drv-libinput-0.10.0-5.fc22,xorg-x11-server-1.17.1-14.fc22
is the latest one for f22, should be in stable any minute now

what happens is:
without middle button scrolling enabled/triggered the middle button press is simply sent on immediately and causes a paste event.

when scrolling is enabled, the press is held back and only send on when you release within the timeout. To you this appears as if the paste happens on release but it still happens on the press event in the client - the press event was just delayed.

In your case the problem is that you don't have scrolling enabled. Run 
xinput set-prop <device name> "libinput Scroll Method Enabled" 0 0 1

after updating to libinput-0.16.0-4.fc22. that enables MB scrolling on the device. Once you have the kernel patches from bug 1225563 installed this should be enabled automatically.

Awesome! It works now that I upgraded to 0.10.0-5 (in updates-testing), though I had to run one additional command (order doesn't matter):

    xinput set-prop <device name> "libinput Scroll Method Enabled" 0 0 1
    xinput set-prop <device name> "libinput Button Scrolling Button" 2

libinput-0.17.0-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libinput-0.17.0-1.fc22

Package libinput-0.17.0-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libinput-0.17.0-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-9555/libinput-0.17.0-1.fc22
then log in and leave karma (feedback).

libinput-0.17.0-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.