<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - xf86-input-libinput: Rough and lopsided mouse movement in games/apps that reposition mouse"
href="https://bugs.freedesktop.org/show_bug.cgi?id=96982">96982</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>xf86-input-libinput: Rough and lopsided mouse movement in games/apps that reposition mouse
</td>
</tr>
<tr>
<th>Product</th>
<td>Wayland
</td>
</tr>
<tr>
<th>Version</th>
<td>1.3.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>libinput
</td>
</tr>
<tr>
<th>Assignee</th>
<td>wayland-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>dannihfoss@fastmail.fm
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=125136" name="attach_125136" title="listprops.txt">attachment 125136</a> <a href="attachment.cgi?id=125136&action=edit" title="listprops.txt">[details]</a></span>
listprops.txt
When using xf86-input-libinput as the input driver in X11, the mouse movement
is very stair-steppy and biased toward moving up and to the left. While it
looks like this issue has already been reported as <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - USB mouse doesn't register slow movements to the right or down in Gnome on Wayland"
href="show_bug.cgi?id=83674">bug #83674</a> and marked
invalid, it actually affects a wide range of applications, not just Clutter.
This issue does not occur when using xf86-input-evdev as the input driver but
I'd really prefer to use libinput as the acceleration curve feels much more
natural than evdev.
My understanding of this issue is this: Many games and applications implement
mouse movement ("mouselook") by constantly repositioning the mouse cursor in
the center of the window or screen and then track the distance the mouse has
moved away from this center to determine movement.
The problem is that when the mouse is getting repositioned, it looks like the
libinput driver is chopping off the fractional portion of the position, meaning
that if the mouse cursor's X position is at, say, 160.8, it becomes 160.0. The
evdev driver preserves the fractional, so a coordinate of 160.8 stays at 160.8
- moreover, if the mouse is at X coordinate 159.8 and the cursor is moved to
160, the position is now at 160.8, not 160.0.
The reason for preserving the fractional is to account for very slow mouse
movements. If the mouse is moved to the right or down a fractional amount, this
movement is lost, since moving the mouse to X coordinate 160.1 will place it
back at 160.0 - this means that a significant amount of effort is needed to
move the mouse down or to the right without it "eating" the input. Conversely,
if moving the mouse ever so slightly to the left - say from X coordinate 160.0
to 159.99, it will suddenly snap over to 159.0, making movement very lopsided
going up and toward the left.
I understand that constantly repositioning the mouse cursor is not the ideal
solution. However, many games do this and most will probably never be fixed to
do it the right way (e.g. ask the window system to trap the cursor inside a box
and get raw mouse input). This is especially true of indie developers, who
release a large number of games to make a living and do not have the time or
money to continuously maintain their older games, nor do they have the means to
make the source of those games available for others to fix these issues.
Applications with this issue off the top of my head:
- SLADE, in 3D editing mode
- Slime Rancher
- Joy Exhibition (itch.io)
- Probably just about any Unity3D-powered game now that I think about it
If the game window hides the mouse cursor, the effect can be more closely
observed by opening an always-on-top window above it (such as Yakuake), which
should make the mouse cursor reappear while still having it be trapped.
I do not know where exactly in the stack this issue occurs, so I would
appreciate any help with triaging this issue. If I know what part of the stack
is responsible for the issue I can at least patch my own system.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>