[Linux] Physical mouse and invisible walls in cannon fodder in amiga core PUAE

[ZzackKbin]

Hello
I have problem with physical mouse for linux arch. In Cannon Fodder when screen is scrolling mouse cursor stop on invisible walls when use physical mouse but when I use Sony pad DS4 everything is ok.
https://youtu.be/M_CwEI6_2iE

• in windows and the same hardware (steamdeck) no problems with physical mouse
• in linux arch desktop and only run retroarch physical mouse stop on invisble walls when screen is scrolling

I tested retroarch with lr-puae with even closed steam application.
libretro/libretro-uae#608

[sonninnos]

Same will happen with every game and every core that uses a mouse. Did you try some other input driver yet if available? And what is the RetroArch version?

[ZzackKbin]

Now I testesd settlers pc and Dosbox pure has the same problem with invisible walls for physical mouse in linux arch .
I tried change in drivers>input sdl linuxraw x and no results

[ZzackKbin]

I installed standalone dosbox and physical mouse works ok in settlers. Looks like something broken in retroarch for linux.

[i30817]

This was fixed a month ago. It was because (in wayland desktops), mouse capture wasn't implemented, so in fullscreen the cursor was 'floating' but you couldn't tell. This also happened in retroarch built for x11 running through XWayland in a wayland desktop iirc.

Maybe try a updated version of retroarch (not the cores)?

It happened in all the cores that required mouse. Ie: dosbox, scummvm, puae, etc.

This was the issue: #15057

there were some more updates to the wayland drivers after this one to fix some follow up bugs like the game focus mode crashing (mouse was already locked) etc.

[ZzackKbin]

In SteamOS (linuxarch):
https://i.imgur.com/HQ6Nhep.png
https://i.imgur.com/1kWVTXv.png

I reisntalled and no results :(
Maybe emudeck broken something.

[i30817]

write the git version and build date you have on the main menu->information window.

To be clear, this was fixed in these 3 commits in order (there are more wayland fixes but they don't interact with the mouse):

#15103 merged march 20
#15114 merged march 21
#15128 merged march 24

if the git commit you have on your version of retroarch is older than these, or it's from a fork that hasn't updated/synced to upstream recently, there is your cause. I wouldn't be too surprised if the flathub version was late.

[ZzackKbin]

sys info: https://i.imgur.com/xEpbREV.png

[i30817]

That makes it sure. That commit is from 16 march 4 days before this started being fixed.

commit 6616b80 (tag: v1.15.0)
Author: github-actions github-actions@github.com
Date: Thu Mar 16 00:13:09 2023 +0000

Fetch translations from Crowdin

Wait for a new version i guess.

[i30817]

BTW. this bug literally existed for YEARS and people complained about it regularly, so it being fixed just as you noticed is actually kind of 'lucky'. You'll just have to wait a bit.

[ZzackKbin]

Maybe Emudeck something broken.

[i30817]

No. I already told you, this is literally a bug in retroarch. You're just not using the latest code of retroarch. When that code becomes available to update, this problem will disappear. Have some patience and play some other games meanwhile, it shouldn't take more than a month, and probably a few days.

[ZzackKbin]

thx

[dyha89]

Hi
I'm still experiencing this issue having RetroArch 1.16.0.
(Also in Cannon Fodder in PUAE.)

[i30817]

This issue is for Wayland and was pretty comprehensively fixed, there is a similar issue for android caused by pretty much the same cut corner, but in other drivers.

Is your device running Linux or Android or mac\ios?

#14016 (android issue, has a pr in progress but not submitted yet)

[dyha89]

Thanks for your answer.
I'm using Manjaro Linux. I have installed retroarch using pacman package manager.
Version: retroarch 1.16.0.3-1

(Once I have turned 'physical mouse' in core options off, then back on, and restarted retroarch. After this, I have played the game like 15 minutes without issue reproduction. When I have started retroarch again next day it started to reproduce again. Maybe it's an coincidence - do not know.)

[dyha89]

cf.mp4

[dyha89]

[sonninnos]

Core version, game and the mouse core option do not matter one bit, except of course there is no mouse at all if disabled. What matters is that the emulated mouse cursor can't travel at the same speed as the OS cursor, and isn't 1:1 at the same coordinates, which will result in out of bounds situations if mouse is not grabbed to the window properly. As in the core does not get new mouse readings when the OS mouse cursor is no longer inside the window.

AFAIK that was fixed ages ago in Linux, but perhaps then not with all input drivers. With Windows it hasn't been an issue for a long time regardless if playing in a window or not, or if mouse grab is active or not. Windows apps can read relative mouse data even when OS mouse cursor is outside of the active window. Generally in fullscreen mouse grab should not even matter, but again not all input drivers behave the same.

With Amiga it is very easy to test the mouse cursor without launching any games. Just make sure you are launching Kickstart version 2 or later, and hold both mouse buttons down on startup to activate the Early Startup menu.

[dyha89]

I have noticed that 'Automatic Mouse Grab' in input options was off. I turned it on, and I had no reproduction after 15 minutes of playing.

I'll let you know again if it still works fine after some more time.

[sonninnos]

Indeed mouse grab is only enforced on fullscreen if using non-windowed fullscreen. That option is for always grabbing when window becomes active.

[i30817]

Seems like it should be forced on Fullscreen, full stop. Why isn't it?

Edit: multi monitor setups I guess...

Maybe a popup warning in certain cores in Fullscreen without that setting?

[dyha89]

Since I turned Automatic Mouse Grab on, issue doesn't reproduce.
Oh, and indeed I have got two monitors.

[sonninnos]

I guess it can be mark solved then, since grab is required by design, and it can't really be forced by default..

[i30817]

There can still be a warning. And I think it would prevent this bug being opened over and over again (not to mention help users).