Bug 90652

f22 uses libinput as default backend, so there are a couple of differences.

Kinetic scrolling is something that has gone the way of the dodo, this should've never been in the driver to begin with and we're now relying on the toolkit to implement that where it makes sense.

As for the touchpad feeling less smooth I'll need some more information please - is it too slow, too fast, what if you change the acceleration speed etc?

Ah, gotcha. So I should be looking talking to the GTK+ folks about this then, I assume.

As for pointer smoothness, I think this might be hard to pin down. After the upgrade, the pointer was faster than it was before. I turned down the speed in GNOME prefs, but the movement/acceleration characteristics continued to feel different, which is when I posted this bug. About a day later, I seem to have gotten used to the new feel.

I do have one other problem, though: I usually double-tap-and-hold to select, and I've noticed that the hold does not release as soon as I take my finger off the trackpad, but takes almost a second, which seems unnatural to me (I move a window, then move my cursor elsewhere, and the window comes along). Is this expected/configurable?

there's definitely a difference in pointer acceleration, we know about that (it's faster on most touchpads). The question is whether it's unusable, so far everyone got used to it quite quickly :)

that doesn't mean we don't want to address any real issues (e.g. the x230 has a custom accel method because of the broken touchpad). so if you think there are continuous accel issues, we can see how we can work those out.

(In reply to Arun Raghavan from comment #2)
> I do have one other problem, though: I usually double-tap-and-hold to
> select, and I've noticed that the hold does not release as soon as I take my
> finger off the trackpad, but takes almost a second, which seems unnatural to
> me (I move a window, then move my cursor elsewhere, and the window comes
> along). Is this expected/configurable?

yeah, the reason is the multi-drag feature (or whatever you want to call it). you can lift the finger and set it back down during a drag process to keep dragging across more than one touchpad width. that requires a timeout though which is what you're seeing. The easiest way to avoid the timeout is to tap again to release (Bug 90255) which is only on git master at this point though.

(In reply to Peter Hutterer from comment #3)
> there's definitely a difference in pointer acceleration, we know about that
> (it's faster on most touchpads). The question is whether it's unusable, so
> far everyone got used to it quite quickly :)
> 
> that doesn't mean we don't want to address any real issues (e.g. the x230
> has a custom accel method because of the broken touchpad). so if you think
> there are continuous accel issues, we can see how we can work those out.

I'll keep an eye on this and reopen the bug if it feels like usability has deteriorated.

> (In reply to Arun Raghavan from comment #2)
> > I do have one other problem, though: I usually double-tap-and-hold to
> > select, and I've noticed that the hold does not release as soon as I take my
> > finger off the trackpad, but takes almost a second, which seems unnatural to
> > me (I move a window, then move my cursor elsewhere, and the window comes
> > along). Is this expected/configurable?
> 
> yeah, the reason is the multi-drag feature (or whatever you want to call
> it). you can lift the finger and set it back down during a drag process to
> keep dragging across more than one touchpad width. that requires a timeout
> though which is what you're seeing. The easiest way to avoid the timeout is
> to tap again to release (Bug 90255) which is only on git master at this
> point though.

That sounds reasonable. I'll wait for the release with that and report back if there's still a problem.

I don't know where in the stack this responsibility could possibly belong, but it'd be nice to have a way to let users know about these sorts of changes (being able to lift your finger in between a move is a feature people would appreciate, I'm sure).

(In reply to Arun Raghavan from comment #4)
> I don't know where in the stack this responsibility could possibly belong,
> but it'd be nice to have a way to let users know about these sorts of
> changes (being able to lift your finger in between a move is a feature
> people would appreciate, I'm sure).

bit difficult, tbh. I try to add things like that in the release notes and blog about it (I have an post pending for exactly that feature, just waiting for 0.16 to be ready). And they're documented (http://wayland.freedesktop.org/libinput/doc/latest/tapping.html). It's not possible for anyone else in the stack to expose these, those features aren't directly exposed. e.g. you can enable/disable tapping, but tap-to-end-drag is built-in, you don't get to decide on it.

If you want to bulk up the libinput documentation be my guest, I always welcome documentation patches.

(In reply to Peter Hutterer from comment #5)
> bit difficult, tbh. I try to add things like that in the release notes and
> blog about it (I have an post pending for exactly that feature, just waiting
> for 0.16 to be ready). And they're documented
> (http://wayland.freedesktop.org/libinput/doc/latest/tapping.html). It's not
> possible for anyone else in the stack to expose these, those features aren't
> directly exposed. e.g. you can enable/disable tapping, but tap-to-end-drag
> is built-in, you don't get to decide on it.
> 
> If you want to bulk up the libinput documentation be my guest, I always
> welcome documentation patches.

I didn't meant to imply this belongs to libinput. With a one-time downstream hat, and current user hat, I definitely appreciate the changelogs and blog posts.

From the point of view of non-technical users, I was wondering how these things can be communicated. I think the responsibility will have to lie with distributions or with GNOME/KDE/..., as they are the closest to the user, and control when/which version of libinput is deployed.

oh, I'm quite convinced that the documentation does belong in libinput, after all we are the only ones who know the exact details of what's happening (some of which is even model-specific). and it provides a convenient link to give to anyone asking. Alas, users don't generally read documentation, so blog posts have the widest reach at this point.
That link I posted is supposed to be the non-technical documentation, i.e. the "here's how it works" as opposed to the rest which is just API documentation.