Sean asked me to review his proposal for the HID controller input mapping
format, I did but then went completely bollocks with it thinking what else
could be done within the XML file.
As a result, here is an example file which has nothing to do with his planned
format. Here I try to tackle in XML issues seen with HID device control, for
both input and output. I'm not proposing this format to replace Sean's ideas,
but I tried to think of the most common use cases how HID is used and show a
XML method to do the trick for a HID packet. I have shamelessly thrown away any
backwards compatibility as well.
http://tuohela.net/hid-crazy-map.xml
My XML map allows developer to register one javascript callback function, which
will handle input and output HID packets as one large chunk. The complexity of
this XML format comes from the ideas how to handle HID inputs without a script.
In most cases, the sensible option is to create one hid_input javascript
function and handle state processing here only. The other options are only
relevant for learning HID codes automatically or for learned mappings.
Some other notes about HID in general:
HID is not like MIDI. To control button led state on most devices, you send a
packet which sets state for ALL leds in one packet. In addition, HID
controllers send a large packet containing state for multiple controls in same
packet, not just 'button X was pressed' or 'slider X was moved'.
This means that for HID output packets (change led states etc), in a naive
implementation you would call EVERY function set to handle any button states
every time one of the states handled by this output packet changes. For
example, press 'play' and the output led function to set 'play' led would also
trigger calls to check status of every other LED, otherwise you would set all
other leds off.
Similarly, for HID inputs which call functions, the XML would create a function
call for each function in the mapping when matching packet is received, even if
the relevant bytes for the function in the packet did not change from last
packet. For example, pressing play on a HID controller would result to calls of
EVERY function matching the packet signature in XML, when you use a naive
implementation of things.
To solve these two function call issues, the HID XML input control mapping
support should:
- Register each packet type (<controls> packet) to a buffer matcing the sent
packet bytes
- Store the last received packet to the buffer after processing current packet
- Compare sections of the packet (<control> bytes offset) to the last packet
when receiving
- If received bytes are same as last packet's, the control function is NOT
triggered, whatever it was supposed to do
For HID output control mapping, we should:
- Register each output packet type (<outputs> packet) to a buffer
- Store current state of the output fields (<output> entries) to the buffer
- Add callbacks to the functions specified in the output to update the buffer
fields, instead of calling the functions to construct the packet fields
- Send the whole buffered and modified packet after callback has modified the
buffer
This way, if we for example send 'all button leds' packet, we only send the
packet when button states change, and to calculate the correct packet only need
to run callback for the modified button state and get the state of all other
buttons from the cached output packet buffer.
*hile*
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
