[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    Re: Making X report the mouse position with subpixel precision
From:       Paul Vojta <vojta () Math ! Berkeley ! EDU>
Date:       2007-02-28 18:40:01
Message-ID: 20070228184001.GA24194 () math ! berkeley ! edu
[Download RAW message or body]

On Wed, Feb 28, 2007 at 10:04:49AM +0100, Tomas Carnecky wrote:
> The problem is that the _mouse_ doesn't send events in a bigger 
> precision. The mouse reports one unit movement, the kernel generates a 
> input-event with one unit movement, X reads the input-event and sends a 
> one unit (pixel) movement to its clients. (tested with the evdev interface).
> 
> Even if I set my mouse to 1600 DPI (todays top mice can only handle as 
> much as 2000 DPI), it wouldn't be useful to divide one pixel into 2x2 
> sub-pixels, because then I'd have to move my mouse a too big distance to 
> get the cursor somewhere.

If you set your mouse to 1600 DPI then moving it an inch would cause it to
report that it moved 1600 units (=pixels) to the X server.  Dividing it
into 2x2 subpixels would make it more reasonable.

I have a Kensington mouse, and I have to set the resolution lower in order
not to have the cursor flying all over the screen when I move the mouse.

Also, other pointing devices, such as touchpads, use their own internal
coordinates.  These have a much higher resolution than the mouse output,
and this translation takes place within the X driver (at least in the case
of Synaptics).

I'm not necessarily in support of the X server reporting subpixel mouse
events; I'm just pointing out obvious flaws in the above argument.

On a somewhat related note, I would like to see the X server break away
from the 1 mickey = 1 pixel rule, and do its own conversion of mickeys
to pixels, so that mice can be used at high resolutions without extreme
behavior, and so that acceleration, etc., can be handled more smoothly.

--Paul Vojta, vojta@math.berkeley.edu

[prev in list] [next in list] [prev in thread] [next in thread]