EDIT:<p>I took a quick look at the codebase for the browser (<a href="https://github.com/MozillaReality/FirefoxReality" rel="nofollow">https://github.com/MozillaReality/FirefoxReality</a>), and it isn't what I was expecting (once you dive to app/src) - definitions for the main three supported systems are each at this root level, and I didn't see any kind of "template" or "empty" definition file or anything to guide someone wanting to make one themselves - but maybe that's not possible.<p>It appears that these files are wrappers around the APIs used for those other products (?). So your only hope would be to base your wrapper on these existing ones, which while feasible (working with the API docs too), isn't what I would call "ideal". Plus, there doesn't seem to be a separation of concerns when it comes to input vs output.<p>I mean, what if I wanted to use my hacked powerglove with my Rift HMD? Or what if I wanted to use my Vive controllers with my Virtuality Pro?<p>I understand that the supported systems are nominally "all-in-one" solutions, but the parts (HMDs, controllers, tracking) are available separately (at least in some of the cases) - so mixing and matching might be something someone would want to do. It would definitely be that case for those implementing their own "mixed setup", where they might have an old VPL datasuit and glove, plus some other old pro-level HMD that they like to play with.<p>As it is, it seems like each setup would have to be a custom "all-in-one" for that setup, so if you had two different systems that used two different HMDs and tracking, but both used the same Powerglove Minelli interface - the code couldn't be "shared" in a reasonable manner (yes, I know with the right symlinking and other buggery it could be accomplished within the current structure, but it isn't ideal).<p>I was hoping the structure would be more like /plugins, with /input /output, and under those /controller /glove /wand and /hmd /motionplatform /cave, then under each /occulus /vive /google /example<p>Or something like that. Am I wrong here?<p>---<p>Ok - I know this is likely open source and thus can be changed, but I honestly wish that things like this offered (and marketed) a means - via plugins or something (and maybe this does - hence, marketed) - the ability to expand on what i/o devices are allowed.<p>Sure - should the "main players" be featured? Of course. But what about those of us who might like to - oh, I don't know - throw on an old Forte VFX-1 and a Powerglove and go at it? Maybe we want to recreate the experience of using REND386?<p>Or what if you have access to a Polhemus or Ascension magnetic tracking system (or any number of other "pro-level" tracking)? Or HMDs? Or other input devices? Or motion platforms?<p>Maybe you're a developer of something completely new, and want to play in this same environment and make it compatible...<p>Again - I haven't dug into the code, and maybe it's designed to accommodate these kinds of use cases. I'd just love to see that availability, if it exists, to be advertised more. I guess its because I get the same feeling around software released for my OS of choice, where Windows and Mac are prominently advertised, and Linux is at best, if it's offered at all, the classic step-child stuffed in a closet.<p>As an aside, I never can figure out the argument that "we don't offer support for Linux because the market is so small, it isn't worth it for us" - well, if everyone keeps saying and doing that, what do you think will ultimately occur? Do you think that market will grow, stay the same, or shrink?