****EDIT: There’s apparently an issue for people running the Vive and WMR where they’re seeing reduced resolution. We’re looking into it and will post an update as soon as possible.
****EDIT2: We’ve found the issue affecting Vive and WMR. We’re testing a fix internally and will release an update hopefully in the next 24 hours. Please do not submit any more bug reports about Vive/WMR resolution.
11.20 VR4 is Live on the servers. Aside from the usability fixes that Ben already mentioned, the major ‘feature’ in VR4 is…Oculus users will no longer need SteamVR. If you downloaded it just for X-Plane, go ahead and remove it. It will no longer be necessary.
As we said we would do from the very beginning, we investigated the relative performance of X-Plane through the native Oculus SDK versus SteamVR and what we found, through data collection,is that the overall experience for Oculus users was better by going through the Oculus SDK directly. I know many of you are thinking “Duh! I told you that a month ago ya big dummy!” and yes…yes you did. Fortunately/Unfortunately, we try not to make engineering decisions based on gut feelings and anecdotal evidence when we have a way to collect actual numbers. We wanted to tackle a majority of the usability issues affecting everyone before we looked into performance.
In the various A/B tests that we performed, we found that going to the Oculus SDK directly got us about 25% improvement in frame rate. This does not necessarily indicate that there’s anything wrong with SteamVR itself. There are several factors influencing the performance in VR. First, Oculus has their “home”, that little bachelor pad where you hang out while waiting for games to load. SteamVR has their “home” as well. When you use SteamVR, BOTH are running on your machine. Those houses are not free and X-Plane is already CPU bottlenecked so anything consuming CPU resources is going to directly affect performance. (I noticed an Autodesk updater in my task manager that was stealing 5% of my CPU consistently. That too was decreasing my performance….every bit matters!). Going directly to the Oculus SDK removes the SteamVR house from the equation.
Sure, getting 25% improvement is a huge win, but that’s NOT the biggest win. The biggest win, in my opinion, is that Asynchronous Space Warp (ASW) works MUCH better even at very low frames rates down to about 22.5fps. It appears as though the timing of the frames is critical for ASW to work properly. Being at 22.5, 30, 45, 90fps feels smooth! Being in between those frame timings seems to make ASW lose its mind creating an annoying judder; the opposite of what ASW is supposed to be doing for us. Oculus seems to be V-Syncing us to hit those intervals, allowing their algorithms to make reliable timing decisions and predictions. It’s my suspicion that SteamVR was just not hitting those intervals, causing ASW to flip out.
TLDR; Performance for Oculus will be on par with what Vive users have been seeing all along. The smoothness of the rendering seems consistent even down to 22.5fps. If you’re a Vive user, you will still, of course, need SteamVR as that IS your native SDK. If you’re a WMR user, you will still need SteamVR. I have not seen any reprojection issues with WMR like we have with Oculus. Supposedly the upcoming versions of SteamVR have some performance improvements coming for WMR users as well so we’ll be sticking with SteamVR for all headsets other than Oculus. That can always change in the future…based on data.
Set your updaters to grab the latest Beta and you’ll find yourselves with VR2 Preview Release. We put a lot of time into this release in an attempt to tackle as many of the usability issues of the VR1 release as we could. (Steam users — VR2 should be available as a public beta on Steam sometime this weekend, as soon as Philipp gets it uploaded.)
Important Note: If you are trying to run VR2 on an X-Plane install that was previously running FlyInside’s plugin, you might experience a crash on startup. We suggest installing VR2 to a fresh copy of X-Plane on your hard drive. If you can’t do that, you might need to uninstall FlyInside and reset your X-Plane preferences.
EDIT: There is currently a known issue with the Thrustmaster HOTAS causing the sim to crash. We’re looking into this and once it’s fixed, we will release VR3 which will address this issue and possibly others should they arise in the next 48 hours or so. For now, if you want to use VR2, you’ll need to do so without your HOTAS.
I’ll enumerate the major headliner features/improvements and talk about them individually, but first, let me be clear what is NOT in this release. This release will NOT dramatically improve the performance or reduce judder for any VR platforms. The goal of VR2 is to address usability for all users. Read More
After an intense year of development and a few demos of the technology at various Flight Simulator conferences, it’s finally time to let you all in on a preview of X-Plane 11 with VR support built-in! I will admit that I personally thought this was another technologic fad that was going to fade without ever gaining traction but I’m happy to say that I think I was wrong. Once you try a VR headset, you’ll never want to fly without one again. For the first time EVER, you can fly precisely and accurately by looking around and interacting with the cockpit without being anchored to a narrow field of view and small clickable hotspots viewed from unnatural angles. VR lets you have unlimited freedoms to move your head and body around naturally. You also get a sense of scale for the first time. Objects and manipulators are the right sizes and distances…just stand next to the tires or engines on one of the airliners and you’ll understand what I mean by scale. Read More
Things have been quiet with the mobile product recently but that’s only because we have been working on some new features that we didn’t want to talk about until we had them running reasonably well on a variety of devices. Well, we have made some great progress and now I’m happy to start talking about it.
What’s the big secret?
So what have we been working on…..? Taking the entire X-Plane 10 Desktop flight model and aircraft systems! That means all of the physics, all of the systems, all of the datarefs, as well as 99.9% of the panel system and instruments*. I cannot emphasize enough how unprecedented this is on a mobile device…and it will be free of course. Read on for specifics…
Flight Model History
Let’s rewind time back to 2007 when the original iPhone was being released. We had about 25MB of memory to work with and a very limited processor. There was absolutely no choice but to prune the flight physics and all of the systems back to the bare minimum. This has been our mobile product’s foundation for the past 9 years…a reasonably good approximation of flight physics and systems that is adequate for mobile devices…but very limiting for us as developers and also a bit limiting for users as well. Lately, we’ve been moving over pieces of the desktop flight model a little bit at a time (for example, Airliners required a better slat and flap system) but it’s time consuming and tedious.
Where we’re headed…
Over the last couple of months we’ve been reorganizing our systems and now have most of the desktop systems running on our mobile product…even on the older devices that we support like the original iPad Mini/iPad 2/iPhone 4s. We’re still actively integrating the systems so it’s not ready for release just yet, but a lot of the work is done.
So what does this mean for users? Archimedes said “Give me a lever and a place to stand and I will move the earth.” The mobile product sharing the flight model and systems with desktop is a HUGE….MASSIVE….LEVER. It means that mobile instantly gets an FAA Approved flight model…the same one that real pilots train on. An instantly improved autopilot, no more bounced landings (unless you fly like Ben…in which case you’ll still bounce ;)) full electrical, hydraulic, engine, prop, fuel, radios, navigation, pressurization, starter, trim and gear systems.
With all of those systems available in their entirety, it means that the beautiful 3D cockpits that our artists have been developing can come to life with interactivity to touch and manipulate all of the same systems that you can on desktop. Start/Shutdown the aircraft the right way, tune all of the radios, operate the full autopilot etc.
This is the symbiotic relationship that we’ve been talking about since the launch of V10 Mobile. Mobile feature development will improve the Desktop product, and Desktop features will trickle down into the Mobile product.
When is this happening?
Soon? I expect much of this to be done and the first update to happen by the spring for iOS and Android. It will not be done in one release but over several.
The release schedule and contents are still not completely concrete at this point but if I were to take a guess, I’d say that the first release will include the complete flight model. This will be an incremental update for end users because while the flight dynamics will change, the interaction will not change much. It will have the same simple 3 button autopilot and minimal interactivity with the 3D cockpit.
The second and subsequent releases will start to expose much of this new system to users. I would expect to see a new 2D autopilot UI that exposes the complexity of the desktop autopilot…heading, altitude, speed, LNAV, VNAV etc. I would also expect that some of the aircraft panels will have been updated with manipulators that allow you to start touching all kinds of buttons and knobs.
With this kind of leverage, we can release new features faster than ever before. I’ll have more details on that specifically when the time is appropriate.
*We will not have a working 430/530 on mobile in the short term nor will we have a few very uncommon and extreme instruments.
It’s been a while since I’ve written a blog entry because…I’ve been working in the dungeons, coding for Android, unlike Ben who spends his days at Starbucks sipping lattes and writing blog posts all day. 🙂
Seriously, if you have not yet heard, we’ve finally released X-Plane 10 for Android. It was a long, arduous process. Maybe I’ll write about the experience in a separate blog post if anyone’s interested. Anyway, back to the product…It has the same features and pricing model as X-Plane 10 for iPhone/iPad and will remain that way for the foreseeable future. I don’t expect Android to lag behind like it has in the past. If anything, it will probably be the first to get updates since there’s no painfully slow Apple approval process to sit through.
Where’s the iOS Update?
This initial release on Android is identical to the current release 10.1.0 on iOS except for the additional of liveries! This update will be available for iOS as soon as Apple approves it. It’s currently sitting in their queue.
What’s the Android Plan?
Currently I’m in firefighting mode! As of today, there are 7,654 supported devices so needless to say, there are some device-specific crash bugs…most on devices that I was not able to acquire myself during testing. I’ll admit however, there are fewer than I expected. We’re currently seeing 90.4% crash-free users. This is low compared to our iOS stability of 99.5% however the industry metric for games is supposedly 97%. I can’t remember where I read that, but that’s been my pseudo-goal so I plan on releasing frequent patches until we get there.
Aside from hardware-specific OpenGL issues, the biggest source of instability seems to be with Google’s In-App Billing service. I’ve found and fixed some issues in their sample code which will help, but many users cannot even link up with the service! I have not gotten enough data to fully understand that yet.
An update to 10.1.4 has been pushed this morning. It should go live in a couple of hours. That should fix stability issues for some people but I don’t expect it to move the needle significantly until the In-App Billing issues have been resolved. Until then, I’ll keep at it!
What’s next for Mobile?
Android is a top priority at the moment. Until we reach stability there, almost all of my efforts will be focused on doing so. Once Android has settled down a bit, the work that we do will be for both platforms.
I know the map is a source of annoyance for a lot of people. It appears, unsolicited, when trying to operate the throttle. I can look into that.
We do of course have more aircraft and missions coming. I can’t talk about the specifics of those yet but our artists are very busy at work making more stunning planes.
But where’s the “meat and potatoes” features? Unfortunately, a lot of the feedback that I get is not specific enough for us to use. I see things like “I like Infinite Flight/Aerofly better!” which is fine…that’s a matter of preference. But WHY do you like it better? What features are you missing most?
So here’s your chance to chime in. What’s important to you? What will make the app fit your needs better? Please feel free to comment below. Get your friends to comment too. The more feedback that I get, the more I can make sure our customer’s needs are being met.
We’ve been quiet on the Android front for X-Plane 10 Mobile but typically around here, quiet is a good thing because it means we’re busy!
We’ve put in a lot of effort and we’re at a point now where we’re going to begin testing the product. More on that in a minute…
First, I’m excited to say that for the first time, our iOS and our Android products will be the same! In the past, Android came around much later than iOS did and the Android operating system and the devices running it were quite a bit behind Apple’s so we had to make our Android product different. This is no longer the case. Google offers all of the same amenities that we’re currently using on iOS. We will have leaderboards, achievements and multiplayer. The product itself will be effectively identical. It’s the same X-Plane Engine, flight model, scenery packages, aircraft etc. There will be no teaser screenshots because…well….it looks exactly the same as all of the iOS screenshots that we’ve already been posting.
Our goal, once the Android version is released, is to keep the iOS and Android products simultaneously up to date. If a new feature is added to one platform, it will be available on the other platform almost immediately (store approval times permitting).
We’re going to begin testing relatively soon. I have a few odds and ends to tie up before we’ll be ready to go but i’d say in the next week or so we’ll begin our first round. If you want to be considered to be a tester, you can click on the link and submit a request. There’s no guarantee that you’ll get in. We can’t play favorites.
This testing will be slightly different from the norm. Typically we let users Beta test our products to find some bugs early and help us stabilize. With Android however, our goal is to release an early Alpha version to a small number of users and then slowly increase the size of the test group until we’re confident that it’s running properly on a wide range of devices. Then we will expand the group even more and begin Beta testing per usual.
Why are we doing things differently? With iOS, we had one operating system version to worry about (iOS 8) and twelve different devices (every supported iPhone and iPad) running one brand of GPU to test against. Between Ben, Tyler and myself, we essentially own one of everything. On Android, we have three (4.1.X, 4.4.X and 5.X) operating system versions, four major GPU manufacturers and (wait for it….) over six thousand different devices. Needless to say, we do not own one of everything! We need to ease into the testing to find driver issues and other device-specific problems early which is why we’re doing the Alpha test.
We’re mainly focused on testing the Android-specific pieces because 90% of the code is the same as what’s running on iOS which has already been thoroughly tested.
When will it be released?!
As soon as it’s ready! Awwww (sad face), I know you hate that answer…but it’s true. Our goal is to release it as soon as testing shows that it’s stable! This will probably be in a number of weeks, not days but also not likely months.
Hi Guys, it’s Chris. I haven’t written a blog post in ages. They’ve kept me locked in the basement like Milton Waddams, unwilling to let me out to see daylight until I finished X-Plane 10 Mobile. And they stole my #$%#^ stapler!
“Where’s the Android version? 60% of all smartphones run on Android but I guess that Apple-Fan-Boys are more important in your company”
“Why do you guys constantly focus on iPhone first when most users are on Android?”
Before I get into the real point of the blog post, allow me to answer some of those questions. YES we are planning on shipping X-Plane 10 Mobile for Android. YES we have already begun development. We do not have a release date. We do not have any hints. The only thing that I can say, is that we want it out just as soon as you do. NO we do not view Android as a lesser/inferior platform…We value Android customers just as much as we value our iOS customers. A customer is a customer. I think we’ve demonstrated by supporting Windows, Mac and Linux all these years that we’re not trying to play favorites. We want everyone to be able to enjoy our products. BUT, that doesn’t mean that the costs of development and the speed and efficiency of development is equal on all platforms.
Historically, we’ve always developed for iOS first and then Android second. I’d like to be open an honest about our reasons and hope that even if you disagree with them, you’ll at least understand why we have historically developed for Apple first. I will warn you, everything I have to say is completely my opinion, my impression, my feeling based on my experiences. I’m going to sound a lot like an Apple “fanboy”. I will admit, I do have a high level of respect for Apple’s commitment to polish and detail, but I also own a dozen android devices and respect them for their cutting edge features, their openness and their friendliness to customization.
At the end of the day however, I’m paid to be efficient and thorough and my thoughts below explain why that means Apple has historically come first.
I will also warn you…I don’t want this blog post to turn into a flame war between Apple and Android users. We’re talking about phones here people, not religion. At the end of the day, they’re just small piles of plastic and silicon that let us surf the web, make phone calls and play games.
We Can’t Develop Apple and Android In Parallel
Sure, we do this on desktop by releasing Windows, Mac and Linux versions in unison 100% of the time. Developing for desktop is pretty different than developing for mobile. We use very few 3rd party frameworks on desktop and it’s an open environment. On a mobile phone, it’s a very closed environment. What this means is that developing Apple and Android in parallel requires a lot more effort than developing for Windows and Mac in parallel.
Can it be done? Absolutely! Plenty of companies are doing it. But they also have large teams with large expenses. We’re still a pretty small group of individuals and we like it that way. The tradeoff however is that we can only focus on one platform at a time.
One alternative that we could consider is delaying shipment of an Apple product until the Android version is done as well. That’s a loss for everyone. Apple customers lose out on having the latest software and Android customers may lose because…we don’t have the revenue coming in to support the Android development costs. That’s right…Apple sales get reinvested into the company to fund Android development!
As Ben mentioned earlier…Apple and Android mobile sales fund desktop development…and desktop development funds mobile development! This is a very important fact to remember. I’ll admit, we laugh and roll our eyes when desktop users complain about the company working on mobile products, and mobile users complain about the company working on desktop products….and android users complaining about us working on apple products and vice versa.
The company has found equilibrium creating both desktop and mobile products. There’s adequate revenue to fund adequate staffing to continue to develop both.
We Develop On Mac Hardware
This is no secret. It’s been this way since the company started. We just find Apple products allow us to be more productive and don’t get in our way.
Historically, Apple’s Mobile Platform Has Been More Mature
Apple had both a technological advantage as well as a time advantage over Android when they began.
Apple already had an Operating System, supporting frameworks and a development environment to leverage. Making mobile versions of those things required them to port existing, time-tested code to a new platform. From a stability standpoint, Apple had the advantage in that they already had the code, the engineers and the process in place to do this.
On the other hand, Google had to start from scratch. They had to put together a new team to create a new operating system to run new frameworks…and they had to create a set of tools for developers to use.
In addition to all of the technological advantages Apple had, they also had a head-start of well over a year. We were already selling X-Plane V9 for mobile before Android was even announced publicly.
That meant we were already established and familiar with the iOS platform as developers.
When I began the Android port for X-Plane V9, I had to pretty quickly put it down…and wait. Android at the time only supported Java apps. X-Plane is NOT a Java app. 99% of it is written in C/C++ and Android had absolutely no support at the time…and so we waited….and waited….and waited.
Finally, many months later, Android added their NDK which allowed us to have C/C++ support. But it was completely minimal. None of the standard libraries that we were used to using were available. This meant a lot of effort on our part to get anything done. If you’re not a developer, a reasonable metaphor might be a carpenter that’s trying to build a house, but he first has to build his own hammer, nails, square and saw because the tools he’s used to using don’t exist on this job.
Finally it came time to release V9 for Android. For iPhone/iPad, we uploaded our 400+mb app to their store and we were done. On Android however, the store had a limit of 25MB. So that meant we had to buy servers and write code to download the resources from a farm of servers. Again, this added more time and more complexity.
Apple Has Fewer Devices
For this latest release of X-Plane Mobile, we support iPhone 4S/5/5S/6/6+ as well as iPad 2/3/4/Air/Air2/Mini/Mini2 and iPod Touch 5. That’s 13 devices to my recollection. But it’s even simpler than that…because they all have the same GPU manufacturer, they all support the same PVR texture compression, and they all pretty much just work interchangeably from a development standpoint. The only major differences between them are the processor speeds and the screen resolutions. We can literally test on every single device and be sure that the app runs the way we expect it to.
As of the time of this writing, our X-Plane V9 is running on 7,072 devices. You read that right….SEVEN…..THOUSAND…..DIFFERENT……DEVICES. Each device has a different combination of CPU, GPU, screen size, screen density and drivers. We cannot possibly test them all. Admittedly, many of them “just work” and there are of course only a handful of CPU and GPU manufacturers to worry about…but at the very least, it means at least three different texture compression formats. PVR is proprietary and unless the mobile device has a PowerVR chipset, they’re not going to get PVR. So we have to support various formats. That requires three different versions of our app to be created and tested and distributed. That requires three different resource packages to be created and tested.
There’s just no way to have the same level of stability as we can have with the iPhone/iPad platform.
Apple Has Higher OS Upgrade Adoption
Without carriers and other manufacturers getting in the way, Apple can release a new OS with features and bug fixes, and we can be sure that they exist on the majority of the devices that we care about in no time. This means that if there’s a driver issue that needs fixing, it will make it out to the masses and eventually the problem is gone.
Android’s fragmentation has really hurt them in this area. We encountered several devices over the years that violated some OpenGL spec. We worked with the manufacturer to isolate the issue. They release a patch to fix the issue…and most users never had a way to get the patch because their phone carrier dropped support for that phone model.
Now the user’s stuck with an App that they paid for that doesn’t work and there’s nothing that we can do about it.
We like Apple’s Developer Tools Better
As I mentioned earlier, Apple’s developer IDE has been around for ages. We have access to various performance analyzers and can now even analyze an entire OpenGL frame, one draw call at a time. This means we can really tune the crap out of the app before we make it public. In addition, all of the tools come in a single package that just works out of the box. Apple has also always had a simulator that’s hardware accelerated. This means for a lot of things, i don’t need a device plugged into the computer to debug something.
Android’s solution was for less “out of the box” in that they were using various open-source pieces that all had to be installed and fit together just right. Android had an emulator that was not hardware accelerated. It took longer just to boot than it took me to find a phone in my house, get it, plug it in and push an app to it.
Honestly, I think both sets of IDEs are sorely lagging behind features that Microsoft’s Visual Studio has had since 2000, but I digress.
We develop for Apple first because it’s easier and faster for us. It allows us to get the product out the door, running as efficiently and as reliably as possible. When we port the app for Android development, we can be sure that most bugs that come up are specific to Android and are therefore much easier to resolve in a timely fashion.
We are not playing favorites. We have no personal issues with Android and have no personal ties to Apple. The day that Android becomes the faster and easier platform to develop for, it will be the one that we develop for first. It’s just a business decision!
In the meantime, Android users should remember that the way things are currently being done means that they sometimes have to wait longer for new updates, but the updates that they receive will likely be more stable as they’ve been tested harder.
I will also note that we are closing the time gap between iPhone and Android releases. In the past, we were over a year behind on the Android release…because Android didn’t exist. 🙂 Now that it’s becoming more established, the gap should be shrinking more and more.
I’ve just uploaded some new videos to the official X-Plane YouTube video channel. These videos are screencast tutorials for airport authors to help them understand the ATC Airport Flow feature in X-Plane v10.
ATC Airport Flows are essentially a set of rules that control how the runways are used for airport operations. An airport like Chicago’s O’Hare (KORD) for example has 7 runways (14 different takeoff/landing directions)! ATC does not simply put aircraft wherever they feel like in the moment or there’d be a massive aluminum traffic jam. They have a set of rules that control which runway(s) are in active and inactive at any given time. These rules are typically based on two main criteria: weather conditions and time of day.
In the real world, at major airports, traffic studies are done to decide which runway combinations are most efficient for traffic flow, safety and workload and those combinations of runways become active when the conditions are just right.
Once the controller deems certain runways active/inactive for the current conditions, there are yet more rules to determine which types of aircraft use each of those runways. For example, if a small Pilatus is flying into KORD, I strongly doubt they’re going to block up their major runways for arrivals for a small single engine turbo prop. They’re likely to put him on a smaller accessory runway. Also consider some airports which only use certain runways for arrivals while other runways are only used for departures. This is often done for noise abatement or obstacle avoidance. These types of rules can be included in the ATC Airport Flow.
Our goal was to give authors enough granularity to closely mimic the way real airports are run so that when X-Plane’s ATC is in action, it’s towers can make similar decisions to the real controllers.
Well as I promised (11 months ago), here’s a tutorial on making ATC Taxi Networks in WorldEditor v1.2. Hopefully this clears up some misunderstandings about how the pieces of the system work and how they’re meant to be used. Perhaps the next video tutorial will be on creating Airport flows to teach ATC which runways get used for which operations.
Edit: see the end of the article for a GUI tool to manage joystick permissions.
I’ve already briefly discussed some of the changes necessary to get joystick devices working properly but I thought it’d be a good idea to consolidate all information into one post for easy reference as 10.10 is nearing it’s release to the masses.
First, why the change? In the past we used the “joystick” interface to joystick devices on Linux. This interface is extremely basic and is really only useful to games that require minimal knowledge of the actual hardware. X-Plane really does not fit this specification at all. X-Plane needs to work with the spectrum of hardware from the most basic one axis trim wheel to the most complicated home-built cockpits that have dozens of axis and literally hundreds of buttons and switches. In order to support this properly, in 10.10 we’ve switched from using the “joystick” interface to using the “input” interface. This gives us ALMOST the same quality of low level access to the hardware that we get on Win/Mac. The problem with using the “input” interface is that almost anything can be an input. Your keyboard and mouse for example are “inputs”. As linux is a multi-user operating system, there are permissions concerns regarding input device reading. You wouldn’t want another user snooping on your keyboard as you’re typing credit card numbers would you? Many Linux distros by default restrict access to these devices with some exceptions handled in ACLs. If the device LOOKS like a joystick, anyone’s allowed to access it since the security risk associated with joysticks are pretty much zero. But the definition of a joystick is something that has two axis and some buttons. Therein lies the problem. Rudder pedals don’t have any buttons. Trim wheels don’t have any buttons either and they only have one axis. Because of this, the ACL for the devices does not kick in and you now need root access to read from the device.
The solution…run X-Plane as root! I’m joking though some people will have no problem doing this. If you’re cool with that, be my guest but it’s generally not regarded as a safe way to run a system. For the rest of the population, there are rules than can be created that will detect your hardware and automatically set the permissions appropriately so that X-Plane can access the hardware. These are called UDEV rules. For a typical Linux user, creating a UDEV rule should be walk in the park but for a novice it might seem tricky. Luckily, it only needs to be done once and will work for good.
A big thank you goes out to Bill Good who is a member of the X-Plane.org community. He put together this tutorial for you guys to benefit from.
This is an optional step but it really makes things easier. Each piece of hardware has a Vendor ID and a Product ID. These are called the VID and PID in industry. These two ID’s together are used to detect a device’s existence. You’ll need to know the VID and PID of each device that you care about. To determine this, you can get a tool called “lsinput” which makes this a bit easier. Just run “sudo apt-get install input-utils” on a debian based system. If you’re Red Hat based, i’m sure you can run the similar “YUM” command.
Run “sudo lsinput” which will list all /dev/input/event ‘s that are attached to the system. Find the hardware that you care about. Here’s a sample output for a Saitek Pro Flight Rudder. Notice the Vendor and Product lines which have hex values of 6A3 and 763 respectively. That’s what we need.
bustype : BUS_USB
vendor : 0x6a3
product : 0x763
version : 273
name : "Saitek Saitek Pro Flight Rudder "
phys : "usb-0000:00:16.2-4.1/input0"
uniq : ""
bits ev : EV_SYN EV_ABS
Create a file called “99-X-Plane_10_Joystick.rules” in your /lib/udev/rules.d/ directory. I’m not sure if this path is distro specific. You may need to look up where udev rules go on your distro. EDIT: Users report that a more appropriate path may be “/etc/udev/rules.d/” which has the added benefit of being a location that gets grabbed by backups. Either path will work fine however.
In the 99-X-Plane_10_Joystick.rules file, create one entry for each device that you wish to include. Put them all in this file…each hardware entry on its own line. Only the ATTRS sections need to be set by you, the rest is boilerplate. Notice the Vendor and Product values of 6A3 and 763 from before in the sample below (Make sure to scroll horizontally. On smaller monitors, the whole string may not be visible).
The last step requires a restart of the system. There MAY be a subsystem that can be restarted instead of taking the whole system down but i’m not aware of what that may be so it’s best to just restart the whole thing.
Update: One enterprising Linux X-Plane user has written an open source GUI tool to manage joystick permissions. Here it is!