Mouse cursor problems when starting the core without any game

[i30817]

Description

The mouse cursor appears to be boxed in to a rectangle that is not actually the whole extent of the screen in fullscreen. You can sort of force the cursor to move down if you move it fast. This problem is old, and occurred in the older core too.

Eventually, with some messing around with the cursor, moving fast up and down etc, the 'window' the mouse thinks it is restricted to grows and the problem doesn't happen again.

Expected behavior

Accurate mouse clamping i guess.

Actual behavior

It is very frustating

Steps to reproduce the bug

1. here, i just start the core without any game. It's the right core, i built this version

Version/Commit

[You can find this information under Information->Core Information / System Information]

• ScummVM core: v2.6.1.3-19-gcf2264b
• RetroArch: 66507d86a7

Environment information

• Device:
• OS: linux ubuntu 22.04.1 LTS, wayland gnome

[spleen1981]

Can you check with upstream_master branch if the issue is still there?

[i30817]

Is there a way to build a single engine? Otherwise it takes several hours to compile just to test the main GUI.

[i30817]

Also, that branch isn't compiling.

Compiling libretro-os.cpp...
/home/i3/Documents/Projects/new-scummv-core/src/libretro-os.cpp: In member function ‘int OSystem_RETRO::TestGame(const char*, bool)’:
/home/i3/Documents/Projects/new-scummv-core/src/libretro-os.cpp:1269:54: error: no matching function for call to ‘Common::ConfigManager::loadDefaultConfigFile(const value_type*)’
 1269 |                         ConfMan.loadDefaultConfigFile(getDefaultConfigFileName().c_str());
In file included from /home/i3/Documents/Projects/new-scummv-core/src/libretro-os.cpp:35:
/home/i3/Documents/Projects/new-scummv-core/scummvm/common/config-manager.h:128:34: note: candidate: ‘void Common::ConfigManager::loadDefaultConfigFile()’
  128 |         void                     loadDefaultConfigFile(); /*!< Load the default configuration file. */
      |                                  ^~~~~~~~~~~~~~~~~~~~~
/home/i3/Documents/Projects/new-scummv-core/scummvm/common/config-manager.h:128:34: note:   candidate expects 0 arguments, 1 provided
/home/i3/Documents/Projects/new-scummv-core/src/libretro-os.cpp: In function ‘OSystem* retroBuildOS(bool)’:
/home/i3/Documents/Projects/new-scummv-core/src/libretro-os.cpp:1305:50: error: invalid new-expression of abstract class type ‘OSystem_RETRO’
 1305 |         return new OSystem_RETRO(aEnableSpeedHack);
      |                                                  ^
