Joystick API

[A. D. Sharpe Sr.]

Hello all. I'll keep this brief:

1. Does anyone know of any game or other piece of software that would be broken if the current joystick driver & API were replaced?

 

[Phishfry]

I like to blow off some steam with Trigger Rally.
It works out of the box with a Logitech F310 gamepad.
I think it uses SDL. I have SDLjoy from github working to calibrate it.
Tried to port joytran with no luck.

Sorry if that does not directly answer your question.
I also use these games with the same gamepad:
ioquake
openarena
TORCS (flaky gamepad)

Not sure what API you are referencing.
SDL is sort of like DirectX from what I can tell.

 

[A. D. Sharpe Sr.]

Not sure what API you are referencing.
SDL is sort of like DirectX from what I can tell.

I'm talking about FreeBSD's native joystick API. Are you playing these games through Linux emulation? I wasn't aware that SDL supported joysticks on FreeBSD. We certainly don't have a real native solution for modern joysticks...yet.

 

[SirDice]

I wasn't aware that SDL supported joysticks on FreeBSD.

MAME also uses SDL for its joystick support.

 

[shkhln]

Eh… It's either SDL or nothing. I'm not aware of anything using /dev/joy*.

We certainly don't have a real native solution for modern joysticks...yet.

We have evdev, but no native drivers and no route to applications. It's easy enough to reuse gamepad drivers from Linux with webcamd, so drivers aren't a huge concern. Applications are somewhat tricky. Again, it's quite easy to compile SDL with evdev backend, but that will disable SDL's UHID backend which is probably not ideal.

 

[A. D. Sharpe Sr.]

We have evdev, but no native drivers and no route to applications. It's easy enough to reuse gamepad drivers from Linux with webcamd, so drivers aren't a huge concern. Applications are somewhat tricky. Again, it's quite easy to compile SDL with evdev backend, but that will disable SDL's UHID backend which is probably not ideal.

That's really the point of me asking. We have no native drivers & no route to applications, but we should have those things. So, I asked my question in order to make sure that I'm not looking into work that may potentially be rejected. We shouldn't have to reused gamepad drivers from Linux, because we should have our own drivers & a way to route them to applications. As far as SDL is concerned, it's also high time for us to have our own game input backend to plug into SDL. Unless it's the FreeBSD community's goal to remain a second class citizen when it comes to these things. As long as this is the status quo, it's kind of difficult to provide a reason for anyone to see FreeBSD as a joke when it comes to gaming. That's something that needs to change, but I didn't want to start even the slightest bit of research into it before making sure that I'm not either stepping on anyone's toes or doing work that no may be frowned upon.

 

[shkhln]

We shouldn't have to reused gamepad drivers from Linux, because we should have our own drivers & a way to route them to applications.

We absolutely should if we can, I see no point in repeating that work.

 

[A. D. Sharpe Sr.]

We absolutely should if we can, I see no point in repeating that work.

Probably because you don't really care whether or not FreeBSD can offer native solutions. Not only should we have our own native solutions, we should also take advantage of the opportunity to provide better solutions that work seamlessly.

 

[shkhln]

What would you do "better"? It's not like there are multiple ways to parse bitmaps with encoded button state coming from a particular gamepad model.

 

[Beastie7]

I agree with shkhln.. drivers are a terribly mundane endeavor to get into and the work involved is almost never ending. We definitely shouldn't re-invent the wheel there. The least we can do is take it and re-factor it so it'll read cleaner, perform better, etc. I fully support FreeBSD having it's own multimedia APIs though.

 

[A. D. Sharpe Sr.]

What would you do "better"? It's not like there are multiple ways to parse bitmaps with encoded button state coming from a particular gamepad model.

First, I'd update the actual FreeBSD joystick API that's already included in the source tree. Second, I'd create an actual usb hid joystick kernel driver, in the same vein as the usb hid drivers that we already have in kernel. Third, I'd create a native userspace routing library that allows joysticks to report their true features. Fourth, I'd interface that library to SDL, so that no one really notices the difference besides the fact that the new solution just works. That's the plan that I'm currently working on. No jumping through hoops or browsing every forum imaginable just to get the same support natively on FreeBSD as you get on other OSes.

 

[A. D. Sharpe Sr.]

I agree with shkhln.. drivers are a terribly mundane endeavor to get into and the work involved is almost never ending. We definitely shouldn't re-invent the wheel there. The least we can do is take it and re-factor it so it'll read cleaner, perform better, etc.

To be honest, this isn't really the case, when it comes to usb joystick driver support. All usb joysticks follow the basics of the usb hid standard. Sure, there may be a few deviations here & there, but they're predominantly the same. I was only testing the waters before I start the work. From what I've seen, there's no reason for me to not do it. And since I'm vehemently against the concept of having to rely on Linux support for infrastructure that we should already have for ourselves, I tend to see such arguments as more of a reason that native solutions should be implemented.

 

