• Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login
RetroPie forum home
  • Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login
Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

Most recently connected Bluetooth controller becomes player 1?

Scheduled Pinned Locked Moved Help and Support
bluetooth wiiupi3b+player number
13 Posts 3 Posters 1.2k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V
    vt_fbcoach
    last edited by 21 Oct 2020, 18:37

    Pi Model or other hardware: 3B+
    Power Supply used: CanaKit 5V 2.5A Raspberry Pi 3 B+ Power Supply/Adapter
    RetroPie Version Used: 4.6.9
    Built From: Pre made SD Image on RetroPie website
    USB Devices connected: 128 GB flash drive; TP-Link Bluetooth adapter
    Controller used: Wii U Pro Controller (x2; originals bought in-store)
    Guide used: https://retropie.org.uk/docs/Bluetooth-Controller/

    Due to frequent ghost inputs with my two Wii U Pro Controllers (e.g., randomly exiting a game, starting a different ROM from the Emulation Station menu, etc) I recently purchased an external TP-Link USB Bluetooth dongle (see above). After disabling the internal Bluetooth by adding dtoverlay=pi3-disable-bt to /boot/config.txt, connecting the USB dongle, and re-pairing the two Wii U Pro Controllers, everything seems to be working fine and I haven't noticed any ghost inputs over the last few days.

    I have also installed pyhammond's retropie_wiimote_lights script to correctly display the player number lights on each of the Wii U Pro Controllers (by default they will always show the P1 light). After installing this script, I have noticed some strange behavior with the player number assigned to each controller which I am not sure whether to attribute to the USB Bluetooth adapter, Emulation Station, RetroArch, or something else entirely. For example,

    1. Connect a controller (C1) and its P1 light turns on
    2. Connect a second controller (C2) and its P1 light turns on; C1's light changes from P1 to P2
    3. When playing a multiplayer game, C2 does indeed control Player 1 and C1 controls Player 2 as indicated by their lights

    However, jstest shows that js0 does in fact correspond to the first connected controller (C1 controlling P2) and js1 corresponds to the second connected controller (C2 controlling P1). Is this the expected behavior that the most recently connected controller takes over as Player 1 and bumps all previously connected controllers to higher player numbers? Or is this some quirk of the external USB Bluetooth dongle?

    To test, I have deleted the wii-controller.service file copied by the retropie_wiimote_lights script to /etc/systemd/system/ and the above described behavior persists, so I do not think that script is the issue. I have also checked the contents of my retroarch.cfg file at /opt/retropie/configs/all and can confirm the joypad index values have not been modified from the defaults. And I have tried uncommenting the first two joypad index lines (input_player1_joypad_index = 0 and input_player2_joypad_index = 1) but even after rebooting the system the second connected controller always takes over as Player 1. Unfortunately I do not have any other controllers (wired, Bluetooth, or otherwise) with which to test this behavior.

    Thank you for the help!

    1 Reply Last reply Reply Quote 0
    • M
      mitu Global Moderator
      last edited by 21 Oct 2020, 19:08

      Can you run (with both controllers connected)

      cat /proc/bus/input/devices
      

      and post the output ?

      1 Reply Last reply Reply Quote 0
      • V
        vt_fbcoach
        last edited by 21 Oct 2020, 19:32

        Yes, here is the output:

        pi@retropie:~ $ cat /proc/bus/input/devices 
        I: Bus=0005 Vendor=057e Product=0330 Version=0001
        N: Name="Nintendo Wii Remote Pro Controller"
        P: Phys=
        S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:74/0005:057E:0330.0001/input/input0
        U: Uniq=
        H: Handlers=js0 event0 
        B: PROP=0
        B: EV=20000b
        B: KEY=f 0 0 0 0 0 0 0 7fdb0000 0 0 0 0 0 0 0 0 0
        B: ABS=1b
        B: FF=1 7030000 0 0
        
        I: Bus=0005 Vendor=057e Product=0330 Version=0001
        N: Name="Nintendo Wii Remote Pro Controller"
        P: Phys=
        S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:69/0005:057E:0330.0002/input/input1
        U: Uniq=
        H: Handlers=js1 event1 
        B: PROP=0
        B: EV=20000b
        B: KEY=f 0 0 0 0 0 0 0 7fdb0000 0 0 0 0 0 0 0 0 0
        B: ABS=1b
        B: FF=1 7030000 0 0
        
        
        1 Reply Last reply Reply Quote 0
        • M
          mitu Global Moderator
          last edited by mitu 21 Oct 2020, 19:52

          You issue sounds a bit similar to this issue on the wiimote_lights repository, except that in the reported case, the lights were switched differently. What's in common with that issue is the external BT dongle and I think the script has an option to switch the numbering if you choose the external install/configure options.

          What's different is that - in your case - the /dev/input/eventX numbering is the same as /dev/input/jsX, so the RetroArch should choose js0 as P1 even if it sorts by/dev/input/eventX files.

          If you're absolutely sure there's no input remapping taking place in RetroArch, try to get a verbose log when running a 2P game and post it on pastebin.com.

          1 Reply Last reply Reply Quote 0
          • V
            vt_fbcoach
            last edited by 21 Oct 2020, 20:41

            Thank you for the help - here is the link to the verbose log from a 2P game (Super Mario Kart using lr-snes9x2010):

            https://pastebin.com/MbNEjccy

            These appear to be the lines of note where the controller input numbers are being assigned (lines 83-91 of the pastebin):

            [WARN] [udev]: Couldn't open any keyboard, mouse or touchpad. Are permissions set correctly for /dev/input/event*?
            [INFO] [udev]: Plugged pad: Nintendo Wii Remote Pro Controller (1406:816) on port #0.
            [INFO] [udev]: Pad #0 (/dev/input/event1) supports force feedback.
            [INFO] [udev]: Pad #0 (/dev/input/event1) supports 16 force feedback effects.
            [INFO] [udev]: Plugged pad: Nintendo Wii Remote Pro Controller (1406:816) on port #1.
            [INFO] [udev]: Pad #1 (/dev/input/event0) supports force feedback.
            [INFO] [udev]: Pad #1 (/dev/input/event0) supports 16 force feedback effects.
            [INFO] [Joypad]: Found joypad driver: "udev".
            [WARN] [udev]: Full-screen pointer won't be available.
            

            It appears to be using the event* handlers rather than the js* handlers, correct? But as you noted, event0/js0 and event1/js1 are assigned to the controllers in the order in which they were connected via Bluetooth. It is the Pad #* which does not appear to be correct.

            For completeness, here is a copy of my retroarch.cfg file from /opt/retropie/configs/all:

            https://pastebin.com/hQ4U2c4S

            1 Reply Last reply Reply Quote 0
            • C
              Clyde
              last edited by 21 Oct 2020, 21:47

              The user @meleu made a script to change the player-controller assignment based on either name or joystick index. Maybe that could help?

              https://retropie.org.uk/forum/topic/1167/here-is-a-way-to-select-joystick-for-players-1-4-global-or-emu-specific

              1 Reply Last reply Reply Quote 0
              • V
                vt_fbcoach
                last edited by 22 Oct 2020, 01:10

                Thank you for the suggestion, but I'm not sure how effective that script will be given the last sentence of the readme file says:

                • If you are using joysticks with equal names, then, yes, the connection order matters.

                and I am using controllers with equal names but the connection order is not being interpreted correctly.

                Interestingly, if I connect the second controller midway through an already active game (for example, an arcade game such as the 2-player version of TMNT: Turtles in Time), the lights will still change as before when a new controller is connected (ie, C1 light changes from P1 to P2, C2 light shows P1). But the first connected controller will still be Player 1 and the second connected controller will be Player 2. If I exit to Emulation Station and re-enter the same game (or any others), the second connected controller will now be Player 1 and the first connected controller will be Player 2 (the original problem described in this thread).

                1 Reply Last reply Reply Quote 0
                • V
                  vt_fbcoach
                  last edited by vt_fbcoach 22 Oct 2020, 02:08

                  Ok, so it looks like the fix proposed and implemented by pyhammond for external Bluetooth adapters in 2017 is no longer present in the udev_joypad.c file of RetroArch as of this pull request in July 2019.

                  Reading through the pull request comments, it doesn't sound like anyone besides the author of the change actually tested this modification...

                  EDIT: Actually, it looks like this fix for external Bluetooth adapters was removed because of its impact on wired USB controllers: https://retropie.org.uk/forum/topic/17276/usb-ports-no-longer-determine-player-number-retroarch-1-7-1/59

                  So I guess it would be nice to have the option to re-enable the old qsort behavior? Or maybe I just need to modify the source code locally and re-compile?

                  1 Reply Last reply Reply Quote 0
                  • M
                    mitu Global Moderator
                    last edited by 22 Oct 2020, 03:20

                    Can you also take a look in /opt/retropie/configs/snes/retroarch.cfg to see if any joypad re-ordering hasn't been set ?

                    The patch mentioned in issue is now no longer part of RetroArch, it's been superseded by this one, which should produce identical results for your configuration (i.e. it uses the ordered /dev/input/eventX nodes).

                    1 Reply Last reply Reply Quote 0
                    • V
                      vt_fbcoach
                      last edited by vt_fbcoach 22 Oct 2020, 11:34

                      Here are the contents of my /opt/retropie/configs/snes/retroarch.cfg file:

                      # Settings made here will only override settings in the global retroarch.cfg if placed above the #include line
                      
                      input_remapping_directory = "/opt/retropie/configs/snes/"
                      
                      savefile_directory = "/home/pi/RetroPie/roms/snes/saves"
                      savestate_directory = "/home/pi/RetroPie/roms/snes/saves"
                      
                      #include "/opt/retropie/configs/all/retroarch.cfg"
                      

                      According to this post by pyhammond:

                      https://github.com/pyhammond/retropie_wiimote_lights/issues/1#issuecomment-362658937

                      "The problem with the emulators seems to be that internally, they loop through and do a specific system-call [ udev_enumerate_get_list_entry() ] in order to get the controller from the system. When you are using an external dongle, for some reason the controllers don't come back from the system call in the order that they appear under /dev/input. That's where the discrepancy lies."

                      So the fix implemented by pyhammond corrected this issue for Bluetooth controllers with an external adapter, but that presented problems for users with controllers wired to specific USB ports:

                      • https://retropie.org.uk/forum/topic/17276/usb-ports-no-longer-determine-player-number-retroarch-1-7-1/59
                      • https://github.com/libretro/RetroArch/issues/6707

                      And was ultimately reverted in these two commits to RetroArch:

                      • https://github.com/RetroPie/RetroPie-Setup/pull/2400 (May2018)
                      • https://github.com/libretro/RetroArch/pull/9074 (July 2019)

                      But it doesn't seem like either of these two more recent changes took into account the reversed ordering of Bluetooth controllers with an external adapter returned by udev. So I can appreciate why this fix was removed, but it would be nice to have the option to use it again when only Bluetooth controllers are being used with an external adapter.

                      M 1 Reply Last reply 22 Oct 2020, 11:41 Reply Quote 0
                      • M
                        mitu Global Moderator @vt_fbcoach
                        last edited by 22 Oct 2020, 11:41

                        @vt_fbcoach said in Most recently connected Bluetooth controller becomes player 1?:

                        Here are the contents of my /opt/retropie/configs/snes/retroarch.cfg file:

                        That doesn't look like it has any impact on controller ordering.

                        So I can appreciate why this fix was removed, but it would be nice to have the option to use it again when only Bluetooth controllers are being used with an external adapter.

                        I wouldn't be so sure that the patch would yield the desired effect and would worth the trouble.

                        For your immediate purposes, something inspired by

                        V 1 Reply Last reply 22 Oct 2020, 14:03 Reply Quote 0
                        • V
                          vt_fbcoach @mitu
                          last edited by 22 Oct 2020, 14:03

                          For your immediate purposes, something inspired by

                          @mitu Sorry, it looks like your message may have been prematurely cut off?

                          I've seen some posts online that this external Bluetooth adapter ordering issue is unique to udev, so I'll try changing input drivers to something else like sdl2 and report back.

                          1 Reply Last reply Reply Quote 0
                          • M
                            mitu Global Moderator
                            last edited by 22 Oct 2020, 14:33

                            @vt_fbcoach said in Most recently connected Bluetooth controller becomes player 1?:

                            @mitu Sorry, it looks like your message may have been prematurely cut off?

                            Yes, somehow I pressed enter before actually giving an answer, sorry.
                            You could leverage the onstart/onend scripts for runcommand to switch dynamically the joypad indexes when 2 gamepads are detected. Something similar to https://github.com/meleu/RetroPie-joystick-selection.

                            1 Reply Last reply Reply Quote 0
                            13 out of 13
                            • First post
                              13/13
                              Last post

                            Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

                            Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.

                              This community forum collects and processes your personal information.
                              consent.not_received