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

    Retroarch cores crash on trigger press (Mouse Click) with overlay active

    Scheduled Pinned Locked Moved
    Help and Support
    lr-fceumm wiimote lightgun overlay
    13
    50
    7.4k
    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.
    • C
      ChuckyP @Headrush69
      last edited by

      @headrush69 please update me if you find anything.

      H 1 Reply Last reply Reply Quote 0
      • H
        Headrush69 @ChuckyP
        last edited by Headrush69

        @chuckyp So the problem doesn't appear to be specific to any Retroarch core, so like you, I tried a clean install, same issue.

        I next tried using the linuxraw and sdl2 input drivers in Retroarch, no success.

        I reverted and compiled the previous 1.7.2 version of Retroarch and problem there as well.

        Thinking maybe it was an issue with my recent trackball added to my iPac2, I tried without using it and just using a standard mouse. Still had the same issue.

        So looking at the verbose logs of Retroarch I noticed that it referenced 2 mice.
        My system only has 1 mouse.

        From there I looked at /dev/input/by-id/ and noticed that dev input rules seem to create 2 entries for each input devices.

        alt text

        I don't know enough about udev's event model, but it look like Retroarch was defaulting to mouse index 0 which was /dev/input/mouse0

        If in Retroarch, I go into controls and set the mouse index to 1, which is /dev/input/event4, the system no longer locks up.

        For now it's a temporary fix until I can figure out what the difference between the 2 device entries for each input options mean.

        Edit: Further testing with the mouse index set to #1 in Retroarch and mouse buttons work as expected in games with mouse support as well. (Centiped for example)

        C 1 Reply Last reply Reply Quote 1
        • C
          ChuckyP @Headrush69
          last edited by

          @headrush69 can’t wait to make this change and see if it works. Thanks for the update.

          1 Reply Last reply Reply Quote 0
          • roslofR
            roslof
            last edited by

            Coincidentally, my mouse index needs to be set to 1. Any other value means the trackball itself will not function.

            Where are you setting the mouse index? I'm going through the Retroarch GUI (not quick menu):

            Main Menu
            Settings
            Input
            Input User 1 Binds
            User 1 Mouse Index (1) <-- was originally 0, which is not my trackball

            So no change on my end, so far. Trackball works, but left-click freezes all Retroarch games when an overlay is displayed.

            Let me know if you set your index in another area or CFG. Maybe there's a conflict somewhere that I'm just not seeing.

            Best!
            -Ros

            1 Reply Last reply Reply Quote 0
            • H
              Headrush69
              last edited by

              @headrush69 said in Retroarch cores crash on trigger press (Mouse Click) with overlay active:

              Can you post the output of: ls -l /dev/input/by-id/

              If you set log_level to 0 and verbose_logging to ON in your retroarch.cfg file, when you check the log file do you see references to 2 mice?

              This will determine if we are dealing with the same issue.
              Coincidently, when my mouse index was set to 0, my trackball (aka mouse) always worked, it was just pressing the mouse button caused the freeze.

              roslofR 1 Reply Last reply Reply Quote 0
              • roslofR
                roslof @Headrush69
                last edited by

                @headrush69 it could be a different issue

                I'm using:
                A keyboard w/touchpad (pointer) identified as "_mini_keyboard"
                A PS4 controller which has a touchpad identified as "Sony_Interactive"...
                And a bluetooth Kensington trackball/mouse (which doesn't appear at all in Input)

                /dev/input/by-id shows the following:

                usb-_mini_keyboard-event-kbd usb-_mini_keyboard-if01-event-mouse usb-_mini_keyboard-if01-mouse usb-Sony_Interactive_Entertainment_Wireless_Controller-event-if03 usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-event-joystick usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-event-mouse usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-joystick

                Again there is no reference to the actual Kensington trackball. The trackball/mouse works perfectly for everything EXCEPT when there is any retroarch overlay being displayed. Otherwise, the button and trackball input work as expected.

                Definitely feels like a bug and I'm not clear if there is a work-around for me. I tried removing hardware, deleting retroarch configs/etc. No luck. Changing the index doesn't do anything for me, other than have the trackball work 100% or 0% ;-)

                H 1 Reply Last reply Reply Quote 0
                • H
                  Headrush69 @roslof
                  last edited by

                  @roslof said in Retroarch cores crash on trigger press (Mouse Click) with overlay active:

                  usb-_mini_keyboard-event-kbd usb-_mini_keyboard-if01-event-mouse usb-_mini_keyboard-if01-mouse usb-Sony_Interactive_Entertainment_Wireless_Controller-event-if03 usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-event-joystick usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-event-mouse usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-joystick

                  I needed to see the output from using ls -l, not just ls, as this shows the actual events each device is attached to.

                  Also, needed to see the verbose debug output from Retroarch so we can see what and how it is identifying your devices.

                  I understand about the trackball working, mine did too, except with the overlays.
                  I believe overlays in Retroarch were originally designed with inputs in mind. (on screen).

                  roslofR 1 Reply Last reply Reply Quote 0
                  • roslofR
                    roslof @Headrush69
                    last edited by roslof

                    I needed to see the output from using ls -l, not just ls, as this shows the actual events each device is attached to.

                    Also, needed to see the verbose debug output from Retroarch so we can see what and how it is identifying your devices.

                    I understand about the trackball working, mine did too, except with the overlays.
                    I believe overlays in Retroarch were originally designed with inputs in mind. (on screen).

                    Gotcha.

                    From ls -l:

                    usb-_mini_keyboard-event-kbd -> ../event0
