1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
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
|
