path: root/TODO

- 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




______________________________________________________________________________
= array lookups for symbols

- make arrays to lookup symbols by usagepage# and usage#

- advantage: much fewer symbol lookups

- disadvantage: much more RAM used.

implementation idea #1:

make hid-specific gensym() function which checks an array for the symbol by
#.  If it doesn't exist, it looks up the symbol and adds it to the array.  The
array size should be dynamically allocated so that [hid] doesn't use massive
amounts of memory.

If no vendor-defined pages are used, then the array could be quite small.  If
only one usage page is used, then it would also be not too big.  Otherwise, it
could use 10+ megs of RAM... hmm..

implementation idea #2:

this array should be built by hid_build_elements_list().  Then each time it
fetches an event using the element_pointer array, it would also get the stored
usage_page and usage symbols, and instance t_float.  So I need to make an
element struct like:

struct _hid_element
{
		  void *element;
		  t_symbol *type; // HID "usage page"
		  t_symbol *usage; // Linux "code"
		  t_float instance;
		  t_float previous_value; //only output on change on abs and buttons
} t_hid_element;

For Linux input.h, instead void *element, store the type and code numbers to
compare against

______________________________________________________________________________
= output one value per poll

- 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

to eliminate the jitter of the messages being processed every block, have
[poll 1( set the time to the poll size (~1.5ms for 44,100)

______________________________________________________________________________
= iterate through elements and do a proper queue of the ones we want:

- also, label multiple instances of the same usage

http://mud.5341.com/msg/8455.html


______________________________________________________________________________
= make second inlet for poll # (for [human->pd])


______________________________________________________________________________
= output device data on open

- Logical Min/Max i.e. [range -127 127(
- device string  [name Trackpad( 



______________________________________________________________________________
= open devices by name

i.e "Trackpad" a la Max's [hi]


______________________________________________________________________________
= 
= autoscaling based on Logical min/max

- this is probably essential for input, the question is how to find out what
  the data range is easily.

- output would be handy, rather than autoscale, to save on CPU

- this should probably be done in Pd space

______________________________________________________________________________
= test verbose names

- matju says symbols are compared by pointer, so they are fast

- try verbose names like:
  		syn = sync
		snd = sound
		msc = misc
		rep = repeat
		pwr = power

- maybe these too
		abs = absolute
		rel = relative
		btn = button

- maybe make the type the full name, with the code using the abbreviation

- change generic ev_9 to type_9

- change word "code" to "element"


______________________________________________________________________________
= event name changes

- make key/button Type "button" rather than "key" (undecided on this one)


______________________________________________________________________________
= hid/serial

- open/close status outlet

- [send ( to send data

- [tgl] 1/0 for open/close


______________________________________________________________________________
= linux input synch events (EV_SYN)

- these seem to be generated by the Linux kernel, so they probably don't fit
  in with the [hid] scheme.  Probably the best thing is to ditch them, or
  figure out whether they should be used in controlling the flow of event
  data, as they are intended.


______________________________________________________________________________
= writing support!

- Linux example: http://www.linuxjournal.com/article/6429


______________________________________________________________________________
= profile [hid] object and usage

- find out if [autoscale] takes a lot of CPU power, or where in [hid] is using
  CPU where it doesn't have to be


______________________________________________________________________________
= Report available FF effects

- check against HID Utilities Source/PID.h


______________________________________________________________________________
= 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

- 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)



 /----------------------------------------------------------------------------\
------------------------------------------------------------------------------
   BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS BUGS 
------------------------------------------------------------------------------
 \----------------------------------------------------------------------------/

______________________________________________________________________________
- BUG: crashes when you try yo open "mouse" with no args


______________________________________________________________________________
- BUG: on Mac OS X, polling starts without hid_build_device_list()

- when polling starts, hid_build_device_list() should be called before starting


______________________________________________________________________________
- BUG: figure out how to prevent segfaults on mismapped devices/elements

- it should gracefully ignore things where it currently segfaults

- looks like its in build_device_list

______________________________________________________________________________
- BUG: multiple instances pointing to the same device don't have seperate close/free

- closing the device on one instance closing that same device on all other
  instances of [hid]

- deleting that instance also closes the device for all other instances
  pointing to that same device


______________________________________________________________________________
- 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()


______________________________________________________________________________
- 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

  abs   abs_hat0x       Button Input, Keyboard Usage 0x39
  abs   abs_hat0y       Button Input, Keyboard Usage 0x39

I am pretty sure this is just a hid_print_element_list() display problem.