Won't attach to Xbox 360 controller

[PaddyMac]

I'm on 12.2-RELEASE. I've tried iichid 0.0.3 from ports and the code from Github as of today. In either case, when I load iichid and plug in the controller, the output from dmesg is

ugen3.3: at usbus3 uhid0 on uhub3 uhid0: <Microsoft Corporation Controller, rev 2.00/1.10, addr 3> on usbus3 uhid0: at uhub3, port 2, addr 3 (disconnected) uhid0: detached usbhid0 on uhub3 usbhid0: <Microsoft Corporation Controller, rev 2.00/1.10, addr 3> on usbus3 hidbus0: on usbhid0 xb360gp0: <XBox 360 Gamepad> on hidbus0 hidraw0: on hidbus0 hidbus0: failed to attach child: error 6 xb360gp0: detached hidraw0: detached device_attach: hidbus0 attach returned 6

[wulf7]

Try current master from this repo

[PaddyMac]

As I mentioned above, I've already tried the code from current master with the same result as with the 0.0.3 release. And just to be sure, I tried rebooting with iichid added to /boot/loader.conf in case manually running "kldload iichid" was insufficient. If there's anything additional I can do to assist in debugging, please instruct me how to do so.

[wulf7]

As I mentioned above, I've already tried the code from current master with the same result as with the 0.0.3 release.

I forgot to add that I committed possible fix for #43 to this repo just before I wrote previous message. Please, pull it again.

[PaddyMac]

Ah. Thanks for clarifying. I pulled and rebuilt. It does seem to be attaching to the Xbox 360 controller. This is the output I see now.

ugen3.3: at usbus3 usbhid2 on uhub3 usbhid2: <Microsoft Corporation Controller, rev 2.00/1.10, addr 3> on usbus3 hidbus2: on usbhid2 xb360gp0: <XBox 360 Gamepad> on hidbus2 hidraw2: on hidbus2

Are there any applications on FreeBSD that are known to work with this so I can test it? Nothing I've tried so far recognizes that there is a game controller on FreeBSD.

[wulf7]

Are there any applications on FreeBSD that are known to work with this so I can test it? Nothing I've tried so far recognizes that there is a game controller on FreeBSD.

If you want to test native evdev interface, you can build SDL2 with evdev support (need patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249874) and than compile and run simple test program https://gitlab.com/sdl-jstest/sdl-jstest. Being run it shows state of controls at real time. That is the way I tested my PS4 game controller.

If it works for you, than virtually all applications with SDL2 gamepad support should just work. I know only one such an application: emulators/mednafen but I am pretty sure that more exists. The bad news: I was not able to run it properly, i.e. find all the bioses/roms and configuration options. The good news: It detected my game controller at start and wrote its name.

I did not tried wine or proprietary linux games.

[wulf7]

Also you may ask author of the XBox 360 driver, @myfreeweb if he knows FreeBSD native applications that can use this driver.

[valpackett]

RetroArch obviously is the biggest one, and it's the one I use the most. RPCS3 and Mesen use evdev directly too. Dolphin can, but uses SDL on BSD right now, changes are required at least in the build system.

also, keep in mind that you need access to /dev/input/inputN, which usually only root is supposed to have, but for game controllers they should be available to your regular user account. Use evemu-record (devel/evemu) to just test that it's working at all. Run as root at first, and then check as user to see that access rights are correct.

e.g..

% doas evemu-record
Available devices:
[…]
/dev/input/event4:      XBox 360 Gamepad
[Ctrl-C]
% doas chown greg /dev/input/event4
% evemu-record
Available devices:
/dev/input/event4:      XBox 360 Gamepad

really devd should be configured to detect known game controllers and make them available

[wulf7]

keep in mind that you need access to /dev/input/inputN,

Following can be added to /etc/devd.rules to make all event devices available to e.g. operator group

[system=10]
add path 'input/*' mode 0660 group operator

[wulf7]

ioquake3 is rumored to support gamepads too, but our ports version is too old for this.

[PaddyMac]

I tried sdl2-jstest as well as evemu-record, and both will detect the Xbox 360 controller when running as root. I also tried the pcsxr emulator, and it will detect the controller when run as root. Wulf7, I tried your /etc/devd.rules entry, and it had no effect (it did not change any permissions). So I tried adding an input group to my system, adding my user to that group, and manually chowning the /dev/input/event8 device to root:input. But nothing will detect the controller when running as a regular user even with the permissions set up this way.

