input: add pointer sensitivity multiplier

[ZiedYousfi]

Summary

• Add a per-device sensitivity input setting for mouse, touchpad, trackpoint, and trackball sections.
• Apply the setting as a compositor-side multiplier to libinput's accelerated pointer delta, preserving the configured acceleration profile and speed curve.
• Keep accel-speed constrained to libinput's supported [-1, 1] range while offering a way to exceed libinput's practical movement speed limit.

Motivation

Libinput clamps pointer acceleration speed to [-1, 1], which can still be too slow for some setups. A compositor-side sensitivity multiplier works around that limitation without changing libinput acceleration semantics.

This is also useful for accessibility and ergonomics. As a concrete personal example, I need higher pointer movement on larger screens where libinput's maximum speed is not enough.

Documentation

• Added commented examples to resources/default-config.kdl.
• This adds a new config option, so the wiki should be updated before/alongside merge.

[YaLTeR]

..maybe this should be a PR into libinput instead then?

[ZiedYousfi]

..maybe this should be a PR into libinput instead then?

Yeah I get the idea, but I don’t think this could go into libinput.

libinput has its own reasons for keeping the accel range in [-1, 1], and that’s tightly tied to hardware behavior and how the accel curve is tuned. Extending that range would kind of go outside what it was designed for.

What I’m doing here is different: it doesn’t touch libinput at all. It just applies a simple multiplier on the final delta on the compositor side.

So:

• default behavior stays exactly the same
• if you don’t enable the option, nothing changes for anyone
• libinput accel and curves are untouched

It just gives an extra bit of flexibility for setups where the max speed isn’t enough, without affecting existing users.

[YaLTeR]

I mean, your problem seems to be between your mouse and libinput. Adding a niri setting is just adding a downstream workaround. What if you switch to another compositor? You'll need to add the same setting.

Btw nowadays you can also write yourself a libinput plugin, might be possible to do what you want through that.

[ZiedYousfi]

I mean, in theory sure, but in practice it’s not really that simple.

Not all mice let you change DPI in a consistent way on Linux, and there isn’t exactly a universal tool that works across setups. And even then, changing DPI isn’t the same as adjusting pointer sensitivity, it just shifts the problem somewhere else.

In my case I also dual-boot with Windows, so I’m trying to keep a consistent pointer feel. Right now, with libinput alone, even at max settings, that’s just not possible.

Also, I wouldn’t really call this a “downstream workaround”. There isn’t any standard for this in Wayland, so it’s not like I’m bypassing something defined elsewhere. It’s just adding a small, optional feature at the compositor level.

If needed, I’m fine adding similar support in other compositors as well. I don’t think libinput itself should change for this.

And since the default is effectively a no-op, it doesn’t really change anything for anyone unless they explicitly need it.

[YaLTeR]

Still, look into libinput plugins, if you can do what you need with them it'll work all across Linux: https://wayland.freedesktop.org/libinput/doc/latest/lua-plugins.html

[Atan-D-RP4]

I'd like to chime in to say that I do something similar in my implementation of compositor zoom here #3246.

I downscale the pointer deltas by the current zoom factor/level so that pointer movement between zoomed and unzoomed contents matches, i.e, the same output distances is covered.

So there is already some need for the compositor to apply some scaling to pointer motion.

[YaLTeR]

In your case, sensitivity is needed in a specific case for a niri feature. Here it's more of a "this mouse is way too slow in general" problem.