XB1 pad works with ES but not games or Retroarch.
I also assumed that after installing the xpadneo driver with ./install.sh that retropie would automatically assign in to my controller? Or should i have assigned it myself in a setting somewhere?
No, the installation will only add the new driver and make it work with the device (hopefully), you'd still be needing to pair the new device and re-configure your input in Emulationstation.
A button works so i can select menues however my up and down buttons are erratic [...]
So the driver is not suited for your controller. You should uninstall it (there's an
uninstall.shscript in the source folder you downloaded from Github).
Can you run the command I mentioned earlier, to see the identification of the controller and check if
xpadis used for it ?
I paired the controller and re-configured it as if it was the first time.
Even before i installed the xpadneo driver it would do that though.
Ill try checking the identification next.
@mitu This is with the xpadneo driver
pi@retropie:~ $ cat /proc/bus/input/devices I: Bus=0005 Vendor=045e Product=02fd Version=1130 N: Name="Xbox Wireless Controller" P: Phys=b8:27:eb:9f:31:27 S: Sysfs=/devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11/0005:045 E:02FD.0008/input/input9 U: Uniq=5c:ba:37:47:3a:ba H: Handlers=js0 event0 B: PROP=0 B: EV=20001b B: KEY=7cdb0000 0 0 0 0 0 0 0 0 0 B: ABS=3003f B: MSC=10 B: FF=1 7030000 0 0 pi@retropie:~ $
@hallda12 It doesn't matter which driver is installed. The VendorID is 045e and the ProductID is 02fd. I don't see this combination registered by the
xpaddriver. However, it should be supported by the
Your controller is actually a Xbox One S model (terrible naming by Microsoft), which I don't think is handled by
Can you try running
udevadm info -q all /dev/input/event0 lsmod | grep xpad
to see if the
xpadneohas been registered for the device and the driver is loaded ?
pi@retropie:~ $ udevadm info -q all /dev/input/event0 P: /devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11/0005:045E:02FD.0008/input/input9/event0 N: input/event0 E: DEVNAME=/dev/input/event0 E: DEVPATH=/devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11/0005:045E:02FD.0008/input/input9/event0 E: ID_BUS=bluetooth E: ID_FOR_SEAT=input-platform-soc E: ID_INPUT=1 E: ID_INPUT_JOYSTICK=1 E: ID_PATH=platform-soc E: ID_PATH_TAG=platform-soc E: LIBINPUT_DEVICE_GROUP=5/45e/2fd/1130:b8:27:eb:9f:31:27 E: MAJOR=13 E: MINOR=64 E: SUBSYSTEM=input E: TAGS=:seat:uaccess: E: USEC_INITIALIZED=13679312933 pi@retropie:~ $ lsmod | grep xpad hid_xpadneo 20480 0 ff_memless 16384 1 hid_xpadneo pi@retropie:~ $
OK, so the driver is installed and loaded.
Can you try re-setting again your input configuration - like explained here - , remove all paired Bluetooth devices, pair it again and then re-try configuring the controller ?
@mitu Ok this is getting weird. Ive reset the input and reconfigured bluetooth. At the point of mapping the Left trigger it maps, pauses and then skips the Right trigger leaving it "Un-definded". I then have to map the rest of my buttons and then go back up so i can map Right trigger. BTW this has been happening since the beginning but i never thought this might cause an issue as by the time I'm finished all the buttons seem to be mapped to a corresponding number.
So i now go into retroarch and the controller appears un-responsive like usuall until i mash all the buttons. I then realize i can fully use all of the menu by Holding left trigger. As soon as i let go i am unable to use the menu. So as long as im holding L2 my controller works haha
Any ideas whats happening?
Any ideas whats happening?
Beats me. But I would repeat the re-configuration, skip the triggers and see if you get a usable configuration.
@mitu Just tried it and it works perfect in every emulator. Even the hotkeys. Who would of thought that the triggers would cause so many problems.
Im still unsure where the issue lies. Maybe i have a faulty controller? Seems to work my xbox fine and maybe the pie is ultra sensitive to how the pad responds.
@hallda12 What I think it might happen is that the triggers are actually registered as analog axes instead of just button presses. The
xpaddriver has a parameter for this (
triggers_to_buttons) which is always on in the RetroPie installations and disables this behavior. It doesn't seem that
xpadneohas a similar parameter - or it behaves differently.
You can try and running
jstest /dev/input/js0from the command line and see how the trigger appear - button presses or axis movement.