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

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

SuperJim

I've tried adding the change, and it was successful! I've listed the steps below if you want to compile it yourself. ~~I believe the --enable-neon flag should be added to the configure command, but it won't work for me with that included~~. * note the configure command is one line, ending with --enable-dispmanx; it seems be wrapping below.

Update using the script to ensure you have 1.7.6 installed,
~/RetroPie-Setup/retropie_setup.sh

cd
git clone https://github.com/libretro/RetroArch.git
cd RetroArch
git checkout tags/v1.7.6

<RPI2 only>
CFLAGS="-O2 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations" ./configure --disable-sdl --enable-sdl2 --disable-oss --disable-al --disable-jack --disable-qt --disable-x11 --disable-pulse --enable-neon --enable-floathard --enable-dispmanx

<RPI3 only>
CFLAGS="-O2 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations" ./configure --disable-sdl --enable-sdl2 --disable-oss --disable-al --disable-jack --disable-qt --disable-x11 --disable-pulse --enable-neon --enable-floathard --enable-dispmanx

git apply ~/RetroPie-Setup/scriptmodules/emulators/retroarch/01_hotkey_hack.diff
git apply ~/RetroPie-Setup/scriptmodules/emulators/retroarch/02_disable_search.diff
git apply ~/RetroPie-Setup/scriptmodules/emulators/retroarch/03_disable_udev_sort.diff

using whatever editor you prefer, edit input/drivers/udev_input.c, line 991 and replace,

  case RETRO_DEVICE_POINTER:
       return udev_pointer_state(udev, port, id, false);
  case RARCH_DEVICE_POINTER_SCREEN:
       return udev_pointer_state(udev, port, id, true);

with the following,

  case RETRO_DEVICE_POINTER:
    if (idx == 0) /* multi-touch unsupported (for now) */
       return udev_pointer_state(udev, port, id, false);
    break;
  case RARCH_DEVICE_POINTER_SCREEN:
    if (idx == 0) /* multi-touch unsupported (for now) */
       return udev_pointer_state(udev, port, id, true);
    break;

make
sudo cp retroarch /opt/retropie/emulators/retroarch/bin

WarC0zes

@SuperJim I'm a beginner for compile. It's possible to share your compiled retroarch with the fix?

SuperJim

I don't think I can upload files here.

roslof

@SuperJim your steps worked like a charm. Feels amazing to finally be able to play trackball games w/overlays. Thanks Jim & all for helping make this fix a reality after so long...

maxbeanz

Does anyone know if this has been fixed yet or do we still have to manually do @SuperJim 's fix above ? I'm about to redo my Pi setup.

mitu

@maxbeanz It has only been fixed upstream, but the fix is not yet part of the RetroArch package in RetroPie.

maxbeanz

@mitu So it's safe to just update RetroArch from source ?

mitu

@maxbeanz No and no. The source update would still get you the 1.7.6 version (before the fix was added) and removing the version tag from the source script would not be able compile the latest dev/master (due to https://github.com/libretro/RetroArch/issues/8448).
I suggest to either apply the patch to the 1.7.6 build or wait for the next RetroArch package release.

maxbeanz

OK thanks, i'll bookmark this page.

One last thing, he says 'enable neon' should be added but it doesn't work for him. Is this going to make much difference for Raspberry Pi 3 ?

mitu

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

One last thing, he says 'enable neon' should be added but it doesn't work for him.

Because the configuration script needs some CFLAGS set to enable NEON for the compiler. These are added automatically by the RetroPie setup script so --enable-neon would work and NEON would be enabled by the configuration script. See here.

Is this going to make much difference for Raspberry Pi 3 ?

IMHO yes.

SuperJim

It's the configure command that fails, with the following message,

Checking presence of predefined macro __ARM_NEON__ ... no
Build assumed that __ARM_NEON__ is defined, but it's not. Exiting ...

I googled around for it, and it sounds like the specific name for this macro may have changed? In any case, the command worked with 1.7.5, but not with 1.7.6; I'm guessing there's a simple change that would fix it. I also don't think the mali option is actually needed on the pi.