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

[Peter Hutterer]

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. */
-- 
1.7.4.4