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
|
==============================================================================
= define generic event struct (probably Pd-ized input_event )
something like:
struct input_event {
struct timeval time;
t_int type;
t_int code;
t_int value;
};
The question is whether the timeval is needed at all. Linux and Darwin
support it. Currently, I can only think of UPS PWR events actually using
timevals.
===============================================================================
= HID Manager Type/Usage/UsagePage -> Linux Type/Code mapping
UsagePage
Misc Input/Generic Desktop X == ev_rel/rel_x
Button Input/Button #1 == ev_key/btn_left
LED UsagePage => ev_led
LED Usages == Linux ev_led codes
==============================================================================
= device selection
by # (1,2,...), generic name (mouse1, joystick2, tablet3...), or device name
("Trackpad", "Microsoft 5-button Mouse with IntelliEye(TM)", etc.)
first get # working, that's probably the easiest
by #
------------------------------
GNU/Linux
sprintf(x_devname->s_name,"/dev/input/event%d",deviceNum + 1);
Darwin
prHIDBuildDeviceList();
currentHIDDevice = discoveredDevices[gNumberOfHIDDevices];
==============================================================================
= figure out how to store device ID in obj struct
(in SC_HID.c its locID and cookie)
it should probably just store the Pd arguments
==============================================================================
= raw values vs. calibrated
- relative axes should probably be raw data, since its pixel data, but then
this causes problems with sensitivity across different mice. The mouse
sensitivity would probably best translate as resolution, ie calibrated data,
rather than sensitivity, ie raw data.
- absolute axes should be calibrated, so that the same positions on different
devices map to the same value
- but then, I could just create an [autocal] object in Pd, and have [hid]
output only raw values. This would probably be best in keeping with the
idea of having [hid] giving as low level access as possible, then using
[mouse], [joystick], [tablet], etc. objects providing a nice, consistent
interface to the respective devices.
==============================================================================
= pollfn for mouse-like devices
- determine whether using a pollfn is actually better than using a t_clock
- any device that acts like a system mouse can be used with a pollfn, since
the mouse data will go thru Pd's network port, triggering the pollfn.
- this is probably unnecessary since the t_clock seems to run well at 1ms delay
==============================================================================
= make generic functions for the basic actions
releaseDevices()
buildDeviceList()
buildElementList()
getEvent()
- make Darwin HID Manager -> Linux input event convertor functions
==============================================================================
= [close( message might be totally frivolous.
- what does Max's [hi] do with that?
- when would you need to close a device, yet still have the object there?
[open( closes the previous device anyway.
==============================================================================
= function return values
- most functions probably do not need return values
- return (1) seems to be the default on many functions
==============================================================================
= control input messages
- the [delay( message should be replaced by the [poll( msg
- should [poll( also start things, or should it just set polling time?
- are [start( and [stop( needed? is 0/1 enough?
|