[valpackett]

Don't forget to chmod g+rw so the group actually has the rights.

Also that syntax @wulf7 posted goes into /etc/devfs.rules, devfs not devd, there is no devd.rules :D and it's applied by /etc/rc.d/devfs

[wulf7]

I tried your /etc/devd.rules entry, and it had no effect (it did not change any permissions).

Ouch. I am sorry. My bad :-( The name of the file is devfs.rules not devd.rules. If you have entered input group than string can be changed to

[system=10]
add path 'input/*' mode 0660 group input

So I tried adding an input group to my system, adding my user to that group, and manually chowning the /dev/input/event8 device to root:input.

Dont you forget to set 660 file mode for /dev/input/event8?

[PaddyMac]

I had to add devfs_system_ruleset="system" to /etc/rc.conf to get that to work, but that set up the device nodes with the correct group and permissions. And yes, it was a permissions problem before: only the owner could read or write by default and not the group.

The information we've discussed here should really be in the iichid README.md at the minimum. Better would be some autoconfiguration handled by the port. Even better than that would be some upstream changes in FreeBSD like having a dedicated input group and having the devices in /dev/input/* be in that group. Though I'm curious why other devices in /dev/input (like the mouse and keyboard) work without any additional groups or permissions set up. Or is it just because those devices are handled by other means in addition to evdev, and the evdev portion works in Xorg because the X server runs as root?

[wulf7]

Better would be some autoconfiguration handled by the port.

It's good idea to write DEVD rule to change permissions of input/event* nodes for joysticks. If you familiar with devd.conf enough you can do it yourself, if not, I will do it at my own. Hint: sysctl kern.evdev.input.#.phys gives one a name of the driver handling input/event# node.

Even better than that would be some upstream changes in FreeBSD like having a dedicated input group and having the devices in /dev/input/* be in that group.

It is not done in the base yet as no drivers exist in the kernel source tree which require non-root access.

Though I'm curious why other devices in /dev/input (like the mouse and keyboard) work without any additional groups or permissions set up.

They are opened by xorg-server or wayland compositor when latters are running as root.

[valpackett]

FreeBSD native applications that can use this driver

Exciting new addition to this list: Firefox! But right now, only if you apply my patch and compile it from source :)

(yes, only writing that patch made me realize about #48)

They are opened by xorg-server or wayland compositor when latters are running as root

And when not running as root, the display server gets access to them via fd-passing from the session manager (logind/consolekit2/seatd).

---

name of the driver handling input/event# node

ehh.. hardcoded lists, that doesn't scale™ :D We need some centralized place like the udev database that would default to driver names and/or heuristics but would also allow the user to override various info like "is this a gamepad or a mouse". (libudev-devd currently purely relies on heuristics.) And the devd permission-changing handlers would use that too.

I'll try to do something about that "soon".

[wulf7]

We need some centralized place like the udev database that would default to driver names and/or heuristics but would also allow the user to override various info like "is this a gamepad or a mouse". (libudev-devd currently purely relies on heuristics.) And the devd permission-changing handlers would use that too.

Another way is to extend evdev KPI to allow driver set owner/mode of device node and let a user to override them with loader tunables.

[PaddyMac]

I know it's been a while since I followed up on this. But with FreeBSD 13 almost out and iichid now upstreamed, I figured I'd give this another go. I've got 13-RC4 installed on my laptop, and I'm trying to use the drivers included in the base system. It looks like hgame is the primary kernel module now, but in any case the kernel modules are loading (hgame, xb360gp, etc.) and dmesg shows that the controller is recognized, but it's not even creating /dev/input/event* devices any more. I've tried a Microsoft Xbox 360 controller, a PDP brand Xbox One controller, and a Logitech Dual Action gamepad. I'm not sure how many types of controllers are supported by the driver, but I remember it working at least with the Microsoft Xbox 360 controller when I tested it last October. Was there a regression or maybe some important change in the way it works?

[wulf7]

USB support is disabled by default in 13.0. You should add following lines to /boot/loader.conf to enable it:

hw.usb.usbhid.enable=1
usbhid_load="YES"

[PaddyMac]

If I boot up my laptop with nothing added to /boot/loader.conf then plug in the Xbox 360 controller, the following occurs: 1) it will load the uhid.ko, usbhid.ko, hidbus.ko, xb360gp.ko, hidmap.ko, and hgame.ko automatically. 2) dmesg will output

ugen2.2: at usbus2 uhid0 on uhub6 uhid0: <Microsoft Corporation Controller, rev 2.00/1.10, addr 2> on usbus2

3) the light around the X button will blink a couple of times 4) But it won't create any /dev/input/event* devices or otherwise appear to be usable (nothing appears in /var/log/Xorg/0/log either)

If I add

hw.usb.usbhid.enable=1 usbhid_load="YES"

to /boot/loader.conf and reboot, usbhid.ko and hidbus.ko will already be loaded once the system is booted. When I plug in the Xbox 360 controller, this is what happens:

1) None of the additional kernel modules are loaded (uhid.ko, xb360gp.ko, hidmap.ko, and hgame.ko) 2) dmesg will output

ugen2.2: at usbus2 usbhid0 on uhub6 usbhid0: <Microsoft Corporation Controller, rev 2.00/1.10, addr 2> on usbus2 hidbus0: on usbhid0

3) The light around the X button on the Xbox 360 will blink continuously until I unplug it or reboot/power down the laptop. 4) It still doesn't create any /dev/input/event* devices or appear to be usable

[PaddyMac]

I just discovered that while the Xbox 360 controller is not working, my Logitech Dual Action controller appears to be. It will load hgame.ko and hidmap.ko. Dmesg shows

ugen2.2: at usbus2 usbhid0 on uhub6 usbhid0: <Logitech Logitech Dual Action, class 0/0, rev 1.10/3.00, addr 2> on usbus2 hidbus0: on usbhid0 hgame0: on hidbus0

and it creates a /dev/input/event6 device. I still need to get permissions corrected on that since it's owned by root:wheel, but I can work with that. So it does appear to be a problem specific to the Xbox 360 controller. The PDP controller still doesn't work, but the xb360gp driver probably needs a quirk added to make it work because it uses a different initialization routine than the Microsoft controller.

[wulf7]

usbhid0 on uhub6 usbhid0: <Microsoft Corporation Controller, rev 2.00/1.10, addr 2> on usbus2

USB transport driver is successfully attached. What happens if you kldunload/kldload xb360gp.ko from command line after that?

[PaddyMac]

The xb360gp module isn't already loaded after the sequence of events described above. I kldloaded the xb360gp module, and the light on the controller stopped blinking immediately. I checked /dev/input, and it created /dev/input/event6. So yeah, it just looks like the issue is that xb360gp.ko isn't getting loaded automatically for some reason. I tested the PDP controller while I was at it. It still doesn't work, but the Microsoft one is working.

The only issue now is something that may be out of scope for this project, but I reported it last year on the FreeBSD bug tracker ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250724 ). The bug affects the Logitech Dual Action controller but not the Xbox 360 controller.

[wulf7]

The only issue now is something that may be out of scope for this project, but I reported it last year on the FreeBSD bug tracker ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250724 ). The bug affects the Logitech Dual Action controller but not the Xbox 360 controller.

I've tried to add support for hgame to libudev-devd: https://github.com/wulf7/libudev-devd Could you test it?

[PaddyMac]

At first I didn't think it worked. I manually compiled it and copied the library to /usr/local/lib. I plugged in the Logitech controller and it was still tagged as a mouse. But I rebooted and retested, and it is no longer being tagged as a mouse. I guess the old library from pkg was still being used in RAM until the reboot. So the change you made to libudev-devd did the trick.

Dmesg output:

ugen2.2: at usbus2 usbhid0 on uhub3 usbhid0: <Logitech Logitech Dual Action, class 0/0, rev 1.10/3.00, addr 2> on usbus2 hidbus0: on usbhid0 hgame0: on hidbus0

Xorg.0.log output:

[ 106.326] (II) config/udev: Adding input device Logitech Logitech Dual Action Joystick (/dev/input/event6) [ 106.326] (II) No input driver specified, ignoring this device. [ 106.326] (II) This device may have been added with another device file.