From e2dfa073d484b3e165715c20fcef162d8b83513d Mon Sep 17 00:00:00 2001 From: Hans-Christoph Steiner Date: Fri, 2 Jun 2006 21:32:53 +0000 Subject: added a bunch more status info in the Pd domain: device count, range for each element, etc svn path=/trunk/externals/hcs/hid/; revision=5158 --- TODO | 54 ++++++++++++++++++++++-------------------------------- 1 file changed, 22 insertions(+), 32 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index 4cf35cf..27394fd 100644 --- a/TODO +++ b/TODO @@ -1,16 +1,24 @@ +______________________________________________________________________________ +- deal with hatswitches!! + +Because of the currnently implementation of the conversion of the MacOS X +style event to the Linux style event, an event with a value of zero is output +on the unchanged axis when the hatswitch is moved in along the X or Y axis (as +opposed to diagonally). but this might be fixed... - fix up hatswitch logic... hmmm on Mac OS X, just make the next element in the array always be the Y axis of the hatswitch, then when receiving a hatswitch event, output, increment, then output again (yes, its a hack). -- add device type to [info( -HIDGetUsageName(pCurrentHIDDevice->usagePage, pCurrentHIDDevice->usage, cstrDeviceName); - -i.e. cstrDeviceName +- what do standard hatswitches output on the various platforms? they should + probably always output like axes, but then the CUI will be screwed +______________________________________________________________________________ += fix key names on Mac OS X +I think they are unimplemented... :-( ______________________________________________________________________________ = array lookups for symbols @@ -57,16 +65,6 @@ ______________________________________________________________________________ - for relative axes, sum up all events and output one http://lists.apple.com/archives/mac-games-dev/2005/Oct/msg00060.html -- for absolute axes, just output latest value. if they are not in the queue, - I can check them manually - -- buttons, output everything - -- is this at all necessary? How often do multiple events happen in one poll - period? ANSWER: on Mac OS X, most hid_get_events() calls fetch multiple - events for each mouse axis, so yes, its probably necessary - - ______________________________________________________________________________ = [poll 1( message set to exact delay based on block size @@ -82,8 +80,13 @@ http://mud.5341.com/msg/8455.html ______________________________________________________________________________ -= make second inlet for poll # (for [human->pd]) += make second inlet for specific status requests [human->pd]) +- [vendor(, [product( +- [range( +- [poll( +- [name( +- [type( ______________________________________________________________________________ = output device data on open @@ -191,17 +194,12 @@ ______________________________________________________________________________ - at standard block size (64 samples), one block = ~1.5ms -______________________________________________________________________________ -= function return values - -- most functions probably do not need return values - - ______________________________________________________________________________ = check out using USB timestamp -- use the USB timestamp to correctly space the output data (meh, probably - unnecessary) +- use the USB timestamp to correctly space the output data + +(meh, probably not useful) @@ -216,7 +214,7 @@ ______________________________________________________________________________ ______________________________________________________________________________ -- BUG: on Mac OS X, polling starts without hid_build_device_list() +- BUG: on Mac OS X, polling starts without hid_build_device_list() or hid_open() - when polling starts, hid_build_device_list() should be called before starting @@ -250,14 +248,6 @@ This is probably only a problem on relative axes. followed by one call to HIDGetElementValue() -______________________________________________________________________________ -- BUG: hatswitches on MacOS X output an event without a change in value - -Because of the currnently implementation of the conversion of the MacOS X -style event to the Linux style event, an event with a value of zero is output -on the unchanged axis when the hatswitch is moved in along the X or Y axis (as -opposed to diagonally). - ______________________________________________________________________________ - BUG: on MacOS X, two keyboard key codes are reported as hatswitches -- cgit v1.2.1