usb-_mini_keyboard-if01-event-mouse -> ../event1
usb-_mini_keyboard-if01-mouse -> ../mouse0
usb-Sony_Interactive_Entertainment_Wireless_Controller-event-if03 -> ../event3
usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-event-joystick -> ../event4
usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-event-mouse -> ../event2
usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-joystick -> ../js0

                    Relevant info from the verbose log (launching Centipede):

                    [ERROR] [udev] Failed to open device: /dev/input/event3 (Success).
[INFO] [udev]: Mouse #0 (/dev/input/mouse0).
[INFO] [udev]: Mouse #1 (/dev/input/event5).
[INFO] [udev]: Mouse #2 (/dev/input/mouse1).
[ERROR] [udev] Failed to open device: /dev/input/event1 (Success).

                    Appreciate the help here.

                    H 1 Reply Last reply Reply Quote 0
                    • H
                      Headrush69 @roslof
                      last edited by Headrush69

                      @roslof Weird that Retroarch is getting the 3 mouse inputs properly from UDEV, but the listing in /dev/input/by-id/ isn't showing the Kensington Trackball.

                      Can you post the output of :

                      udevadm info -a -p $(udevadm info -q path -n /dev/input/mouse1)

                      and

                      udevadm info -a -p $(udevadm info -q path -n /dev/input/event5)

                      and

                      lsusb

                      By chance did you tried setting mouse index to 2 in Retroarch?

                      roslofR 1 Reply Last reply Reply Quote 0
                      • roslofR
                        roslof @Headrush69
                        last edited by

                        @Headrush69 - No problem. Posted below. Lots of stuff to scroll through though. Note that I did try Mouse Index #2 and the track is unresponsive. Here is the output of each request:

                        udevadm info -a -p $(udevadm info -q path -n /dev/input/mouse1)

                          looking at device '/devices/virtual/misc/uhid/0005:047D:8019.0006/input/input7/mouse1':
    KERNEL=="mouse1"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/virtual/misc/uhid/0005:047D:8019.0006/input/input7':
    KERNELS=="input7"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{name}=="Expert Wireless TB"
    ATTRS{phys}=="B8:27:EB:BD:74:AD"
    ATTRS{properties}=="0"
    ATTRS{uniq}=="F6:CD:BB:40:49:C9"

  looking at parent device '/devices/virtual/misc/uhid/0005:047D:8019.0006':
    KERNELS=="0005:047D:8019.0006"
    SUBSYSTEMS=="hid"
    DRIVERS=="hid-generic"
    ATTRS{country}=="00"

  looking at parent device '/devices/virtual/misc/uhid':
    KERNELS=="uhid"
    SUBSYSTEMS=="misc"
    DRIVERS==""

                        udevadm info -a -p $(udevadm info -q path -n /dev/input/event5)

                          looking at device '/devices/virtual/misc/uhid/0005:047D:8019.0006/input/input7/event5':
    KERNEL=="event5"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/virtual/misc/uhid/0005:047D:8019.0006/input/input7':
    KERNELS=="input7"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{name}=="Expert Wireless TB"
    ATTRS{phys}=="B8:27:EB:BD:74:AD"
    ATTRS{properties}=="0"
    ATTRS{uniq}=="F6:CD:BB:40:49:C9"

  looking at parent device '/devices/virtual/misc/uhid/0005:047D:8019.0006':
    KERNELS=="0005:047D:8019.0006"
    SUBSYSTEMS=="hid"
    DRIVERS=="hid-generic"
    ATTRS{country}=="00"

  looking at parent device '/devices/virtual/misc/uhid':
    KERNELS=="uhid"
    SUBSYSTEMS=="misc"
    DRIVERS==""

                        lsusb

                        Bus 001 Device 005: ID 054c:09cc Sony Corp.
