Retroarch: Feature request: "Grab mouse" option to be permanently enabled via a configuration option, or core override config option

[singularity098]

Description

Mouse input is very tricky at the moment on Linux, because we have an issue in which the mouse input will only allow a very limited range of movement before it stops being registered, presumably once the mouse "leaves the window", even playing on fullscreen. This even means that you cannot move your character to certain parts of the screen in Centipede for example.

To workaround this you can use F12 to toggle "grab mouse". However in my case I am playing these games on an actual MAME arcade machine. This does not have a keyboard, and it's a pain to have to hook one up to press F12 (or any other key) every time I want to play a mouse (trackball) game.

In my opinion the ideal fix for this inconvenience is to enable "grab mouse" option to be permanently turned on, instead of a toggle key. I could set this as a core override option in MAME, or just leave it on at all times.

Version/Commit

• RetroArch: v1.7.5

Environment information

• OS: Ubuntu v18.10

[orbea]

Can you reproduce this in the RetroArch menu when no core is running? I can't, but I am not sure I have any games with mouse support to test.

Also is running RetroArch fullscreen not an option? It seems like it would reduce any chance of this happening.

[singularity098]

When I enable the mouse in the menus, it behaves fine in the menus... nothing weird going on there.

It's only in-game where it is a problem.

And I have been running fullscreen all along, which is why I find it kind of an odd problem. I've also experimented with doing windowed fullscreen instead, or with using different input drivers. I always have the same problem in-game.

It seems to be limited to Linux (Ubuntu 18.10 is my distro). I do not have this issue in Windows 10.

[orbea]

What core are you using? Are you capable of testing other cores?

[singularity098]

Certainly. I've tried this on the MAME (git v0.203) core playing Centipede. Also on the SNES9x core playing Mario Paint. And I've noted the behavior in FBA as well.... basically I cannot find any game/core where the issue is not occurring on my linux system, so it definitely seems to be OS/RetroArch related, not core related.

[orbea]

How about input drivers, which one are you using? Do any others work better or worse? Note, that your user will need to be part of the input group to use the udev input driver.

[i30817]

dosbox had a recent commit for something about mouse grab in X11, but it's a SDL problem.

https://bazaar.launchpad.net/~i30817/dosbox/trunk/revision/4061

[orbea]

SDL? If you are using the SDL input driver I would suggest trying another one and the SDL input driver is often not the best choice.

[singularity098]

The driver I've been using is actually "x".

I switched to udev. My normal controls still work, but this broke the trackball completely. It's just getting no input.

I've also tried linuxraw and SDL2... it produced the same result of the mouse not being able to move past a certain point.

[grant2258]

if you use my pull request your mouse should work under udev @singularity098

https://github.com/libretro/RetroArch/pull/7730

let me know how you get on

[singularity098]

Hi grant2258.... My RetroArch system (Ubuntu 18.10) is on the nightly build PPA and I did just update to the latest build (shows in RetroArch menu as Dec 19 build date).

It looks like your change was merged a few days ago... but my trackball still doesn't work when I choose udev input driver, it only works using the other drivers. I wonder if I could be missing something regarding whether I received the updated code, or anything else?

[grant2258]

hi could you possible do a

 ls -al /dev/input/

then type

and paste the output of the above commands so we can see permissions

and could you pastebin your ra log so we can see any errors it might have. that should give us a clearer picture of what going on.

[grant2258]

ls -al /dev/input/
total 0
drwxr-xr-x  4 root root     540 Dec 19 03:04 .
drwxr-xr-x 19 root root    3340 Dec 19 03:04 ..
drwxr-xr-x  2 root root     100 Dec 19 03:04 by-id
drwxr-xr-x  2 root root     140 Dec 19 03:04 by-path
crw-rw----  1 root input 13, 64 Dec 19 03:04 event0
crw-rw----  1 root input 13, 65 Dec 19 03:04 event1
crw-rw----  1 root input 13, 74 Dec 19 03:04 event10

grant cdrom floppy sudo audio dip video plugdev input netdev bluetooth lpadmin scanner

as you can see from the paste above the /dev/input is in the input group andI am in that group that way we know you dont have permission issues and can rule that out. Please note you need to re-log in after adding yourself to a group

[singularity098]

It looks to me that I'm already in the group... I had worked through the instructions for doing so in the docs a couple weeks ago.

singularity098@Linux-Arcade:~$ ls -al /dev/input
total 0
drwxr-xr-x   4 root root     580 Dec 20 19:11 .
drwxr-xr-x  20 root root    4020 Dec 20 19:11 ..
drwxr-xr-x   2 root root     220 Dec 20 19:11 by-id
drwxr-xr-x   2 root root     240 Dec 20 19:11 by-path
crw-rw----   1 root input 13, 64 Dec 20 19:11 event0
crw-rw----   1 root input 13, 65 Dec 20 19:11 event1
crw-rw----   1 root input 13, 74 Dec 20 19:11 event10
crw-rw----   1 root input 13, 75 Dec 20 19:11 event11
crw-rw----   1 root input 13, 76 Dec 20 19:11 event12
crw-rw----   1 root input 13, 77 Dec 20 19:11 event13
crw-rw----   1 root input 13, 78 Dec 20 19:11 event14
crw-rw----   1 root input 13, 79 Dec 20 19:11 event15
crw-rw----   1 root input 13, 80 Dec 20 19:11 event16
crw-rw----   1 root input 13, 81 Dec 20 19:11 event17
crw-rw----   1 root input 13, 82 Dec 20 19:11 event18
crw-rw----   1 root input 13, 83 Dec 20 19:11 event19
crw-rw-rw-   1 root input 13, 66 Dec 20 19:11 event2
crw-rw----   1 root input 13, 84 Dec 20 19:11 event20
crw-rw----   1 root input 13, 85 Dec 20 19:11 event21
crw-rw-rw-   1 root input 13, 67 Dec 20 19:11 event3
crw-rw-rw-   1 root input 13, 68 Dec 20 19:11 event4
crw-rw-rw-   1 root input 13, 69 Dec 20 19:11 event5
crw-rw-rw-+  1 root input 13, 70 Dec 20 19:11 event6
crw-rw-rw-   1 root input 13, 71 Dec 20 19:11 event7
crw-rw-rw-   1 root input 13, 72 Dec 20 19:11 event8
crw-rw-rw-+  1 root input 13,  0 Dec 20 19:11 js0
crw-rw----   1 root input 13, 63 Dec 20 19:11 mice
crw-rw-rw-   1 root input 13, 32 Dec 20 19:11 mouse0
crw-rw----   1 root input 13, 33 Dec 20 19:11 mouse1
singularity098@Linux-Arcade:~$ 
singularity098@Linux-Arcade:~$ groups
singularity098 adm cdrom sudo dip plugdev input lpadmin sambashare

[singularity098]

Oh! I noticed that while my arcade trackball was still not working in udev, the Logitech wireless touchpad/keyboard that I had was actually working now.

So I changed the player 1 mouse index from "0" to "2" and now my trackball is actually working in-game! And the original root issue which caused me to create this feature request is no longer occurring when I'm using the udev driver! This is great.... this was basically the final problem that I had to iron out with my arcade. (and same for my friend's arcade... we built 2, he did woodworking and I did hardware/software)

Thanks so much for your help and troubleshooting assistance.

[singularity098]

I guess that I should just close the issue then.... closing