The ps4 controller for example in usb is not recognized under godot 4.2.1

If Godot relies on udev, it's probably compiled without gamepad support by default. You'll have to look into this part first.

Espionage724 said:
This sounds related to what I did for a USB joystick for FlightGear: https://forums.freebsd.org/threads/usb-joystick-with-flightgear.94855/ and sounds like the controller needs to show up under /dev/uhid#. I have some notes here about it too.

After installing uuhid it seems easy to move a plugged-in joystick with:

Code: 
uhidd -h -H 'uhid' -u '/dev/ugen0.6'
Click to expand...
uhidd should never be used, it's a completely useless piece of garbage. If FlightGear somehow relies on it, it's a problem with FlightGear and should be fixed there.
 
shkhln said:
uhidd should never be used, it's a completely useless piece of garbage. If FlightGear somehow relies on it, it's a problem with FlightGear and should be fixed there.
Click to expand...
Is there a better way to have USB game controllers show under dev/uhid# on FreeBSD without getting it fixed at the source in the meantime? I'm more interested in playing it :p

As far as I know, usbhid causes USB devices to use modern paths under /dev/ugen#.#, and programs not expecting those modern paths don't see the devices. I'm pretty sure this also affects Firefox with U2F sticks (thread), and seemingly affect other joystick games (neverball/putt, devilutionx, doomsday).

Is it that everything still expecting /dev/uhid# needs updated for ugen#.#?
 
The apps should either use evdev (implemented for compatibility with Linux a few years ago) or just plain libusb (if they want to parse HID descriptors themselves).

/dev/uhid was supposed to be the go-to HID descriptor interface, however it doesn't return the descriptors as they are, there are some patches and workarounds applied (see https://github.com/freebsd/freebsd-src/commit/0cb0bc8808d00ea6288d6c6a34bd6403597e4327), which is not what you want from such a low-level API. Let's suppose we want to reverse the Y joystick axis because the hardware reports it improperly. Does it make sense to patch up the descriptor or reported values for that right in the kernel? You might think it does, but other operating systems don't necessarily have the same workarounds (or committing them in sync with you), so any userspace code would still have to apply the same workarounds, but now it's unaware whether it's being fed the unmangled input information and have to deal with that as well. This is pretty much the definition of leaky abstraction.

In contrast, evdev doesn't provide HID descriptors to the userspace, which puts this responsibility on the kernel, while libusb allows userspace to read unmangled HID descriptors, which means the userspace is also responsible for any workarounds. Either option is much better than the uhid mess.

/dev/ugen is a slightly more general USB thing, which doesn't have any advantages over libusb, as far as I'm aware. Then there is uhidd that adds an additional layer of mangling on top of this, which is frankly ridiculous.
 
shkhln said:
If Godot relies on udev, it's probably compiled without gamepad support by default. You'll have to look into this part first.


uhidd should never be used, it's a completely useless piece of garbage. If FlightGear somehow relies on it, it's a problem with FlightGear and should be fixed there.
Click to expand...

This is the first thing I checked, it is compiled with the udev=on option
With uhidd -h -H 'uhid' -u '/dev/ugen2.5' the controllers are still not detected by godot...
 
I use usbhid, and found a forum discussion somewhere that recommended temp-disabling it, plugging in the device, and then re-enabling usbhid. That works nicely for my joystick to show under /dev/uhid# and fgjs, and I didn't need to adjust permissions or use uhidd.

Code: 
su - root -c "sysctl 'hw.usb.usbhid.enable=0' && sleep 3 && sysctl 'hw.usb.usbhid.enable=1'"
 
shkhln said:
Try this script: https://github.com/shkhln/linuxulat...32b8d3a9ad5fe409e/bin/fix-gamepad-permissions.
Click to expand...
Espionage724 said:
I use usbhid, and found a forum discussion somewhere that recommended temp-disabling it, plugging in the device, and then re-enabling usbhid. That works nicely for my joystick to show under /dev/uhid# and fgjs, and I didn't need to adjust permissions or use uhidd.

