Removed python/Makefile.original and python/TODO

2 files changed, 0 insertions, 173 deletions

diff --git a/python/Makefile.original b/python/Makefile.original
deleted file mode 100644
index 9dc959d..0000000
--- a/python/Makefile.original
+++ /dev/null
@@ -1,23 +0,0 @@
-build: extension
-	python setup.py build
-
-check:
-	sudo python -m evemu.testing.runner
-
-clean:
-	sudo rm -rf build
-	sudo rm -rf _trial_temp
-	sudo find . -name "*.pyc" -exec rm {} \;
-
-clean-parent:
-	cd ../; make clean-am && make distclean-am
-
-clean-parent-misc:
-	cd ../; sudo rm -rf Makefile Makefile.in aclocal.m4 autom4te.cache/ \
-	config-aux/ config.h.in config.log config.status src/.deps/ src/Makefile \
-	src/Makefile.in tools/.deps/ tools/Makefile tools/Makefile.in configure \
-	src/.libs/ src/evemu.lo src/libutouch-evemu.la tools/.libs/ \
-	tools/evemu-describe tools/evemu-device tools/evemu-echo tools/evemu-play \
-	tools/evemu-record
-
-clean-all: clean clean-parent clean-parent-misc
diff --git a/python/TODO b/python/TODO
deleted file mode 100644
index 0349ed4..0000000
--- a/python/TODO
+++ /dev/null
@@ -1,150 +0,0 @@
-BUGS
-====
- *
-
-
-TODO
-====
-
- * find out where bustype id -> bus name is (e.g., 3 -> BUS_USB)
-
- * implement device write
-
- * implement device extract
-
- * implement events record
-
- * emplements events play
-
- * implement a wrapper for the event stuff
-
-
-MIND-STATE DUMP
-===============
-
- * currently working on debugging why devices aren't being deleted after each
-   test (instead, they are being deleted once all tests have finished)
-
- * tracing through the evemu-device program to identify any logic in the C
-   that's missing in the Python implementation
-
- * the reason for the activity of the last bullet point: only the device name
-   is being written to the devices, not the actual device data
-
-
-NOTES
-=====
-Stephen's got some good examples for ctypes support here:
- * http://bazaar.launchpad.net/~bregma/utouch-geis/python-geis/view/head:/geis.py
-
-In particular:
- * line 289, the init for Geis, working around the issue of pointers getting
-   initialized inside a C function
- * line 295 for garbage collection
- * 299 and 265, for the byref trick
-
-Let's start with a simple case first:
- * try to get extract working
-
-Actaully, that's not so simple -- after talking with Henrik, he clarified that
-extract works directly against an input device, not against files.
-
-What I need to do first are these things:
- * create a virtual device from a recorded device file
- * replay the events from a recorded events file
-
-The script does this:
- * main()
-   * take the deivce/properties file as a parameter
-   * calls evemu_device, passing a filepointer for the properties file
- * evemu_device takes the passed file pointer
- * identifies a device file
- * writes the properties to the device file
-
-Notes about the device function sigs in Henrik's code:
-
-oubiwann: cnd: henrik defined a bunch of evemu functions that operate on a
-          pointer to the device
-cnd: ok?
-oubiwann: besides the pointer reference, these functions also take parameters
-oubiwann: one of them being simply "code"
-cnd: heh
-cnd: I have a feeling "code" has the meaning given in the evdev protocol
-oubiwann: in this context (parsing the device structure) can you think of what
-          the "code" parameter might be?
-cnd: i.e. ABS_X or REL_X or BTN_A
-cnd: the evdev protocol has types, codes, and values
-cnd: type is ABS, or REL, or KEY, etc.
-oubiwann: yeah, type is also a param in some of these
-cnd: code is a specific "variable" in each type group
-oubiwann: got it
-oubiwann: yeah, that makes sense
-cnd: so REL_X defines relative motion in the X direction
-oubiwann: thanks!
-
-More notes about the parameters passed in the device data functions:
-
-<oubiwann> rydberg: what are the valid values for the "code" and "type"
-           parameters in the evemu_* device data functions?
-<rydberg> did you see the latest bzr branch with header documentation? :-)
-* oubiwann merges from trunk...
-<rydberg> if we are talking about evemu_has_event, for instance, then type is
-          one of EV_ABS, EV_REL, EV_KEY etc
-<rydberg> and code is a valid code for the type - for example, type = EV_ABS,
-          code = ABS_MT_POSITION_X
-<oubiwann> rydberg: first question about this: 
-<oubiwann> 1) by "etc." do you mean all the EV_* constants defined for the
-           linux input events?
-<rydberg> yep
-<oubiwann> rydberg: the list I collected last night and added to the const file
-           starts at line 38 here:
-           http://bazaar.launchpad.net/~oubiwann/utouch-evemu/731678-python-wrapper/view/head:/python/evemu/const.py
-<oubiwann> is that a complete list?
-<rydberg> looks like it, yes
-<oubiwann> okay, cool
-<oubiwann> the second question I have is this: type seems to indicate which
-           values are "legal" for code
-<oubiwann> however, most of those functions don't have a type parameter; only
-           the code parameter
-<oubiwann> so how do I know which code values are valid?
-<rydberg> yes, those are restricted to EV_ABS only, which are the codes
-           containing the MT protocol
-<oubiwann> got it
-<oubiwann> rydberg: so, starting at line 81 in that same file, I've listed the
-           ABS_* values
-<oubiwann> do those look more or less complete?
-<rydberg> up to kernel 2.6.37 it seems
-<oubiwann> okay
-<rydberg> #define ABS_MT_DISTANCE  0x3b /* Contact hover distance */
-* oubiwann adds that one
-<oubiwann> rydberg: third question: if EV_ABS is all that we care about for
-           most of the functions (the ones without a type), this implies that
-           there are non-mt events that could be queried for in
-           evemu_has_event
-<oubiwann> since it takes a type parameter
-<oubiwann> is that the case?
-<oubiwann> if so, what events might we be concerned with?
-<rydberg> evemu is a representation of the kernel device, and as such, can be
-           used to emulate keyboards, mouse, joysticks, accelerometers, etc
-<rydberg> so even though we do this for MT in particular, there is no
-           restriction to how evemu can be used
-<oubiwann> rydberg: okay, so for our purposes the value passed for "type" in
-           evemu_has_event will almost always be EV_ABS, right?
-<rydberg> or EV_KEY
-<rydberg> for buttons
-<oubiwann> rydberg: with possible legal values of BTN_*?
-<oubiwann> or KEY_* also?
-<rydberg> yep
-<rydberg> we have only seen BTN_ used so far
-<oubiwann> okay, cool
-<oubiwann> rydberg: can you give me an example of a button usage in MT? 
-<oubiwann> is this like two taps being used as a button click or something?
-<rydberg> a trackpad with its buttons
-* gustavold (~gustavold@galena.ime.usp.br) has joined #ubuntu-touch
-<oubiwann> ah, I didn't realize that trackpad buttons were being used in MT
-           data
-<oubiwann> rydberg: okay, thanks man!
-<oubiwann> I'm going to update the python docs with all this information
-<rydberg> they arent really, but they are part of the kernel device
-
-