From 1906581fd01266403c167770398b07267a25e79e Mon Sep 17 00:00:00 2001 From: "Stephen M. Webb" Date: Wed, 30 Nov 2011 16:36:55 -0500 Subject: Removed python/Makefile.original and python/TODO --- python/Makefile.original | 23 -------- python/TODO | 150 ----------------------------------------------- 2 files changed, 173 deletions(-) delete mode 100644 python/Makefile.original delete mode 100644 python/TODO 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: - - rydberg: what are the valid values for the "code" and "type" - parameters in the evemu_* device data functions? - did you see the latest bzr branch with header documentation? :-) -* oubiwann merges from trunk... - if we are talking about evemu_has_event, for instance, then type is - one of EV_ABS, EV_REL, EV_KEY etc - and code is a valid code for the type - for example, type = EV_ABS, - code = ABS_MT_POSITION_X - rydberg: first question about this: - 1) by "etc." do you mean all the EV_* constants defined for the - linux input events? - yep - 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 - is that a complete list? - looks like it, yes - okay, cool - the second question I have is this: type seems to indicate which - values are "legal" for code - however, most of those functions don't have a type parameter; only - the code parameter - so how do I know which code values are valid? - yes, those are restricted to EV_ABS only, which are the codes - containing the MT protocol - got it - rydberg: so, starting at line 81 in that same file, I've listed the - ABS_* values - do those look more or less complete? - up to kernel 2.6.37 it seems - okay - #define ABS_MT_DISTANCE 0x3b /* Contact hover distance */ -* oubiwann adds that one - 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 - since it takes a type parameter - is that the case? - if so, what events might we be concerned with? - evemu is a representation of the kernel device, and as such, can be - used to emulate keyboards, mouse, joysticks, accelerometers, etc - so even though we do this for MT in particular, there is no - restriction to how evemu can be used - rydberg: okay, so for our purposes the value passed for "type" in - evemu_has_event will almost always be EV_ABS, right? - or EV_KEY - for buttons - rydberg: with possible legal values of BTN_*? - or KEY_* also? - yep - we have only seen BTN_ used so far - okay, cool - rydberg: can you give me an example of a button usage in MT? - is this like two taps being used as a button click or something? - a trackpad with its buttons -* gustavold (~gustavold@galena.ime.usp.br) has joined #ubuntu-touch - ah, I didn't realize that trackpad buttons were being used in MT - data - rydberg: okay, thanks man! - I'm going to update the python docs with all this information - they arent really, but they are part of the kernel device - - -- cgit v1.2.3