Issue configuring PowerA Fusion wired XBox One controller

mitu

Since neither of you updated to the latest xpad, I'd say it's unlikely this is causing the trouble. One thing though, if you update the kernel, this will overwrite the xpad driver distributed by RetroPie.
So @simonster , can you try updating the xpad driver from source - from the RetroPie-Setup menu ?

simonster

@mitu said in Issue configuring PowerA Fusion wired XBox One controller:

So @simonster , can you try updating the xpad driver from source - from the RetroPie-Setup menu ?

Hi @mitu

Just updated this from source, but no joy I'm afraid (after a reboot).

Just in case I hadn't made it clear from my description, below is the output from jstest when I press each shoulder trigger.

mitu

@simonster Normally, the xpad driver should take of this with the triggers_to_buttons driver option [1]. The behavior you're seeing is the opposite, if I'm not mistaken. The xpad package automatically adds this option to the driver. You can check the option is configured by default by checking /etc/modprobe.d/xpad.conf, it should have a line with

options xpad triggers_to_buttons=1

Can you run dmesg | tail right after plugging in the controller and post the output ?

[1] https://www.spinics.net/lists/linux-input/msg00820.html

aditkrator

This is what I get immediately after I plug in the controller.

[   37.991519] usb 1-1.5: new full-speed USB device number 4 using dwc_otg
[   38.125060] usb 1-1.5: New USB device found, idVendor=045e, idProduct=02ea
[   38.125075] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   38.125084] usb 1-1.5: Product: Controller
[   38.125093] usb 1-1.5: Manufacturer: Microsoft
[   38.125102] usb 1-1.5: SerialNumber: 3032363030323737353233373435
[   38.178909] input: Microsoft X-Box One S pad as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/input/input2
[   38.179907] usbcore: registered new interface driver xpad
[   40.820164] random: crng init done
[   43.671563] Voltage normalised (0x00000000)

mitu

@aditkrator Do you get the same behaviour as @simonster when testing the buttons with jstest ?

simonster

It doesn't look like my controller is using xpad at all:

[ 1401.392278] usb 1-1.1.2: New USB device found, idVendor=24c6, idProduct=561a
[ 1401.392292] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1401.392300] usb 1-1.1.2: Product: Controller
[ 1401.392309] usb 1-1.1.2: Manufacturer: PowerA
[ 1401.392317] usb 1-1.1.2: SerialNumber: 0000BE512D3F0D75
[ 1401.393476] input: PowerA FUSION Controller as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/input/input2

aditkrator

@mitu

Yes, my axis 2 still ranges from -32767 when released to 32767 when pressed and same with axis 5.

simonster

I'm going to try rewriting the original image to the card and check before I update the RetroPie script or any of the modules.

mitu

@aditkrator FWIW, I get the a similar behavior when running jstest and disabling the triggers_to_buttons option. With this option on (which should be the default), the triggers register as buttons (on/off).
Can you check if /etc/modprobe.d/xpad.conf exists and has the line I mentioned a couple of posts ago ?

simonster

@mitu

I can confirm mine was set with triggers to buttons. But as I said above, it doesn't look like my controller uses xpad at all.

aditkrator

@mitu Mine also has options xpad triggers_to_buttons=1.

simonster

I can confirm that after reimaging the card, the triggers show up as buttons, but dmesg | tail still doesn't suggest xpad is involved.

I'm going to try updating the RetroPie packages (without the kernel updates) and see if it still works.

aditkrator

I'm also going to try to reflash the SD card and run dmesg | tail and jstest to see if this issue persists.

Edit 1: Here are the results of dmesg | tail

[   32.995080] usb 1-1.5: New USB device found, idVendor=045e, idProduct=02ea
[   32.995094] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   32.995105] usb 1-1.5: Product: Controller
[   32.995113] usb 1-1.5: Manufacturer: Microsoft
[   32.995124] usb 1-1.5: SerialNumber: 3032363030323737353233373435
[   33.043410] xpad: loading out-of-tree module taints kernel.
[   33.043422] xpad: loading out-of-tree module taints kernel.
[   33.046448] input: Microsoft X-Box One S pad as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/input/input0
[   33.046920] usbcore: registered new interface driver xpad
[   33.271690] Under-voltage detected! (0x00050005)

Edit 2: I can confirm jstest now treats the triggers as buttons. I also think I may have misspoken in an earlier message:

