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

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)

ChuckyP

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

roslof

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

Headrush69

@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.

roslof

@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% ;-)

Headrush69

@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).

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.

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?

roslof

@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

Headrush69

@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.

GoG

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.

roslof

@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.

SuperJim

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.

SuperJim

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.

roslof

@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.

MrLightgun

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.

roslof

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

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.

ChuckyP

@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.

mitu

@roslof The RetroPie script is not using the RA's latest source, it's pinned to a release (right now it's at 17.6). If you wish to get the latest version, then you'll need to compile it separately and move the resulting binary in the installation folder (/opt/retropie/emulators/retroarch/bin).