SDL2 requires root privileges to use joysticks in Linux

SDL Development
1

SDL2 has dropped support for the Joystick API (/dev/input/js*) in Linux. It now only uses the Event API (/dev/input/event*) for joysticks. In many cases, these event device files are not readable by unprivileged users, and so your joystick won’t work.

If you use Linux, and your Joystick works with SDL1.2 but not SDL2, the following steps will probably allow you to use your joystick:

0: Make sure your joystick is plugged in.

1: Download the following file and move it to /etc/udev/rules.d/
http://wntrknit.freeshell.org/sdl2-joysticks/99-joystick.rules

2: Download the package input-utils. As root, run the command lsinput. You will get some details about all of your event devices. Look for the one that corresponds to your joystick, and make note of the vendor id and product id. Alternatively, you can run lsusb or dmesg.

3: In the file you downloaded, replace 9999 with the vendor id of your device, and replace 8888 with the product id of your device.

4: For additional joysticks, add lines to the 99-joystick.rules file, one for each joystick.

4: Your joystick devices will have world readable permissions at your next reboot. You can also change the permissions manually, unplug and replug your joysticks, or unload and reload the modules with modprobe.

I think it’s unfortunate that this is necessary. It’s not particularly beginner friendly, and if your joysticks just don’t work you won’t know why. I don’t think SDL should alter permissions of event devices or udev rules, as that is more the responsibility of distro and system maintainers.

However, I think people who run into this problem would appreciate an error message that tells them what the problem is. I have supplied a link to a patch against the latest mercurial that displays a message if there are joysticks detected but SDL can’t use them. It uses different logic with and without libudev, I expect both to be very reliable.

http://wntrknit.freeshell.org/sdl2-joysticks/sdl2-joystick-permission-error-notification.patch

2

The README-linux.txt explains this situation. It varies with each distro,
there’s not much SDL can do, but it’s an easy fix for the end user.

BTW, you can probably match by ENV{ID_INPUT_JOYSTICK}==1 instead of vendor
and product, making it a more generic rule that will apply to all joysticks
identified as such by udev.

Ref: SDL/README-linux.txt at e9af6dcd93e92013198ec7cc8445555632b86c37 · libsdl-org/SDL · GitHub

2013/11/22 WK1 > SDL2 has dropped support for the Joystick API (/dev/input/js*) in Linux.

It now only uses the Event API (/dev/input/event*) for joysticks. In many
cases, these event device files are not readable by unprivileged users, and
so your joystick won’t work.

If you use Linux, and your Joystick works with SDL1.2 but not SDL2, the
following steps will probably allow you to use your joystick:

0: Make sure your joystick is plugged in.

1: Download the following file and move it to /etc/udev/rules.d/
http://wntrknit.freeshell.org/sdl2-joysticks/99-joystick.rules

2: Download the package input-utils. As root, run the command lsinput. You
will get some details about all of your event devices. Look for the one
that corresponds to your joystick, and make note of the vendor id and
product id. Alternatively, you can run lsusb or dmesg.

3: In the file you downloaded, replace 9999 with the vendor id of your
device, and replace 8888 with the product id of your device.

4: For additional joysticks, add lines to the 99-joystick.rules file, one
for each joystick.

4: Your joystick devices will have world readable permissions at your next
reboot. You can also change the permissions manually, unplug and replug
your joysticks, or unload and reload the modules with modprobe.

I think it’s unfortunate that this is necessary. It’s not particularly
beginner friendly, and if your joysticks just don’t work you won’t know
why. I don’t think SDL should alter permissions of event devices or udev
rules, as that is more the responsibility of distro and system maintainers.

However, I think people who run into this problem would appreciate an
error message that tells them what the problem is. I have supplied a link
to a patch against the latest mercurial that displays a message if there
are joysticks detected but SDL can’t use them. It uses different logic with
and without libudev, I expect both to be very reliable.

http://wntrknit.freeshell.org/sdl2-joysticks/sdl2-joystick-permission-error-notification.patch

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Gabriel.

