The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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

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: https://hg.libsdl.org/SDL/file/e3e00f8e6b91/README-linux.txt




2013/11/22 WK1




--
Gabriel.

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sik the hedgehog wrote:

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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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



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



Tried that and it didn't work for me.



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.

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?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.