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
|
==============================================================================
= define generic event timestamp struct (probably Pd-ized input_event )
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
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
- this will have to be dealt with when the "mouse0", "joystick2" arguments are
implemented
==============================================================================
= 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
==============================================================================
= 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?
==============================================================================
= ditch x_devname in hid_linux.c
- use sprintf(arg,"/dev/input/event%d",x_ddevice_number); instead
==============================================================================
= consistent console output
void hid_post(const char *format, const char *);
==============================================================================
= if device is closed and obj is started, open device and start
______________________________________________________________________________
------------------------------------------------------------------------------
BUGS
______________________________________________________________________________
------------------------------------------------------------------------------
______________________________________________________________________________
- BUG x->x_delay reset to default when device is opened
______________________________________________________________________________
- BUG: [mouse] and [joystick] arguments don't work to open device
______________________________________________________________________________
- BUG: [open('ing a device causes all other active [hid] objs to have their
devices closed
- this means only one [hid] object can have an open device at one time
- I thought this was due to the hid_close_device() call in hid_open(), which releases
the device list, but this doesn't seem to be the case.
______________________________________________________________________________
- BUG: getting events from the queue doesn't output a 0 value event when the
motion stops, so when the mouse stops, the sound keeps playing.
This is probably only a problem on relative axes.
This will probably have to be implemented on a platform-specific level:
- On Darwin/MacOSX, I think that the HIDGetEvent() loop will have to be
followed by one call to HIDGetElementValue()
|
