[PATCH 05/20] dix: document DoGetDirection's maths

[Simon Thum]

On 04/20/2011 08:28 AM, Peter Hutterer wrote:
> This is the best explanation I can come up with, but it seems to hold true
> for my example values.
> 
> Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> ---
>  dix/ptrveloc.c |   12 ++++++++++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/dix/ptrveloc.c b/dix/ptrveloc.c
> index 50ad22a..fafbbb0 100644
> --- a/dix/ptrveloc.c
> +++ b/dix/ptrveloc.c
> @@ -483,8 +483,16 @@ DoGetDirection(int dx, int dy){
>  #else
>      r = atan2(dy, dx);
>  #endif
> -    /* find direction. We avoid r to become negative,
> -     * since C has no well-defined modulo for such cases. */
> +    /* find direction.
> +     *
> +     * Add 360° to avoid r become negative since C has no well-defined
> +     * modulo for such cases. Then divide by 45° to get the octant number,
> +     * e.g.     0 <= r <= 1 is [0-45]°
> +     *          1 <= r <= 2 is [45-90]°
> +     *          etc.
> +     * But we add extra 90° to match up with our N, S, etc. defines up
> +     * there, rest stays the same.
> +     */
>      r = (r+(M_PI*2.5))/(M_PI/4);
>      /* this intends to flag 2 directions (45 degrees),
>       * except on very well-aligned mickeys. */
Reviewed-by: Simon Thum <simon.thum at gmx.de>

You seem to have recovered the reasoning quite nicely, there's nothing I
could add.

Cheers,

Simon