This post will pretty much only be of interest to Linux users – everyone else, talk amongst yourselves. Topic of discussion: X-Plane.com is neither a plane nor a communist. (Sorry, work on the road processing code has drained me of any remaining sanity.)
The brief history of X-Plane for Linux is that Joshua Wise ported X-Plane to Linux a while ago because he felt like it (and being too young to drive at the time, apparently had some free time). The Linux port was never a commercial effort. – Laminar Research didn’t say “we’ll make a ton of money by porting to Linux, so let’s hire someone”. It just sort of happened. (Well, I wasn’t in the room so I don’t know exactly what was said.)
Linux has steadily represented about 5% of our user base from that point on, and this gets to the “commercial problem” of Linux: even with the work we do to try to keep platform specific code in X-Plane to a minimum, Linux sales don’t justify the development cost to maintain the platform.
Yet there still is a Linux version of X-Plane. We keep renewing the Linux port for “one more version” because while the Linux community doesn’t buy a ton of copies of X-Plane, Linux users do contribute in an outsized way by providing code back to the scenery tools and other development efforts. In other words, the Linux community doesn’t contribute dollars, but they contribute a lot of code.
This came up during the X-Plane 9 and 10 Linux discussions. Our primary request to Linux users has been “please support each other”. There are too many Linux distributions for us to provide support; our dedicated support staff does not even have Linux expertise, so Linux support immediately hits engineering.
While a number of Linux users have really done a great job of helping other users out, another issue came up. One of the ways we try to minimize Linux-specific costs is to keep the OS-specific code very basic and rudimentary. In the past we’ve taken patches from users to fix OS specific bugs, but this is an awkward process at best.
Some Linux users asked if we could find a way to release source to the OS-specific parts of X-Plane so that they could improve the Linux-specific code (and thus the platform-specific experience) themselves. Right now this is a very awkward process: I have to tell the user “give me a snippet that does X” and then hope that I can get the snippet integrated and tested on my own.
One of the suggestions that came up at the time was to separate out some of the code that abstracts the OS/hardware so that Linux users could patch it more easily.
A Hard Abstraction
Separating out the platform specific code is a good idea, but it wasn’t one we were going to drop everything to pursue – if we did, the end result would be no improvement to X-Plane after some number of weeks of heavy development. Instead, we are slowly moving the code in this direction as we work on it.
The first code to get a work-over is the joystick code; Chris has been refactoring the joystick code for a few weeks now. 10.10 won’t show you any new behavior; it runs the existing UI on top of new low level code. Once we are sure this works, Chris can implement a bunch of new joystick UI features on top of the new low level code quite easily.
The new joystick code separates out the OS-specific joystick interface code from the rest of X-Plane. In the long term, this will make it practical for us to share the hardware abstraction code with users as source, take patches, and even allow developers to swap it out on their local development machines via a shared object. We’re not there yet with this level of flexibility, but the new code makes these things possible.
You Can Keep Your Hat On
There is one immediate win to the new code that will be apparent to Linux users in X-Plane 10.10: the new code (which is based on input.h instead of joystick.h) recognizes hat switches as a set of buttons, rather than a pair of axes; this is almost certainly better from a UI configuration standpoint.