[shkhln]

Okay, okay. I shut up and resume my usual hoop jumping routine.

 

[JAW]

First, I'd update the actual FreeBSD joystick API that's already included in the source tree. Second, I'd create an actual usb hid joystick kernel driver, in the same vein as the usb hid drivers that we already have in kernel. Third, I'd create a native userspace routing library that allows joysticks to report their true features. Fourth, I'd interface that library to SDL, so that no one really notices the difference besides the fact that the new solution just works. That's the plan that I'm currently working on. No jumping through hoops or browsing every forum imaginable just to get the same support natively on FreeBSD as you get on other OSes.

This sounds interesting, I wasn't even aware there was a FreeBSD joystick API (do you have a link to a man page handy?)

I'm currently dabbling with writing a cross-platform arcade game (for BSD/Linux/Windows) but it only support gamepads on Windows via the XInput API, it would be great to get some gamepad support on FreeBSD (as I personally use FreeBSD as my development platform).
I have quite a few USB gamepad controllers of various configurations too, so could probably help out with some testing there!

 

[shkhln]

This sounds interesting, I wasn't even aware there was a FreeBSD joystick API (do you have a link to a man page handy?)

There wasn't. It's an interface to a single driver. Here is the manual page.

 

[Phishfry]

Here are the three files:
usr/src/sys/dev/joy/

 

[JAW]

There wasn't. It's an interface to a single driver. Here is the manual page.

Oh wow, that really is a blast from the past, the driver seems to be for the old school 15-pin joystick port! I probably still have my old Microsoft Sidewinder stick gathering dust somewhere from my X-Wing/Tie Fighter days! If I remember correctly that 15-pin port was actually part of the sound card (SoundBlaster?)

 

[PaddyMac]

A. D. Sharpe Sr., I am totally with you. The people touting webcamd and Linux drivers as a solution likely haven't actually tried to use webcamd to get a game controller to work on FreeBSD. I have, and I have had zero success out of three different controllers I've tried. Heck, I've only had a 50% success rate out of two webcams I've tried to get working with it. I'm not a rich man, but I'd pay a bounty of $50...maybe even $100 to a dev who could get game controllers working on FreeBSD without the major headaches, frustration, and failure that is the case now. Honestly, I would pay just to get Xbox and Playstation controllers to be "plug 'n' play" on FreeBSD.

So far, the only success I've had with USB controllers on FreeBSD is to make sure webcamd is *not* loaded so that SDL applications can use it as an HID device. Likewise for the hidd daemon some people suggest using. It doesn't make anything work; it just prevents applications that can access the controller directly from being able to use it.

 

[shkhln]

The people touting webcamd and Linux drivers as a solution likely haven't actually tried to use webcamd to get a game controller to work on FreeBSD.

They used it and it was quite ok.

 

[PaddyMac]

I wish I could find these people and get some help. I've set up webcamd, and it created /dev/input/js0. But the only software I've found on FreeBSD that makes use of /dev/input/js0 is jtest-gtk.

 

[shkhln]

Quit whining. Here is your patch:

diff --git a/devel/sdl20/files/patch-configure.patch b/devel/sdl20/files/patch-configure.patch
new file mode 100644
index 000000000000..3cd58cbaf3f8
--- /dev/null
+++ b/devel/sdl20/files/patch-configure.patch
@@ -0,0 +1,29 @@
+--- configure.orig     2020-03-20 05:38:47.438439000 +0300
++++ configure  2020-03-20 05:39:48.991686000 +0300
+@@ -24475,7 +24475,7 @@
+           ;;
+         esac
+         CheckTslib
+-        CheckUSBHID
++        CheckInputEvents # CheckUSBHID
+         CheckHIDAPI
+         CheckPTHREAD
+         CheckClockGettime
+@@ -24526,7 +24526,7 @@
+         # Set up files for the joystick library
+         if test x$enable_joystick = xyes; then
+           case $ARCH in
+-            linux)
++            linux|freebsd)
+
+ $as_echo "#define SDL_JOYSTICK_LINUX 1" >>confdefs.h
+
+@@ -24547,7 +24547,7 @@
+         # Set up files for the haptic library
+         if test x$enable_haptic = xyes; then
+           case $ARCH in
+-            linux)
++            linux|freebsd)
+                 if test x$use_input_events = xyes; then
+
+ $as_echo "#define SDL_HAPTIC_LINUX 1" >>confdefs.h

 

[Criosphinx]

Eh… It's either SDL or nothing. I'm not aware of anything using /dev/joy*.



We have evdev, but no native drivers and no route to applications. It's easy enough to reuse gamepad drivers from Linux with webcamd, so drivers aren't a huge concern. Applications are somewhat tricky. Again, it's quite easy to compile SDL with evdev backend, but that will disable SDL's UHID backend which is probably not ideal.