3

Does anybody know which distros are affected? (definitely not Ubuntu,
since my joystick works just fine here)

4

Sik the hedgehog wrote:

Does anybody know which distros are affected? (definitely not Ubuntu,
since my joystick works just fine here)

I understand that udev only sets ACL entries for the joystick when the
session is active and non-remote. This requires a display manager that
interacts with logind or the session will be inactive. At least that’s
what I experienced on Arch with systemd.

5

[quote=“gabomdq”]The README-linux.txt explains this situation.

So it does. Unfortunately, end users will rarely download the source code for library dependencies and read the README files.

[quote=“gabomdq”]there’s not much SDL can do

SDL can’t fix it outright, but I suggested a little something that SDL can do.

gabomdq wrote:

but it’s an easy fix for the end user.

It’s only an easy fix if you know what to do. That’s why I think an error message will help.

gabomdq wrote:

BTW, you can probably match by ENV{ID_INPUT_JOYSTICK}==1 instead of vendor and product, making it a more generic rule that will apply to all joysticks identified as such by udev.

Tried that and it didn’t work for me.

Sik wrote:

Does anybody know which distros are affected? (definitely not Ubuntu, since my joystick works just fine here)

It depends on a variety of factors. Norfanin mentioned one. I read that whether or not the joystick has buttons is another. I’m not sure if any distros are immune to the problem.

6

Linux
Message-ID: <1385256792.m2f.40841 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

[quote=“gabomdq”]The README-linux.txt explains this situation.

So it does. Unfortunately, end users will rarely download the source code
for library dependencies and read the README files.

[quote=“gabomdq”]there’s not much SDL can do

SDL can’t fix it outright, but I suggested a little something that SDL can
do.

gabomdq wrote:

but it’s an easy fix for the end user.

It’s only an easy fix if you know what to do. That’s why I think an error
message will help.

I think that developers would tend to take a dim view of this ALWAYS
happening. I was initially thinking maybe a callback would be the way
to implement (sort of like the assertion support: if you don’t set a
handler, then a default action occurs, in this case by popping up a
message box), but on further consideration, an event + a hint to
control event vs message box vs silence would probably be ideal.
Here’s the reasoning:

  1. There’s plenty of spots in the SDL_EventType enum,
  2. we’re just talking about one or two char strings so we don’t have
    to worry about structure size,
  3. it allows programs to display the message in their own way if they want,
  4. it further leverages the already existing event-filter/event-watch
    infrastructure, thereby providing callback functionality for those
    developers who so prefer,
  5. it allows the event to be used for any further such messages,
    thereby leveraging any DEVELOPER support for this problem without the
    developers doing anything further, and
  6. it still allows showing the message explaining the problem and how
    to fix it if the application has no idea about this subject at all.

The event type would presumably be something like SDL_ALERT, with the
event itself maybe being something like this:
typedef struct SDL_alertevent
{
Uint32 type;
Uint32 timestamp;

    Sint32 severity; /* Negative for errors, positive for warnings. */

    const char *subsystem;
    const char *message;
} SDL_alertevent;

The hint would maybe be SDL_HINT_JOYPERMISSIONS_ERROR, with the
accepted values probably being “suppress”, “event”, and “messagebox”.
“messagebox” would, of course, be the default so that a user would be
told even for programs where the programmers didn’t have any idea that
the problem existed.

Thoughts?> Date: Sun, 24 Nov 2013 01:33:12 +0000

From: “WK1”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL2 requires root privileges to use joysticks in

7

Jared, that looks thorough and well thought out.

Another way would be to have the Joystick subsystem report failure to initialize, and the error string set, when it fails to initialize any joysticks but joysticks are detected. In fact, I think the current behavior of returning success in this case is a bug. If this is the only thing changed, however, then in the event that 1 joystick is detected but another is not due to permission errors, either there won’t be any message reported, or the user won’t be able to use their 1 joystick that is detected.

Jared’s solution is a bit of work, but is the most flexible.