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

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

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 ?