Out of curiosity, because I don't have any game or emulator installed, I tested my Logitech Attack 3 and a wired Xbox 360 controller using this: https://github.com/meleu/jstest-sdl and both work fine.

But I wanted to ask you, is there a way to use the controllers with libraries like graphics/glfw or x11-toolkits/qt5-gamepad ?

The joysticks test program included with glfw says "Noy joysticks connected" and the Qt Gamepad Simple Example is trying to use evdev:

qt.gamepad: Available backends: ("evdev")
qt.gamepad: Loading backend "evdev"
qt.gamepad: start
qt.gamepad: Using device discovery
Did not find any connected gamepads


I'm guessing I need to install x11-drivers/xf86-input-evdev and create a configuration file?
Would glfw detect joysticks if I install and enable webcamd?

 

[shkhln]

Out of curiosity, because I don't have any game or emulator installed, I tested my Logitech Attack 3 and a wired Xbox 360 controller

There is no point in such test without a specific goal, what works for one program does not necessarily work for another.

The joysticks test program included with glfw says "Noy joysticks connected"

No idea.

and the Qt Gamepad Simple Example is trying to use evdev:

Evdev is available either through webcamd or iichid.

I'm guessing I need to install x11-drivers/xf86-input-evdev and create a configuration file?

No, of course not.

 

[PaddyMac]

shkhln, I apologize if I sound like I'm whining. But I have met with a lot of frustration regarding this functionality. I appreciate you offering a patch, but what does your patch do? As I mentioned above, I can already use gamepads on some specific applications -- typically SDL-based applications -- like PCSXR or SNES9x via UHID support.

I did contact the author of webcamd, and he did clarify that /dev/input/js0 is the old Linux joystick API, but that /dev/input/eventx was also created by webcamd to provide an evdev interface for the joystick/gamepad. Indeed I have a /dev/input/event4 device when using webcamd to set up a controller. According to the webcamd author, this evdev device is generic and should "just work". However, the reality is different. /var/log/Xorg.0.log shows that the X server is recognizing two of my tested controllers as mice (Logitech Dual Action, and an iNNEXT USB SNES pad). A third controller, a PDP brand Xbox One controller isn't detected by Xorg at all without manual configuration, and even then it is detected as a mouse. I'm not surprised that the PDP controller is behaving diffeently. It has a quirk and doesn't behave the same as a Microsoft Xbox One controller and doesn't even work as a UHID device on FreeBSD either (even on Linux it needed a special driver to deal with its odd behavior). As for the Logitech and the iNNEXT controller, Xorg seems to completely ignore any attempts at manual configuration, even if I use lower-numbered conf files than the default ones supplied in /usr/local/share/X11/xorg.conf.d/. In any case, game controllers which have been configured as evdev devices by webcamd are being identified and treated by Xorg as mice, and the only functionality they provide is moving the mouse cursor with the left analog stick or D-pad. I discussed this with the webcamd author, and he did not have an explanation for the behavior. So I don't know if webcamd itself has a problem, if it's a problem with with FreeBSD's evdev support, or something else. The Xorg.0.log indicates that it is treating the device as a mouse because udev tagged it as a mouse.

 

[shkhln]

I did contact the author of webcamd, and he did clarify that /dev/input/js0 is the old Linux joystick API, but that /dev/input/eventx was also created by webcamd to provide an evdev interface for the joystick/gamepad. Indeed I have a /dev/input/event4 device when using webcamd to set up a controller. According to the webcamd author, this evdev device is generic and should "just work".

…with any application which requires evdev. Pretty much nothing on FreeBSD is compiled with evdev gamepad support by default.

A third controller, a PDP brand Xbox One controller isn't detected by Xorg at all without manual configuration, and even then it is detected as a mouse. I'm not surprised that the PDP controller is behaving diffeently. It has a quirk and doesn't behave the same as a Microsoft Xbox One controller and doesn't even work as a UHID device on FreeBSD either (even on Linux it needed a special driver to deal with its odd behavior).

I have a genuine Xbox One gamepad and it doesn't work as a USB HID device as well because it doesn't present itself as a USB HID device to the operating system in the first place. In general, first party console controllers do not implement this spec (at least not in a directly useful way). That is why they require specialized drivers, such as the drivers bundled with webcamd. If your gamepad is supported by other means I don't see why would you want webcamd.

As for the Logitech and the iNNEXT controller, Xorg seems to completely ignore any attempts at manual configuration, even if I use lower-numbered conf files than the default ones supplied in /usr/local/share/X11/xorg.conf.d/.

Who cares about Xorg? Xorg is not a game.

In any case, game controllers which have been configured as evdev devices by webcamd are being identified and treated by Xorg as mice, and the only functionality they provide is moving the mouse cursor with the left analog stick or D-pad.

That's precisely how Xorg is designed to work. You won't be able to use it for games.