Best way to achieve very slow pointer motion? (for accessibility)

[Colomban Wendling]

Le 28/11/2018 à 02:15, Peter Hutterer a écrit :
> On Tue, Nov 27, 2018 at 11:25:05AM +0100, Colomban Wendling wrote:
>> […]
>> * Use the "flat" acceleration profile for slow mode
>>   - This works fairly well and allows for very low pointer speeds.
>>   - The main question is: is there a sensible way to know the rough
>> equivalence point between the "adaptive" and "flat" profiles, so it
>> could be switched automatically on low value of a single "pointer speed"
>> setting?  The idea is that we'd like to have a setting as simple as
>> possible yet providing sensible results for typical use cases.  Ideally,
>> we'd have single slider controlling pointer speed that would just do the
>> Right Thing.
> 
> There's no equivalence point as such, both are implementation-defined and
> can be device-specific. You could figure it quite easily out using the
> libinput sources, but it's bound to change at any time.

That's what I though, having seen the acceleration functions graphs.

> fwiw, the matrix is handled by the server, it's not driver-specific. And
> yes, it will likely conflict with some rotation but that's still a fairly
> niche use-case. And afaik very few relative devices use the matrix anyway
> and for your use-case touchscreens don't matter.

But as you say below, that would clearly be abusing a feature, and a
tricky at that even.

>> Are there other, more appropriate options?
>> Basically, what I'd like to achieve is similar to being able to set the
>> "Accel Speed" to a value way under -1.  If there are no better options,
>> I can consider adding a "enable pointer acceleration" user setting which
>> would control whether the "adaptive" or "flat" profile is used, but I'd
>> like to avoid it if possible to keep the user setting simple and
>> understandable.
> 
> Honestly, I think you're going about it the wrong way. You want an
> accessibility feature and you're looking for hacks and knobs that you can
> (ab)use to get the result you want.
> 
> The side-effect of this is that you make life miserable for both sides. Any
> change in libinput could break whatever knobs you find and you're forcing
> libinput to maintain behaviour that wasn't intended to work this way,
> possibly blocking improvements.

That's the reason I'm asking: because I don't feel great about the
current options I found.

> You should be looking at it this way: how do I get this *feature* into the
> compositor. libinput's purpose is to abstract the hardware but there are
> several things it leaves to the compositor and the toolkits. This would be
> one of them. Pointer slowdown can easily be handled by the compositor since
> it already controls the pointer position (libinput merely provides
> suggested relative deltas). Figure out what other features you'd need and
> how to integrate them. And *integrate* them.

Ok yeah that makes sense, which was more or less the intent of my second
proposition of modifying libinput.  But I indeed slightly misunderstood
the Accel Speed setting, and kind of what is or isn't libinput's to handle.
Now I read your post, I have to agree that something at a higher level
than libinput can do what I need, and then just might be a better place
for it.

Unfortunately, due to the current state of things, I cannot reasonably
expect to be able to rely on Wayland soon; there is work going on to get
MATE to work with it, but it's definitely not gonna be in any kind of
usable state soon.  So I would need a solution working under X -- but if
this isn't a generic solution, ultimately I'd need a Wayland solution as
well.

> PS: yes, obviously this is dependend on Wayland because in X the server
> controls the pointer and you're mostly out of luck.

Well, this "only" suggests I would need a way to do that with X in the
meantime.  What about a multiplication factor in xf86-input-libinput?
Older/other input drivers used to provide things like "Device Accel
Constant Deceleration"/"Device Accel Adaptive Deceleration", and
although I'm not really sure what they technically do, they provide
something that works for the use-case at hand -- but yeah, I might be
abusing something again.

Would such a parameter be acceptable for X, or could you point me to a
better place for this if not?

Thank you,
Colomban