The general process is this:
* Define a device template, which specifies the capabilities of the device (what commands it can accept, what events it can emit, how to find the device in a plug and play manner, any software that needs to be installed, etc, and any additional related devices that need to be a part of the installation in order for it to function)
* Use DCEGen to create a C++ project containing stubs, or use the built in Ruby Editor to fill in Ruby snippets (Ruby code also defines a few specific loops to handle device input, device initialization, and close, which would otherwise be explicitly defined in C++)
* Fill in the blanks, compile, add the device to your device tree... then test, fix, compile, repeat.
This is explained in detail on the wiki: http://wiki.linuxmce.org/index.php/Developing_a_DCE_Device
And in more detail on pages like:
Once the device development has reached a point where things work well enough, you can work with us to push the driver into the source tree, and its relevant database information into the central sqlCVS database.
One important aspect to understand:
LinuxMCE is _not_ Crestron/AMX/etc. It was designed as the Anti-Crestron. That is, instead of explicitly defining from dirt every possible action, and debugging those actions, LinuxMCE provides an architecture of convention where the most common situations are greatly simplified (A/V hookup, for example, is no longer a matter of endless strings of macros, but we derive what needs to be done by a combination of knowing how to control each and every device, as well as the way they are connected in relation to other devices. The end result being that a user has to do much less work to get things working, usually adding devices creates scenarios automatically, with user scenarios added at their own convenience with wizards.)
We have a considerable amount of architecture. Over 4 million lines of C++ code, of our own, not counting the 12 or so projects that we appropriate from upstream. This takes time for any interested developer to understand, and my standard answer to this is, "take a year of your life, and learn this system."
The holes left in our architecture are a result of planned features that never quite left the database schema (such as multiple outputs in a matrix), and that we simply don't have the setup to be able to develop or test.