Bug 101140

In https://bugs.freedesktop.org/show_bug.cgi?id=99000 you said the following on subject of an exposed acceleration setting:

"well, basically: if we don't need it, we don't need to add it. options that aren't actually used are a real drag on maintenance, especially options that are generic enough that users may use them for unrelated things (see the xkcd workflow comic)."

I think the quantity of acceleration complaints reveals a genuine need. You said the following in https://bugs.freedesktop.org/show_bug.cgi?id=98535:

"Reopening, because we still get complaints"

Again, it seems unlikely to me that a single default value will ever be sufficient to meet the needs of the *NIX community, which is diverse in both attitudes and hardware. Apple gets away with it not only because their default value truly is "good enough", but also because they have total control over the touchpad hardware and can ensure that their default value behaves as expected 100% of the time. We don't have that luxury.

Sorry, still closing this as WONTFIX, for a couple of reasons:

* the reason this still isn't better is ETIME on my side (and lack of hardware that's affected by this). [1]
* Apple gets away with it because it's good enough - and this is the point, isn't it? We have a lot of device-specific code, there's not point having config options that everyone has to tweak individually when we can just make it good enough on whole categories or model series at a time
* "acceleration" has very little meaning - what exact factor do you want to expose?
* once we expose that factor, we're locked into the *algorithm*, because for any change now we have to figure out how not to break that configuration

So right now, adding that config option has only downsides for the long-term maintenance efforts.


[1] I pretty much only hear calls for "give me a config option" (which really means: "a magic number that works for me on my hardware") , but apparently it's not bad enough for anyone to spend time investigating the cause and finding a proper solution. Most of the time when I provide branches to test, I get crickets and tumbleweeds, so my motivation in general is a tad low to work on this. And my motivation to expose a config option just to get abused whenever it changes in the future is zero.

"Ehh, good enough for me" doesn't strike me as the best response for a project that aims for 100% adoption across all Linux hardware. We don't all use Thinkpads.

I understand how exposing a specific setting limits your ability to change the algorithm the future. But libinput's mouse module exposes a set of different acceleration profiles, rather than a slider value or something. What's wrong with doing the same type of thing for touchpads?

Not sure where you get the thinkpad part from. They get the most testing because I have access to them, if I have no access to others *and* I get little contribution from others it's hard to improve them. My point was that apparently Apple gets something that's good enough for their hardware, there's no real reason we can't do the same given that we know about the different hardware in libinput and can adjust it as needed (we already have a special acceleration for the x230 for example).

mouse acceleration has a speed setting and a profile that merely forwards the input as-is. That's not usable on touchpads, so we don't export it. If someone comes up with a new acceleration profile that works better for touchpads we can talk about it, but chances are it'll be better for all touchpads, so we can just change the current one to this new code.

I've seen the light regarding your perspective on new options after seeing how masterfully you solved the hysteresis issue. We can fix this in other ways.