/home/i3/Documents/Projects/new-scummv-core/src/libretro-os.cpp:322:7: note:   because the following virtual functions are pure within ‘OSystem_RETRO’:
  322 | class OSystem_RETRO : public EventsBaseBackend, public PaletteManager {
      |       ^~~~~~~~~~~~~
In file included from /home/i3/Documents/Projects/new-scummv-core/scummvm/common/mutex.h:26,
                 from /home/i3/Documents/Projects/new-scummv-core/scummvm/audio/mixer_intern.h:26,
                 from /home/i3/Documents/Projects/new-scummv-core/src/libretro-os.cpp:32:
/home/i3/Documents/Projects/new-scummv-core/scummvm/common/system.h:1221:22: note:     ‘virtual void OSystem::showOverlay()’
 1221 |         virtual void showOverlay() = 0;
      |                      ^~~~~~~~~~~
make: *** [Makefile:604: /home/i3/Documents/Projects/new-scummv-core/src/libretro-os.o] Error 1
i3@sleipnir:~/Documents/Projects/new-scummv-core$ 

[spleen1981]

Also, that branch isn't compiling.

Is it compiling properly, you just need to make sure scummvm submodule is referring to the correct commit when you switch branch.
Anyway you can download your artifact from here for the said branch/platform.

[i30817]

Right. I downloaded the right artifact¹, and besides the scummvm gui skin being reverted to the default, which i expected because it's a different version that i didn't build the scummvm-data, it still presents the problem.

It's a strange thing. I'm not even sure it isn't retroarch itself that it's the problem. Oh well, it takes care of itself like i mentioned.

It can happen in any axis. You just move along a direction and 'suddenly' the cursor doesn't move anymore and you're sliding perpendicularly. Then you move up and down or left to righ a little and the area grows, grows until you reach the actual screen limits.

Good job fixing the myst III problem, but i tried it now and funny enough the problem also happens there. It appears that the 'rectangle' also has such problems in a rotoscape game which is a bit concerning... because in a rotoscape game you're supposed to be able to turn 360º or even more as many times as you want...

¹ this link: https://git.libretro.com/libretro/scummvm/-/jobs/3143291/artifacts/download?file_type=archive for upstream-master, ie, the first line in the linux 64 artifact.

[i30817]

I tried with a mouse i dug up just now, instead of a touchpad and it didn't make a difference, so at least it's not one of the many linux 'quirks' with touchpad drivers that bit me in the ass with retroach before (trying to use with my old portable touchpad in KMS with scummvm was a recipe for frustration because the right mouse click didn't work and the touchpad was turned into a absolute coordinate device).

[spleen1981]

Do you have the same issue using retropad and/or keyboard directional arrows for cursor movement?
Does this happen also on direct game load?
I'm not able to reproduce this on windows or on linux with direct framebuffer, maybe it is specific to wayland.
How is this "sub rectangle" compared to the screen? Maybe a video of the issue could help.
I assume stand alone ScummVM is working properly...

[i30817]

Retropad... is strange. The problem exists, just seems not apparent in the menu, maybe because some sampling artifact from the keyboard (i use the keyboard as retropad since i don't have a controller).

However, in myst III, which is supposed to be 360º rotoscape, shows itself quickly again.

A video can be provided, but github only allows ten mb videos so i have to downsample it. I used the ffmpeg -i input -vf scale=iw/2:-1 output mantra.

out.webm

Anyway, in the video you can see me using the mouse after loading the core and the first unnatural horizontal line is the effect. It stops there after that when i jiggle the mouse. Then i load a save from myst 3 beginning i had and i start using the 'retropad'. Then before the end i try using the mouse, to not much help (sometimes messing around a lot helps move that 'window' a bit).

This isn't in the video, but loading from the playlist doesn't affect this, but it made me notice (from bypassing the scummvm menu load screen, and thus entering the game menu) that the game menu is like the scummvm GUI where the retropad appears to behave 'better'. I suspect this is a illusion from whatever heuristic that is trying to approximate 'the screen' because as seen in the video, retropad fails in game in a game where the 'screen' is arbitary (rotoscoped).

It may be indeed a wayland limitation/bug. I won't speculate what's the aim of it and why it affects retroarch but not scummvm.

Standalone scummvm doesn't have any of these problems, you can rotate the view back to the wife and baby and she starts her dialog.

[i30817]

Interestingly, scummvm in software graphical mode shows a bug that retroarch doesn't (retroarch, i'm assuming, is always in software mode).

The screen gets cut off in the right side. I guess it could be a older bug since my build of scummvm is a few months old.

edit: in myst 3 that is.

[i30817]

Might this not be a core bug, but a bug in retroarch mouse itself when resolutions change?

[i30817]

Eh... i just tried to see if changing from 'fake (windowed) fullscreen' to 'actual fullscreen' did anything and it didn't help, although i'm not sure it would in wayland, which i kind of remember (several years ago) didn't actually have exclusive fullscreen.

The fact that another bug reported opened with the same bug but for windows indicates it's not a exclusive problem to wayland anyway.

Then i tried to change the input driver from 'sdl' to 'udev' and found the amusing 'touchpad treated as absolute input instead of relative input' problem is BACK, and this time even outside KMS. So that driver doesn't work.

(if you don't know how this manifests, touching a touchpad with a finger will 'jump' the cursor whenever the touchpad thinks it projects on the screen, dragging will move normally, but it's still unplayable.

The linuxraw and x drivers have the same problems, even if i find it suspicious that the x driver even works on wayland. I think i built retroarch with xwayland support, i'll go disable that and try again.

[i30817]

No, that didn't help. Tried the sdl and raw input drivers.

I did notice that the wayland menu goes a bit... zoomed in for the resolution in my desktop, even with the fake fullscreen. A bug in the wayland version of the graphics driver i suppose (happens in both gl and waylad. SDL fallbacks to rgui instead of ozone).

[spleen1981]

Can you test if e7fe82c4886ea4e7a964f9148cb7d76b90fe1edc fixes the RetroPad issue?

[i30817]

It works better bit it's still a bit random. The first time i could move to the right (more) and left (less), but not all the way (the woman and the baby didn't show) while using the mouse, but the second time i could turn all the way (while using the keyboard/retropad).

Strangely it seems this didn't help for the mouse but did for the retropad. This is apparent in the main menu of myst 3 where moving around the mouse often shows the effect but the retropad can continue from where the mouse left off.

The same happens in game.

I suppose this doesn't help the 'root cause' of whatever is causing this for the mouse and helps with the pad. Only on this core i suppose, from where the fix is applied; since dosbox still has the problem.

[i30817]

But note, i only tested a dosbox game to find this problem with the mouse since the retroapad doesn't appear to work by default in dosbox-core (i suppose it's for joysticks), so i don't actually know how the retropad behaves in dosbox, just the mouse.

[spleen1981]

Just to summarize, with e7fe82c4886ea4e7a964f9148cb7d76b90fe1edc on your platform - considering the ScummVM GUI only - cursor movement with keyboard directional keys/RetroPad D-pad works good, movement with RetroPad left analog axis is untested and RetroMouse movement issue remained unchanged (same as video above), right?

[spleen1981]

I've added a test_mouse_res branch with mouse vars log (at INFO level).
You may try to move the curson within the rectangle limits to see what's captured actually.

[i30817]

Sure. Here are two captures, first one where in-game in myst 3 i first look 'up' then sideways, and another where i look to the sides first.

capture.txt
capture2.txt

[i30817]

The scummvm GUI is actually behaving now (both mouse and retropad/with a keyboard) (but there are still problems on other cores with mouse support like dosbox).

Back to this core, the test above is scummvm in-game for myst 3, where you're supposed to be able to rotate the mouse east-to-west or west-to-east as many times as you want. It's a bit larger and more 'free' now, but by no means 'a complete turn', much less multiple ones.

Retropad achieves that now.

edit: spoke too soon about 'mouse behaving in the GUI'. It's rarer, but it still can happen. This usually happens in the first few movements of the GUI only if it's going to, which makes me think it's thinking that the 'center' is where the mouse starts or something.

Retropad, still no problems. In fact, using the keyboard/retropad resets the mouse movement too.

[spleen1981]

but there are still problems on other cores with mouse support like dosbox

That's a separate (and probably unrelated) issue to be opened there I guess.

but by no means 'a complete turn', much less multiple ones.

If you mean you need to move the mouse multiple times to accomplish a 360° turn, that's the intended behaviour with RetroMouse, same as standalone ScummVM (and I guess original game). You can increase the mouse speed setting to turn more with a single mouse movement.
With RetroPad it will keep on turning while the D-Pad key is pressed, but that's a different kind of input.

it still can happen. This usually happens in the first few movements of the GUI only if it's going to, which makes me think it's thinking that the 'center' is where the mouse starts or something.

Cursor is initialised at x=0, y=0, you should always see it at top left corner at ScummVM GUI startup.
It would be useful to have a log for this case (which I understand is still cursor blocked in a rectangle smaller than screen), including this "reset" using RetroPad.

[i30817]

I do notice that the mouse starts in the top-left in the initial GUI.

If you mean you need to move the mouse multiple times to accomplish a 360° turn, that's the intended behaviour with RetroMouse, same as standalone ScummVM (and I guess original game). You can increase the mouse speed setting to turn more with a single mouse movement.

No. What i mean with that is that although the range is wider, it still doesn't allow a complete turn horizontally - the same game in upstream scummvm allows how many turns you want with a mouse (or my touchpad). Of course i'm pausing in between - i'm using a touchpad, but even if i was using a 'real' mouse i'd need to pause to move the mouse back once in a while in real life. There still exists a hard limit ingame of how much the cursor will allow a move (retropad works now though).

If you want a log of a example in the normal GUI 'failing' here i managed to capture one where it slides along a imaginary vertical line when i move the mouse diagonally until it hit that 'line'. I should have exited there after doing that but i ended doing a 'try to move left horizontal line when i though it had found a horizontal line too, but it wasn't there.
capture.txt

As for a example of the touchpad resetting - i just noticed that only works in the myst 3 game for some reason. Here it in the core main GUI just moves the line. I lucked out and this time it was a horizontal line. If you see it moving horizontally, i'm using the mouse, if you see that horizontal line moving the y coordinate, it's after using the retropad to move then using the mouse again:

capture2.txt

[i30817]

I find it strange that the first values captured in the log are numbers like

[SCUMMVM TEST] y: -192	_mouseY: 0	_mouseYAcc: 0.00	mouse_speed: 1.00	_screen.h: 480	_overlay.h: 480	_gameScreen.h: 200
[libretro INFO] 
[SCUMMVM TEST] x: -699	_mouseX: 0	_mouseXAcc: 0.00	mouse_speed: 1.00	_screen.w: 640	_overlay.w: 640	_gameScreen.w: 320

even in the core GUI. I'd expect it to be x=0 and y=0 if the coordinate system sets the upper left as 0,0 and the cursor starts there?

Why the negative numbers, are they unintialized and some other piece of code is using random memory to calculate a limit to the mouse?

In fact, aren't negative coordinate numbers a sign that there is something wrong?

[spleen1981]

The x and y are the relative mouse movement (and can be positive or negative) directly retrieved from the libretro API, so there isn't much we can do within the core but using them.
Those initial values are strange indeed, but _mouseX and _mouseY (which are the absolute coordinates calculated within the core) are filtered to be within 0 and max screen width/height, so no issue if problem in the API is just for the initial value.

It is not easy to read the logs without seeing what's happening on the screen at the same time: you should check what happens in the log when you try to pass over the virtual vertical or horizontal block line in the GUI.

e.g: If you have a vertical block line, when you try to move over that line what's the reading of x and _mouseX? If I've understood correctly, that was one of your tests above, and log shows a sequence of x: 0 _mouseX: 392 _screen.w: 640
If you were moving the cursor horizontally at the vertical block line and reading of x from the API was 0, the cursor was not moving because it was not receiving any input on that axis. In this case that completely depends on libretro API for your specific configuration, and there is nothing that can be done core side. The possible 'reset' using retropad occurs on that side also, if any. As x / y are directly used to rotate view in Myst 3, that would explain your issue there as well.
Can you confirm the test above (if you have horizontal block line you should look to y and _mouseY instead)?

[i30817]

Here us a sequence where i iterated over a vertical line a few times at the end of the file, these should be the same line, nothing much to say except it shows the behavior you theorize and that y sometimes goes negative which i didn't think was possible from what you said about it resetting after the start.

The problem being from the libretro api would explain that it also happens on other cores.

capture.txt

[i30817]

I'm just perplexed how this can remain on multiple cores for what's probably years without anyone noticing or caring.

[i30817]

If you use a text editor, and 'find' the X repeating line at the end you can easily find the exact line i started being stuck.

Is it normal the mouseX/YAcc values always being zero when sampled?

[spleen1981]

Ok, so in that case you had a vertical block line at ab 76% of the screen and at that point you are not receiving anymore x inputs from the api (you just get 0 if you try to move to the right).
Negative y mean you were going upwards, positive downwards.
I think the fact that you found this happening in the GUI was incidental, because most of the games runs at 320x200 while the GUI is 640x480, and the vertical block line in the example above was always > 320 (though apparently random).
Myst3 is one of those "highres" games running at 640x480.

Is it normal the mouseX/YAcc values always being zero when sampled?

Yes, actually that log is useless, as at that point those variables are always 0 (anyway they've nothing to do with this issue).

[spleen1981]

I'm just perplexed how this can remain on multiple cores for what's probably years without anyone noticing or caring.

I think that is because this issue seems to be specific to your configuration (drivers? hardware?) plus it's specific to RetroMouse, which isn't the most common device used with RetroArch.
What is the input driver you used in RetroArch for the test above?

[i30817]

SDL2, but it can happens in any driver that works. Udev, linuxraw too. X driver too (i didn't expect it work with x support disabled, since the x video driver doesn't...)

I feel like this is not because of driver code, or if it is, it's on some common code to all.

I will also say i don't think it's my environment - i've seen this on two different computers with different versions of ubuntu, and honestly, i still think the bug you previously closed is the same thing and the user that filed it just thinks it's completely fixed (it sometimes doesn't show with the mouse/touchpad in the scummvm GUI menu every time, although when entering myst3 it always can't make a full turn here). If true, it would also happen in windows!

[i30817]

If you find a better way to track it down, i have some technical knowledge. I can use a command line, and i'm willing to spend time capturing whatever logs and applying patches to retroarch itself, since i already build it regularly.

[i30817]

This seems to be worked on right now on libretro/RetroArch#15057 if you want to monitor it to see if it solves the issue.

The idea appears sound of the reason why it happens in multiple cores (retroarch not playing well with the wayland compositor mouse grab). I'm not too sure why it would also fail with xwayland version of retroarch, but it's not to much of stretch to think that xwayland running on wayland would still have the same problem...

[i30817]

This was fixed in the last version of the PR at libretro/RetroArch#15103

So it's finally fixed. I tested on both x11 and wayland this time (although i didn't bother recompiling from the wayland driver to test x11 - retroarch started and reported the x11 graphics driver, so i thought it was enough).

When it's merged i think this can be closed, finally.