Great, this is fantastic. I wasn't thinking in terms of a generic HID-USB functionality, but this does make more sense to make any solution generic. I'm at work now but will have a more detailed look thorough the links when I get home and see if I can contribute something.
I'm more than happy to get stuck in with coding, and I'm not particularly looking for a simple solution where someone else does the hard work and I just write the config file. I mean, where's the fun in that?
It's not that this is particularly complex or tedious to do, we can provide all the pointers and help that you need. With your background in Java programming, the C++ code and the concept of "listeners" and callbacks should seem fairly natural actually - so you probably won't need too long to add a new "dummy" subsystem to get started quickly.
Obviously, you could still focus on what's important for your own project now, and let others complete it later on.
I've been a bit crippled over the last couple of months by very intermittent internet access at home, but I've got some time off in the next two weeks, so wanted to try and get stuck in then.
Being able to use gitorious to clone the repositories there, would definitely be good - the simgear/flightgear repositories are straightforward to clone, even on mobile broadband.
However, fgdata may be a bit troublesome, but you could just as well use the fgdata from the latest release, modify the "version" file in $FG_ROOT and then use your own compiled binaries. Because most of your work will happen in C++ space anyway.
I need to get a bit of a better understanding in my mind of what is generic in USB comms and what is specific to the device that I've got and then I think that's all the major pieces covered, and it all sounds doable.
Yes, that's probably going to be most time-consuming, the C++ stuff is straightforward actually - and looking at the links below, it shouldn't take you much more than 30+ minutes to get a dummy prototype up and running. Obviously mapping an API to the property tree using listeners would be a little more complex though. For starters, you could directly map library-functions to property-tree callbacks.
I've managed to get FG built and running from source under linux, not yet under osx and I haven't got a windows machine, so barring me sorting out my mac build I'll be working on my old Linux machine.
that sounds fine, and should be no problem: most developers are using some variant of *nix, and frankly it's much easier to build FG on *nix platforms, too
The wiki has a separate portal, dedicated to contributors who want to get involved in core development:
http://wiki.flightgear.org/Portal:DeveloperTo get started, you'll probably want to take a look at:
http://wiki.flightgear.org/Howto:Start_core_developmentThe specifics of adding a new subsystem to FlightGear are covered here:
http://wiki.flightgear.org/Howto:Create_new_subsystemsThis article also provides an introduction to using the SGPropertyChangeListener class, so that your subsystem may subscribe to property tree events in order to "fire" its own callbacks (i.e. subsystem methods like "valueChanged").
Basically this works such that you could add a subscription for some arbitrary path, such as "/usb-hid" - now, whenever somethhing writes to "/usb-hid", your class will be automatically invoked using a listener, i.e. one of the class methods ("valueChanged") will be "fired", so that you can process these events - i.e. in order to see if the events are valid and match what you are expecting.
This technique is fairly common in FlightGear, it is also used to instantiate new AI traffic, but also the new Canvas system uses this method:
All IPC is handled through the property tree and a separate C++ subsystem which registers listeners to "parse" and "process" and writes to a certain branch, such as /ai/ or /canvas or anything else.
In turn, this enables you to map an existing API or cross-platform USB/HID library into property tree space by coming up with typical operations, like "open, send, receive, validate, close" etc.
Ultimately, any other FlightGear system would be able to your new USB/HID layer by using the property tree. Which means that arbitrarily complex USB/HID protocols could be implemented in scripting space using Nasal scripting, which would merely invoke the C++ "glue" code.
Some of the details on adding new files to the existing cmake build environment are discussed here:
http://wiki.flightgear.org/Howto:Create ... instrumentA short introduction to the C++ API of the SGPropertyTree Node class is provided here:
http://wiki.flightgear.org/Howto:Work_w ... y_Tree_APIPlease note that so called "tied properties" shouldn't be used, but "PropertyObjects" should be favored whenever possible:
http://wiki.flightgear.org/Howto:Use_Pr ... ee_ObjectsLots of non-FG specific programming resources and pointers are available here:
http://wiki.flightgear.org/Programming_resources