# Joystick API



## A. D. Sharpe Sr. (Oct 14, 2019)

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 (Oct 14, 2019)

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. (Oct 15, 2019)

Phishfry said:


> 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 (Oct 15, 2019)

A. D. Sharpe Sr. said:


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


MAME also uses SDL for its joystick support.


----------



## shkhln (Oct 15, 2019)

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



A. D. Sharpe Sr. said:


> 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. (Oct 18, 2019)

shkhln said:


> 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 (Oct 18, 2019)

A. D. Sharpe Sr. said:


> 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. (Oct 18, 2019)

shkhln said:


> 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 (Oct 19, 2019)

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 (Oct 19, 2019)

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. (Oct 19, 2019)

shkhln said:


> 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. (Oct 19, 2019)

Beastie7 said:


> 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 (Oct 19, 2019)

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


----------



## JAW (Oct 19, 2019)

A. D. Sharpe Sr. said:


> 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 (Oct 19, 2019)

JAW said:


> 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 (Oct 19, 2019)

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


----------



## JAW (Oct 20, 2019)

shkhln said:


> 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 (Mar 16, 2020)

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 (Mar 16, 2020)

PaddyMac said:


> 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 (Mar 20, 2020)

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 (Mar 20, 2020)

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 (Mar 23, 2020)

shkhln said:


> 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 (Mar 24, 2020)

Criosphinx said:


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



Criosphinx said:


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



No idea.



Criosphinx said:


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



Evdev is available either through webcamd or iichid.



Criosphinx said:


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



No, of course not.


----------



## PaddyMac (Mar 28, 2020)

*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 (Mar 28, 2020)

PaddyMac said:


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



PaddyMac said:


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



PaddyMac said:


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



PaddyMac said:


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


----------



## wago (Aug 2, 2020)

joystick works for me on FreeBSD 12.1 using SDL. I was getting "no joystick found" although attached on /dev/input/event7 and /dev/input/js0, however I noticed the device was owned by webcamd user/group with 660 permissions. I think you can set up a devd rule but I added myself to the "webcamd" group and the joystick works. It's a USB M$ Xbox controller. I've been able to use it in SDL like this:


```
...
SDL_Joystick* joy = NULL;

SDL_InitSubSystem(SDL_INIT_JOYSTICK);

if ( SDL_NumJoysticks() > 0 )
    joy = SDL_JoystickOpen( 0 );
    
SDL_Event e;
handleEvent(e)

if( e.type == SDL_JOYAXISMOTION )
{
    if( e.jaxis.which == 0 )
    {                       
        if( e.jaxis.axis == 3 ) //x
...
```
ref: https://wiki.libsdl.org/SDL_JoystickOpen


----------



## A. D. Sharpe Sr. (Apr 15, 2021)

Just a short update. I've started working on this project, but I've hit a few road blocks. As part of my process, I'm developing a tool to allow me to enumerate usb devices & get notifications of connections/disconnections. This tool is written in C++ & uses libusb. The problem is that I can't access usb information without running the tool as root/su. I see this as being unreasonable, because users should be able to get this information in a GUI tool on their own machine. Currently, I'm researching a way to get around this road block. The fact that I'm in the wheel group doesn't seem to matter, in regards to accessing usb information. I'm looking at devd. I'm hoping that it has an API to allow me to directly query it for the information that I'm looking for. If anyone else has any ideas to help me get past this blockage, please let me know.


----------



## SteamBSD (Apr 17, 2021)

*Solve *(remote play):





--- SteamBSD © is FREE operating system.
YouTube: https://www.youtube.com/channel/UC8wwRY8yGWiJ-bIQlK0wvUA/videos
Site (download ISO/IMG): https://lpros.blogspot.com
Github (internet installer): https://github.com/steambsd/os
Email: steambsd@gmail.com


----------



## PaddyMac (Apr 18, 2021)

A. D. Sharpe Sr. said:


> Just a short update. I've started working on this project, but I've hit a few road blocks. As part of my process, I'm developing a tool to allow me to enumerate usb devices & get notifications of connections/disconnections. This tool is written in C++ & uses libusb. The problem is that I can't access usb information without running the tool as root/su. I see this as being unreasonable, because users should be able to get this information in a GUI tool on their own machine. Currently, I'm researching a way to get around this road block. The fact that I'm in the wheel group doesn't seem to matter, in regards to accessing usb information. I'm looking at devd. I'm hoping that it has an API to allow me to directly query it for the information that I'm looking for. If anyone else has any ideas to help me get past this blockage, please let me know.


Have you been in contact with the developers of iichid? They've done a lot of work toward getting USB gamepads working in FreeBSD. I'll bet you could collaborate with them and make some good progress. As far as accessing devices as a regular user instead of root, I've had the same complaint. My suggestion is that the FreeBSD base system needs to add additional users and groups to give finer-grained control of who can access various devices in the system. In the meantime, adding devfs.rules entries may be a workaround.


----------



## sidetone (Apr 18, 2021)

In FreeBSD 13.0, iichid is in base. I'm uncertain if this an underlying part of usbhid(3), which can be enabled in place of the traditional uhid(4).


----------



## A. D. Sharpe Sr. (Apr 20, 2021)

PaddyMac said:


> Have you been in contact with the developers of iichid? They've done a lot of work toward getting USB gamepads working in FreeBSD. I'll bet you could collaborate with them and make some good progress. As far as accessing devices as a regular user instead of root, I've had the same complaint. My suggestion is that the FreeBSD base system needs to add additional users and groups to give finer-grained control of who can access various devices in the system. In the meantime, adding devfs.rules entries may be a workaround.


Honestly, I've never heard of that project. As for the hardware access problem, I'm thinking that there might have to be either a hardware daemon or some type of modification to devd to facilitate better access.


----------



## A. D. Sharpe Sr. (Apr 20, 2021)

sidetone said:


> In FreeBSD 13.0, iichid is in base. I'm uncertain if this an underlying part of usbhid(3), which can be enabled in place of the traditional uhid(4).


It does look like it's going to be the replacement for the previous hid subsystem. It seems that there's no longer a reason for my project to even exist. In time, I'll upgrade my system to 13. Afterwards, I'll check to see if my usb joysticks work. If so, then I'm going to sit back & enjoy.


----------



## sidetone (Apr 20, 2021)

Your project or a variant of it can still exist.


----------



## A. D. Sharpe Sr. (Apr 21, 2021)

sidetone said:


> Your project or a variant of it can still exist.


I'm currently checking it out now. I just upgraded from FBSD 12.2 to 13. If it works the way I think it works, then all that's necessary is to make sure that iichid works nicely with SDL's input. If that all works out fine, then I can move forward to my real interest -native gaming on FBSD.


----------

