doc: drop unmaintained TODO file

Maybe this comes back later, I have my own private local TODO
system... this file was largely being ignored.

1 files changed, 0 insertions, 31 deletions

diff --git a/TODO b/TODO
deleted file mode 100644
index 08322ee..0000000
--- a/TODO
+++ /dev/null
@@ -1,31 +0,0 @@
-- Figure out why drm isn't restoring the console automatically when killed,
-  when a VT switch restores everything, this starts to look like a drm bug.
-
-- Switch to an ncurses UI for choosing the device/connector, maybe add ability
-  to reconfigure the drm video mode and more sophisticated topology changes?
-
-- Optimize the ray tracer, a spatial index would be nice, there's an octree in
-  the sparkler particle system that may be applicable.  A k-d tree is probably
-  better though, since once can play with the hyperplane heuristics to better
-  suit ray tracing and adapt to the scene complexity.  The threading could also
-  use some love, I haven't had a chance to test it on anything greater than 2
-  cores.
-
-- If keeping the stdio drmsetup, fix the bugs in it (input isn't really checked
-  properly)
-
-- Figure out if it's possible/how to page flip and synchronize multiple crtcs
-  at once.  Can we have a drm program running discrete effects on multiple
-  monitors, in a tear-free fashion on all of them?  I think this is actually a
-  complicated problem they're struggling to deal with in X/weston land general
-  multihead.
-
-- Add more colorful explosions to the sparkler
-
-- The sparkler can produce drastically different simulations with little
-  change, it would be neat to generalize it further to where there are just
-  profiles of sorts which describe the system then the sparkler runs the
-  simulation.  Turning sparkler into just a platform which manages memory,
-  indexes space, and runs the chosen rules would be neat.  As-is one would just
-  clone the sparkler module to a new tree and start tweaking things and adding
-  new particle types, which is fine just inelegant.