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 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…

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 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

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

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.

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.

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.

Interesting…thanks i’ll edit the tutorial!

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.