@aditkrator said in Issue configuring PowerA Fusion wired XBox One controller:

Edit 2: I also setup a RetroPie on my friend's RPi with wired Xbox 360 controllers, and the triggers setup just fine. I didn't update the xpad driver, so either the updated xpad driver doesn't work (which isn't likely since @simonster is having the issue with a fresh copy of 4.4 or (more likely) Xbox One controllers, uniquely, are mapped with positive/negative trigger values in both xpad and xboxdrv.

I actually did update xpad -- I honestly was too tired writing that.

simonster

@mitu

So, after writing RP4.4 image to SD card and starting it, the pad worked correctly (triggers as buttons), but after updating RetroPie Setup Script and running update installed modules (and selecting not to update OS packages) and rebooting, the controller now has the 2 additional axis listed.

I did eventually find that it is using xpad. Because I'd already had the device plugged in before trying it, it wasn't listing the driver in dmesg | tail. The option is still set in /etc/modprobed/xpad.conf so it must be an issue with the xpad driver in use? The install script stated it was installing version 0.4

mitu

@simonster said in Issue configuring PowerA Fusion wired XBox One controller:

The install script stated it was installing version 0.4

I think it's the same version set there for a long time, I'm not sure if it's relevant. So the updated driver has some new unwanted features.

simonster

Given that the xpad code has been updated numerous times last week (22nd/23rd June), and it appears that a diff is being applied by the RetroPie Setup, is there a chance that this isn't being applied correctly any longer? Previous to the 22nd June, it hadn't been changed since December.

EDIT: I have just checked the RetroPie-Setup git repository and can see this was updated 2 days ago.

mitu

@simonster Yes, the patch was no longer applying correctly to the upstream driver, so it was updated, hence my initial reply in the topic.
Could you test if it works by removing the patch from the RetroPie script module ? Too late for me at the moment, but I'll give it a test tomorrow also.

mitu

I think I found the problem - the xpad driver from the RetroPie setup is not getting installed properly. I'll do more testing, starting from a 4.4 stock image and running an update to see how it works, and try to find an easier fix than my manual steps.

mitu

Ok, so I did more testing and the problem is the RetroPie xpad driver not installing correctly during an update. Since the install script first removes the RetroPie xpad driver, then installs it again, you're left with the stock Linux kernel driver, which exhibits the problem of mapping the triggers to axis instead of buttons.

The install script runs ok, but in the driver install step it prints an error:

[...]
 Building module:
    cleaning build area....
    make -j4 KERNELRELEASE=4.14.34-v7+ KVERSION=4.14.34-v7+.....
    cleaning build area....

    DKMS: build completed.

    xpad.ko:
    Running module version sanity check.
    Error! Module version 8E0436A9FBE74C6BE0383CF for xpad.ko
    is not newer than what is already found in kernel 4.14.34-v7+ (85D9866F0D7E8D4F0C731B6).
    You may override by specifying --force.
[...]

Since during an full RetroPie update the screen scrolls fast, this message doesn't get noticed, but it's logged in the update log.

The xpad install fails starting with the stock 4.4 image, which includes kernel 4.14.x that probably has a module version newer than the driver installed by the RetroPie-Setup script. I tried the driver install both on the stock image 4.4 image (with just the RetroPie script updated) and on an updated OS (newer kernel version).

TL;DR version : You can force the RetroPie xpad driver installation by editing the /home/pi/RetroPie-Setup/scriptmodules/supplementary.xpad.sh file and (around line 75) replace

dkms install -m xpad -v 0.4 -k "$kernel"

with

dkms install  --force -m xpad -v 0.4 -k "$kernel"

You can easily check which module driver gets loaded by executing

sudo rmmod xpad
sudo modprobe xpad

and looking at the kernel log with dmesg | tail

# Default Linux driver shows
[  367.808250] input: Microsoft X-Box One pad as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/input/input1
[  367.808955] usbcore: registered new interface driver xpad

# RetroPie driver shows
[  640.816875] xpad: loading out-of-tree module taints kernel.
[  640.818925] input: Microsoft X-Box One pad as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/input/input2
[  640.819752] usbcore: registered new interface driver xpad

@buzz - you think the xpad.sh script can be modified (adding --force to the install step) to get rid of this error ?

BuZz

@mitu yeah. Will sort. Thanks