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.
/dev/input/event6 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).
KERNEL=="event*", ATTRS{idProduct}=="0763", ATTRS{idVendor}=="06a3", MODE="0666" - 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!
Thanks for that! I only see a mistake. ¿How does the (really)novice people will do this?
We’re making the assumption that if you chose linux as your operating system, running a few commands in the terminal is not something that’s outside of your skillset.
Yeah, I agree with that. But now using some Linux distros It’s easier than using Windows(in some way). So , maybe, some new people that are comming to linux will get terrified.
If Linux wants to be competitive with Windows as a home entertainment, game and multimedia OS, it’s going to have to ship with a set of working udev rules that give the user access to his or her gaming hardware out of the box.
My view is that, given the number of cases we’ve seen where the dev/input interface to gaming hardware is not user-accessible, Linux isn’t there yet.
I would like to see someone in the Linux community start pushing udev rules “up-stream” so that distros that target ease-of-use can get around this. I do not think it is the role of applications to try to hack around this, and it’s not the role of LR to get into distro maintenance.
I think there’s still something wrong in the X-Plane developers team.
Linux is widely used by average users nowadays and there are many users using Linux distributions like Ubuntu or Suse without ever using a terminal at all.
And if you as application developer choose to bypass the built-in joystick system of Linux (maybe for good reason in this case), you should not be surprised by some problems occurring. In this case those problems are not very complicated as this is just a permissions problem that can permanently be solved by those udev rules.
It should be clear that you as the X-Plane team provide a working tutorial/manual showing Linux users how to create those udev rules reliably – step by step. In fact it would be better to write a little GUI tool which could be run with gksudo or similar and which could create the needed udev-rules. This tool could be linked in the joystick settings tab in X-Plane intself.
Please remember that you Linux users are paying for your product too. You always say that you don’t earn money with the linux version. But I think if you promise you sim working on linux and one buys it, one can expect that it’s working.
As you see there are many users within the linux community which help each other and you (!) solving problems like these. And they don’t take anything for that – they also provide little tutorials like the one you’ve just published with this blog post.
So please don’t always say that Linux users should be clever enough to solve everything themselves. In contrast to your opinion they do not all know everything 😉
By the way: Norbert recommended changing all event*’s permissions to 666 but I guess this could be a bit against security as this could also have effect on keyboard read permissions, or am I wrong here? This way “everybody” could read your keystrokes…
Additionally it is possible to run X-Plane with sudo and all joysticks will be working – but I do not recommend this too…
Once again thanks to Chris and Bill for helping me with my udev problem…
Hi Lucas,
I think we (LR) have tried to be as clear as possible about the level of support we can provide for Linux, particularly in posts like this one.
http:/2012/05/linux-and-hardwareos-abstractions/
From our side of things, it’s simple business:
– Linux represents a small fraction of our user base.
– Linux represents the most hostile OS platform for game development. (If you think it is easier to develop, ship and maintain binary joystick code, sound code, or graphics code on Linux than on Mac/Win, then you are deluding yourself.)
– Something has to give.
That something is the Linux community changing the equation of support by taking care of each other, which the Linux X-Plane community has done a great job of doing over the past few years.
I am trying to make Linux “more viable” from a business model by open sourcing the Linux HAL, per my previous post – I have made some progress on this front but I don’t know when we’ll be able to productize a customizable HAL.
But re: paying customers, I think we simply disagree on expectations. We believe we can make things ‘just work’ on Windows. We don’t think we can do that on Linux while still letting you pick _any_ distro with any version. The Linux community has more variation and more change, while Microsoft puts a tremendous amount of effort into keeping Windows stable for binary apps.
Cheers
Ben
I wrote a short script to produce the rules file. You need the packages
input-utils grep gawk
then the commandline (one line)
lsinput | egrep “vendor|product|name” | gawk ‘BEGIN{FS=”:”}{x[i++]=$2; if (i==3){i=0; printf (“#%s\nKERNEL==\”event*\”, ATTRS{idProduct}==\”%s\”, ATTRS{idVendor}==\”%s\”, MODE=\”0666\”\n\n”,x[2],substr(x[1],4),substr(x[0],4))}}’
produces the neccessary udev line for all connected devices. Cut and paste all X-Plane devices to the file /etc/udev/rules.d/99-X-Plane_10_Joystick.rules
Path /lib/udev/rules.d/ doesn’t distro specific but I recommend use /etc/udev/rules.d/ not because it has higher priority but because it is backed up rather. But both paths will work of course.
Interesting…thanks i’ll edit the tutorial!
The man page in debias says:
The udev rules are read from the files located in the default rules
directory /lib/udev/rules.d/, the custom rules directory
/etc/udev/rules.d/ and the temporary rules directory
/run/udev/rules.d/.
My interpretation is, that the distribution keeps its rules in /lib and custom rules like those for joysticks or permanent network devices (ethX) are kept in /etc
Instead of a restart, you can also just run
sudo chmod 0666 /dev/input/eventX
for each device you found with lsinput. (X has to be replaced by the acutal number of the device)
Sure that’ll work but that will work exactly once. As soon as you unplug the device or restart the computer you’ll have to do it again. The UDEV rule is permanent.
This was not ment as an alternative to the udev rules, but as a faster way to get the right permissions after setting up udev compared to the suggested restart in step 5.