Bus 001 Device 007: ID 1997:2433
Bus 001 Device 006: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

                        Hope this is helpful

                        H 1 Reply Last reply Reply Quote 0
                        • H
                          Headrush69 @roslof
                          last edited by

                          @roslof Can you also post the output of cat /proc/bus/input/devices

                          Can you plug in your bluetooth dongle after starting the Pi and then checking lsusb

                          Having 3 mouse devices connected at once is making diagnosing a little harder.
                          It would be best to just use your mini_keyboard with touchpad as mouse and see if setting the mouse index in Retroarch with just one device attached still causes the same issue.

                          1 Reply Last reply Reply Quote 0
                          • G
                            GoG
                            last edited by

                            I am wondering if anyone has figured out a resolution to this problem? My trackball and mouse work fine if I disable overlays on mouse index 0, but if overlays are enabled, it locks up on left mouse click. I really like the look of the overlays / bezels, so I would like to use them. I have tried a few different Retropie loads, even one that was made in 2019 with the latest bells and whistles, but it is still no go... really frustrating, but I realize I am in the minority with using a trackball with retropie.

                            roslofR 1 Reply Last reply Reply Quote 0
                            • roslofR
                              roslof @GoG
                              last edited by

                              @GoG I wish. I realized after a clean install and the problem still occurred that this is a retroarch issue that has not yet been solved. I tried all kinds of different combos of controllers and such to no success.

                              Shame, because I devoted a ton of time to perfecting overlays, only to not have trackball button support.

                              So I remove the overlays for the games that are designed for trackballs.

                              Boo... But at least that's a type of work-around.

                              1 Reply Last reply Reply Quote 0
                              • S
                                SuperJim
                                last edited by

                                I also have this issue, but in my case I am using a custom HID composite device that implements two joysticks, mouse and keyboard (media keys only).

                                I have noticed that the mouse is detected twice in the runcommand.log,
                                [INFO] [udev]: Mouse #0 (/dev/input/event2).
                                [INFO] [udev]: Mouse #1 (/dev/input/mouse0).

                                These two entries are the same device,

                                pi@retropie:~ $ ls -lr /dev/input/*
                                crw-rw---- 1 root input 13, 32 Feb 5 21:37 /dev/input/mouse0
                                crw-rw---- 1 root input 13, 63 Feb 5 21:37 /dev/input/mice
                                crw-rw----+ 1 root input 13, 1 Feb 5 21:37 /dev/input/js1
                                crw-rw----+ 1 root input 13, 0 Feb 5 21:37 /dev/input/js0
                                crw-rw---- 1 root input 13, 69 Feb 5 21:37 /dev/input/event5
                                crw-rw---- 1 root input 13, 68 Feb 5 21:37 /dev/input/event4
                                crw-rw---- 1 root input 13, 67 Feb 5 21:37 /dev/input/event3
                                crw-rw---- 1 root input 13, 66 Feb 5 21:37 /dev/input/event2
                                crw-rw----+ 1 root input 13, 65 Feb 5 21:37 /dev/input/event1
                                crw-rw----+ 1 root input 13, 64 Feb 5 21:37 /dev/input/event0

                                /dev/input/by-path:
                                total 0
                                lrwxrwxrwx 1 root root 9 Feb 5 21:37 platform-soc:shutdown_button-event -> ../event5
                                lrwxrwxrwx 1 root root 9 Feb 5 21:37 platform-3f980000.usb-usb-0:1.1.2:1.0-mouse -> ../mouse0
                                lrwxrwxrwx 1 root root 6 Feb 5 21:37 platform-3f980000.usb-usb-0:1.1.2:1.0-joystick -> ../js1
                                lrwxrwxrwx 1 root root 9 Feb 5 21:37 platform-3f980000.usb-usb-0:1.1.2:1.0-event-mouse -> ../event2
                                lrwxrwxrwx 1 root root 9 Feb 5 21:37 platform-3f980000.usb-usb-0:1.1.2:1.0-event-joystick -> ../event0
                                lrwxrwxrwx 1 root root 9 Feb 5 21:37 platform-3f980000.usb-usb-0:1.1.2:1.0-event -> ../event4

                                /dev/input/by-id:
                                total 0
                                lrwxrwxrwx 1 root root 9 Feb 5 21:37 usb-JEB_Arcade_Interface_00000000001A-mouse -> ../mouse0
                                lrwxrwxrwx 1 root root 6 Feb 5 21:37 usb-JEB_Arcade_Interface_00000000001A-joystick -> ../js1
                                lrwxrwxrwx 1 root root 9 Feb 5 21:37 usb-JEB_Arcade_Interface_00000000001A-event-mouse -> ../event2
                                lrwxrwxrwx 1 root root 9 Feb 5 21:37 usb-JEB_Arcade_Interface_00000000001A-event-joystick -> ../event0
                                lrwxrwxrwx 1 root root 9 Feb 5 21:37 usb-JEB_Arcade_Interface_00000000001A-event-if00 -> ../event4

                                I experimented by deleting event2, and then the crash no longer happens on button press; the mouse is detected in the log file, but then doesn't appear to function properly (doesn't work in dosbox or scummvm, does work in amiberry).

                                When the crash does happen, the retroarch process immediately goes to 100%, and can only be killed using -9... then you drop back to emulationstation as expected.

                                1 Reply Last reply Reply Quote 0
                                • S
                                  SuperJim
                                  last edited by

                                  I have made further progress in tracking down the problem, but I don't really understand how the input driver code works. I used gdb to determine retroarch was stuck in input_poll_overlay()

                                  What I can say for certain is that the following loop in function input_poll_overlay() from file input\input_overlay.c never exits,

                                  for (i = 0;
      input_ptr->input_state(input_data, joypad_info, NULL, 0, device, i, RETRO_DEVICE_ID_POINTER_PRESSED);
      i++)
{
   input_overlay_state_t polled_data;
   int16_t x = input_ptr->input_state(input_data, joypad_info, NULL, 0, device, i, RETRO_DEVICE_ID_POINTER_X);
   int16_t y = input_ptr->input_state(input_data, joypad_info, NULL, 0, device, i, RETRO_DEVICE_ID_POINTER_Y);

   memset(&polled_data, 0, sizeof(struct input_overlay_state));

   if (ol->enable)
   {
       input_overlay_poll(ol, &polled_data, x, y);
   }
   else
      ol->blocked = false;

   bits_or_bits(ol_state->buttons.data, polled_data.buttons.data, ARRAY_SIZE(polled_data.buttons.data));

   for (j = 0; j < ARRAY_SIZE(ol_state->keys); j++)
      ol_state->keys[j] |= polled_data.keys[j];

   // Fingers pressed later take priority and matched up with overlay poll priorities.
   for (j = 0; j < 4; j++)
      if (polled_data.analog[j])
         ol_state->analog[j] = polled_data.analog[j];

   polled = true;
}

                                  I've had trouble following how exactly input_ptr->input_state works, however it evidently stays true in the loop statement forever, which is why it locks up.

                                  input_overlay_poll() is called every time, but as far as I can tell does nothing, because ol->active->size is always zero, so the loop is never executed.

                                  I can bypass input_poll_overlay() completely by just immediately returning, and stop the lockup, then the mouse pointer still works, but the buttons don't.

                                  roslofR 1 Reply Last reply Reply Quote 0
                                  • roslofR
                                    roslof @SuperJim
                                    last edited by

                                    @SuperJim Great progress on the debugging here. Glad to see somebody with some engineering chops took the time to take a look. Clearly, there is something funky, but I don't know if anybody can help take this to the next level.

                                    Is there Retroarch documentation somewhere for how to submit bugs and such? With this information, maybe somebody more involved with Retroarch could devote time to investigate further.

                                    1 Reply Last reply Reply Quote 0
                                    • M
                                      MrLightgun
                                      last edited by

                                      Good news, I logged this as a Retroarch issue on github referencing this thread:

                                      https://github.com/libretro/RetroArch/issues/8326

                                      Orbea and Casdevel kindly assisted in resolving the issue and a fix has been commited to RetroArch.

                                      Big thanks to everyone in this thread that provided information.

                                      roslofR C 2 Replies Last reply Reply Quote 2
                                      • roslofR
                                        roslof @MrLightgun
                                        last edited by

                                        @MrLightgun YES! That is GREAT news! Thank you for helping to make this happen.

                                        1 Reply Last reply Reply Quote 0
                                        • roslofR
                                          roslof
                                          last edited by roslof

                                          I updated the Retropie script and attempted to update Retroarch by source, but I don't believe the fix/change made it down yet. I'm not clear on how to view when a fix moves into RetroArch master or otherwise how to build it without the RetroPie Script.

                                          mituM 1 Reply Last reply Reply Quote 0
                                          • C
                                            ChuckyP @MrLightgun
                                            last edited by

                                            @MrLightgun what a fitting name to be bringing this update. It has been a while since I had started looking for a solution to this problem... and for once it wasn’t something simple I had overlooked.

                                            Thanks to everyone for jumping in and keeping this active. Can’t wait for the official release of this fix.

                                            1 Reply Last reply Reply Quote 1
                                            • First post
                                              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.