path: root/doc
diff options
authorPeter Hutterer <>2015-06-26 09:07:24 +1000
committerPeter Hutterer <>2015-07-02 13:03:43 +1000
commitc06d825c53b9d1c56b4e5aa09f39d7af4e9b444e (patch)
tree1c7f69be0a41d4a1918964543c8f5a6e13df560b /doc
parent6ea69c2b3d18ea3994a9577e52060e992d46cc70 (diff)
Drop motion normalization of unaccelerated deltas
This simply doesn't work for low-dpi mice. Normalizing a 400dpi mouse to a 1000dpi mouse forces a minimum movement of 2.5 units and the resulting pixel jumps. It is impossible for the caller to detect whether the jump was caused by a single motion or multiple motion events. This is technically an API break, but not really. The accelerated data was already relatively meaningless, even if normalized as the data did not correspond predictably to any input motion (unless you know the implementation acceleration function in the caller). So we can drop the mention from there without expecting any ill effects in the caller. The unaccelerated data was useless for low-dpi mice and could only be used to measure the physical distance of the mouse movement - something not used in any caller we're aware of (if needed, we can add that functionality as a separate call). Dropping motion normalization for unaccelerated deltas also restores true dpi capabilities to users of that API, mostly games that want to make use of high-dpi mice. This is a simplified patch, the normalization is still in place for most of libinput, it merely carries the original coordinates in the event itself. In the case of touchpads, the coordinates are unnormalized into the x-axis coordinate space as per the documentation. Signed-off-by: Peter Hutterer <> Reviewed-by: Hans de Goede <>
Diffstat (limited to 'doc')
1 files changed, 27 insertions, 4 deletions
diff --git a/doc/normalization-of-relative-motion.dox b/doc/normalization-of-relative-motion.dox
index aaa1735f..dd5d39b3 100644
--- a/doc/normalization-of-relative-motion.dox
+++ b/doc/normalization-of-relative-motion.dox
@@ -12,10 +12,33 @@ physical movement or 10 millimeters, depending on the sensor. This
affects pointer acceleration in libinput and interpretation of relative
coordinates in callers.
-libinput normalizes all relative input to a physical resolution of
-1000dpi, the same delta from two different devices thus represents the
-same physical movement of those two devices (within sensor error
+libinput does partial normalization of relative input. For devices with a
+resolution of 1000dpi and higher, motion events are normalized to a default
+of 1000dpi before pointer acceleration is applied. As a result, devices with
+1000dpi and above feel the same.
+Devices below 1000dpi are not normalized (normalization of a 1-device unit
+movement on a 400dpi mouse would cause a 2.5 pixel movement). Instead,
+libinput applies a dpi-dependent acceleration function. At low speeds, a
+1-device unit movement usually translates into a 1-pixel movements. As the
+movement speed increases, acceleration is applied - at high speeds a low-dpi
+device will roughly feel the same as a higher-dpi mouse.
+This normalization only applies to accelerated coordinates, unaccelerated
+coordiantes are left in device-units. It is up to the caller to interpret
+those coordinates correctly.
+@section Normalization of touchpad coordinates
+Touchpads may have a different resolution for the horizontal and vertical
+axis. Interpreting coordinates from the touchpad without taking resolutino
+into account results in uneven motion.
+libinput scales unaccelerated touchpad motion do the resolution of the
+touchpad's x axis, i.e. the unaccelerated value for the y axis is:
+ y = (x / resolution_x) * resolution_y
+@section Setting custom DPI settings
Devices usually do not advertise their resolution and libinput relies on
the udev property <b>MOUSE_DPI</b> for this information. This property is usually