Code: 
su - root -c "sysctl 'hw.usb.usbhid.enable=0' && sleep 3 && sysctl 'hw.usb.usbhid.enable=1'"
Click to expand...

Thanks for the script and the command but the controller is still not detected under godot...
 
SirDice said:
Does loading ps4dshock(4) help?
Click to expand...
shkhln's fix-gamepad-permissions script already loads this module.
It doesn't change anything, the controller is still not detected.
The controller works with programs that use the SDL1.2 and SDL2 libraries recompiled with the right options...
 
Espionage724 said:
Can you explain how to test this in godot? I never used godot before, but I see a godot-4.2.1 pkg and think I have a PS4 controller somewhere (can test other controllers too)
Click to expand...
You need to install the godot-tools package, run it and search in the projects with the word "gamepad", install and run it and from there you can test the controllers.
Any game project normally supports controllers.
It works very well under Linux in wired and bluetooth.
See my first message
 
Hello, I made a patch for controller support under godot 4.2.1 ( godot-4.2.1_joystick.patch) :
Code: 
diff -ur godot-tools/work/godot-4.2.1-stable/platform/linuxbsd/detect.py godot-tools.patch/work/godot-4.2.1-stable/platform/linuxbsd/detect.py
--- godot-tools/work/godot-4.2.1-stable/platform/linuxbsd/detect.py    2023-12-11 22:14:04.000000000 +0100
+++ godot-tools.patch/work/godot-4.2.1-stable/platform/linuxbsd/detect.py    2025-02-14 19:37:33.532681000 +0100
@@ -370,7 +370,7 @@
     else:
         env.Append(CPPDEFINES=["XKB_ENABLED"])
 
-    if platform.system() == "Linux":
+    if platform.system() in ["Linux","FreeBSD"]:
         env.Append(CPPDEFINES=["JOYDEV_ENABLED"])
         if env["udev"]:
             if not env["use_sowrap"]:
diff -ur godot-tools/work/godot-4.2.1-stable/platform/linuxbsd/libudev-so_wrap.c godot-tools.patch/work/godot-4.2.1-stable/platform/linuxbsd/libudev-so_wrap.c
--- godot-tools/work/godot-4.2.1-stable/platform/linuxbsd/libudev-so_wrap.c    2023-12-11 22:14:04.000000000 +0100
+++ godot-tools.patch/work/godot-4.2.1-stable/platform/linuxbsd/libudev-so_wrap.c    2025-02-14 19:37:42.116512000 +0100
@@ -281,7 +281,7 @@
 int initialize_libudev(int verbose) {
   void *handle;
   char *error;
-  handle = dlopen("libudev.so.1", RTLD_LAZY);
+  handle = dlopen("libudev.so.0", RTLD_LAZY);
   if (!handle) {
     if (verbose) {
       fprintf(stderr, "%s\n", dlerror());
diff -ur godot-tools/work/godot-4.2.1-stable/thirdparty/linuxbsd_headers/udev/libudev.h godot-tools.patch/work/godot-4.2.1-stable/thirdparty/linuxbsd_headers/udev/libudev.h
--- godot-tools/work/godot-4.2.1-stable/thirdparty/linuxbsd_headers/udev/libudev.h    2023-12-11 22:14:04.000000000 +0100
+++ godot-tools.patch/work/godot-4.2.1-stable/thirdparty/linuxbsd_headers/udev/libudev.h    2025-02-14 19:38:07.248390000 +0100
@@ -22,7 +22,7 @@
 #define _LIBUDEV_H_
 
 #include <stdarg.h>
-#include <sys/sysmacros.h>
+// #include <sys/sysmacros.h>
 #include <sys/types.h>
 
 #ifdef __cplusplus

Procedure to follow to apply the patch:
# cd /usr/local/poudriere/ports/default/devel/godot-tools/
# make clean
# make extract
# make patch
# pkg install evdev-proto-5.8
# patch -p1 < godot-4.2.1_joystick.patch
# make
# make package
# cd work/pkg/
# pkg add godot-tools-4.2.1_2.pkg
 
You must log in or register to reply here.
Back
Top