From df90db892d16143742eb3c09e048f5b76457a62e Mon Sep 17 00:00:00 2001
From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed, 20 Apr 2011 11:49:57 +1000
Subject: [PATCH] dix: document DoGetDirection's maths

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@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Simon Thum <simon.thum@gmx.de>
---
 dix/ptrveloc.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/dix/ptrveloc.c b/dix/ptrveloc.c
index 3bf871658..ab2bca766 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 each),
      * except on very well-aligned mickeys. */