Reported by Kevin Brown on the Debian BTS. I observed the problem on my machine too. He says:

"After upgrading from input-mouse 1.2.2 and xserver 1.3 (Debian testing) to 1.2.3 and 1.4.1 (Debian unstable), the mouse code appears to have stopped internally tracking sub-pixel mouse pointer movements.  This behaviour appears to be independent of the video driver being used -- I get this with both the nv driver and the nvidia driver.

I explain this in detail below so you can see what I'm talking about,
but if you want to see it in action, simply execute the command:

xset m 1/2 1

And then move the mouse slowly.  You'll see that it won't move at
all until you get it moving fast enough.  The proper behaviour is for
it to move more slowly than normal (half-speed), but to always
register movement.

The mouse acceleration code, in general, figures the amount of
movement of the mouse cursor by examining the amount of movement
during a given small, fixed time interval, applying an optional
multiplication to that movement, and then applying that movement to
the mouse cursor.  If the amount of movement is greater than the
threshold, it would multiply the movement by the acceleration fraction
(which one can set via the xset command) and apply that to the pointer
location, else it would change the pointer location directly by the
amount of mouse movement there was.

In theory, it works that way now.  The problem is: what if the
fraction is less than 1?  In the previous versions of the handler (or
the core code -- I don't know where this specific code resides), the
mouse pointer position was essentially tracked by a floating point
value (or at least a number that could store fractional results).  If
your movement was past the threshold, the mouse would "move" by that
fractional factor, and the result was that you could configure your
mouse movement to be slower than what the mouse's native movement
was.  For people with a relatively fast-moving mouse (extremely high
resolution), this is very useful.

The current behaviour is this: if the amount of mouse movement *after
multiplication against the acceleration value* is less than 1, it is
truncated to zero.  And the end result is that when the acceleration
fraction is set to less than 1, the mouse won't move *at all* until
you move it fast enough that the resulting movement value (after
multiplication against the acceleration value) is at least 1 pixel's
worth.

And the end result is that I've lost the only means I have of
finely controlling the sensitivity of my mouse under X.  I have to set
my mouse to an acceleration of at least 1/1 to make it usable at all,
because otherwise the mouse pointer will fail to move at all if the
mouse is moved too slowly.

Needless to say, this is most frustrating."