ValveSoftware
Starcitizen mouse issues like wild mouse movement and unable to interact normally. somewhat related to last mouse lock issue
Kernel: 6.8.7 with patches from CachyOS, TKG, Gentoo and RT
Distro: Artix
PKGBUILD: https://github.com/Frogging-Family/gamescope-git
Commands:
gamescope -r 168 -w 2064 -h 864 --F fsr --fsr-sharpness 0 --reshade-effect LUT.fx (EMBEDDED)
gamescope -r 168 --reshade-effect LUT.fx (EMBEDDED)
gamescope -r 168 -w 3440 -h 1440 --reshade-effect LUT.fx (X11 NESTED)
gamescope -r 168 -w 3440 -h 1440 --reshade-effect LUT.fx --force-grab-cursor (X11 NESTED)
Tested entirely in Wine's Virtual Desktop.
Both:
-
Interaction mode rotates 90-180 and usually looks to the floor Bad commit: fb5e86b7c5f2e3dfb998eb1d93a759bd9e43319b
-
Need rapid mouse movement events(like 10-100ms per second) to click interactables to use Bad commits: dc911c1c488ea398b105428a4a75b97d8eeadec7...793dde773b8a8cbd82767a9d4a5f2a64dc9121df
Nested X11:
- Interaction mode rotates wildly on mouse update looking to the ground then going up 45-60 degees
Last good commit: unknown, tested 20 pages of commits until eff0ac001e963e399ec6e4efd4ce955b0b351ea3
- Relative Mouse mode fixes this
Notes:
- Mouse never centers in interaction mod in both Embedded or Nested, usually resets to the center of the top left, unknown intended behavior, also happens in normal X11.
@MCPO-Spartan-117 Out of curiousity, are any of these issues also present at commit point: 14a1db3 For reference commit 14a1db3 is just slightly ahead of version 3.14.12
@sharkautarch
That commit will avoid all but one issue from #1191 which is Prevents display refresh, if you only use Nested you can ignore it, i think you can also go up to febcf34de9993151261047007867bd385de28e57 which will include Display corruption from the same issue as well which i think is Embedded only but i don't remember.
If you want to avoid all the issues that i have reported in this issue and in the past like #1191 and #1265, commit 9e46c89ffc56c0bc6359ef4269274804f0c9d382 should be free of all of them.
Any updates on this one? Issue is still present in 3.14.22 and after updating to Plasma 6.1. Quite anoying as it's making Star Citizen uplayable in Wayland and with HDR. For me the camera jumps down to the right as soon as you enter Interafive mode (Hold F). Tried with and without relative mouse mode and same issue.
@Faceless3882 I'm also having this issue - does HDR make any difference to you? As far as I remember it had no difference... also running 6.1
Do other games have this problem? I don't see why Star Citizen would be special.
Do other games have this problem? I don't see why Star Citizen would be special.
None others that found. It's something to do with interactive mode though. A sub cursor kinda thing?
Do other games have this problem? I don't see why Star Citizen would be special.
If i noticed any other games i'd have reported them in this or the other issue. It's possible a game like Gary's Mod could have this issue as it does have a similar 'interaction mode' but i haven't tried.
Any updates on this one? Issue is still present in 3.14.22 and after updating to Plasma 6.1. Quite anoying as it's making Star Citizen uplayable in Wayland and with HDR. For me the camera jumps down to the right as soon as you enter Interafive mode (Hold F). Tried with and without relative mouse mode and same issue.
What does HDR have to do with this? As a side note HDR was broken on this game in embedded last time i tried which was probably 2-3 months ago.
I have noticed people saying relative mode doesn't fix the issue, every commit i've tried has fixed it for me, so unless this is a nested (x)wayland specific bug i have no idea how to replicate it.
No sorry, HDR doesnt affect whether the issue happens or not, but its the reason I want to run Star Citizen in gamescope. I think you may be right in it being an xwayland bug though
@MCPO-Spartan-117 So just to verify: is the only problem persisting in 3.14.22 the Nested X11-specific problem? Excluding problems that weren’t reported in this issue, that is
@sharkautarch Unfortunately ever since commit 93a90d19a19ea414a165e2f3297c76d9dc9dc062 i've been unable to build upstream wlroots with the drm backend with this error.
User defined options
buildtype : release
force_fallback_for: wlroots,libliftoff,vkroots
prefix : /usr
pipewire : enabled
libliftoff:werror : false
wlroots:werror : false
wlroots:backends : drm,libinput
wlroots:renderers : gles2,vulkan
Found ninja-1.12.1 at /usr/bin/ninja
ninja: Entering directory `_build'
[308/502] Compiling C object subprojects/wlroots/libwlroots.a.p/backend_drm_libliftoff.c.o
FAILED: subprojects/wlroots/libwlroots.a.p/backend_drm_libliftoff.c.o
ccache cc -Isubprojects/wlroots/libwlroots.a.p -Isubprojects/wlroots -I../gamescope/subprojects/wlroots -Isubprojects/wlroots/include -I../gamescope/subprojects/wlroots/include -I../gamescope/subprojects/libliftoff/include -Isubprojects/wlroots/protocol -Isubprojects/wlroots/render/gles2/shaders -Isubprojects/wlroots/render/vulkan/shaders -Isubprojects/wlroots/backend/drm -I/usr/include/libdrm -I/usr/include/pixman-1 -I/usr/include/elogind -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=c11 -O3 -D_POSIX_C_SOURCE=200809L -DWLR_USE_UNSTABLE -DWLR_LITTLE_ENDIAN=1 -DWLR_BIG_ENDIAN=0 -Wundef -Wlogical-op -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self -Wstrict-prototypes -Wimplicit-fallthrough=2 -Wendif-labels -Wstrict-aliasing=2 -Woverflow -Wmissing-prototypes -Walloca -Wno-missing-braces -Wno-missing-field-initializers -Wno-unused-parameter -fmacro-prefix-map=../gamescope/subprojects/wlroots/= -march=native -O2 -ftree-vectorize -pipe -fno-plt -D_FORTIFY_SOURCE=2 -fPIC -isystem/usr/include/libdrm -MD -MQ subprojects/wlroots/libwlroots.a.p/backend_drm_libliftoff.c.o -MF subprojects/wlroots/libwlroots.a.p/backend_drm_libliftoff.c.o.d -o subprojects/wlroots/libwlroots.a.p/backend_drm_libliftoff.c.o -c ../gamescope/subprojects/wlroots/backend/drm/libliftoff.c
../gamescope/subprojects/wlroots/backend/drm/libliftoff.c: In function ‘commit’:
../gamescope/subprojects/wlroots/backend/drm/libliftoff.c:410:27: error: too few arguments to function ‘liftoff_output_apply’
410 | int ret = liftoff_output_apply(crtc->liftoff, req, flags);
| ^~~~~~~~~~~~~~~~~~~~
In file included from ../gamescope/subprojects/wlroots/backend/drm/libliftoff.c:2:
../gamescope/subprojects/libliftoff/include/libliftoff.h:85:1: note: declared here
85 | liftoff_output_apply(struct liftoff_output *output, drmModeAtomicReq *req,
| ^~~~~~~~~~~~~~~~~~~~
[317/502] Compiling C object subprojects/wlroots/libwlroots.a.p/types_wlr_linux_dmabuf_v1.c.o
ninja: build stopped: subcommand failed.
So i'm unable to test upstream properly till i figure out what the issue is if it isn't just upstream issues.
That explains the error then, guess it's time to make another issue on the PKG i use.
@sharkautarch
Every bug reported still persists.
@Faceless3882
X11 without relative mode the camera wobbles up and down now. With relative it behaves like expected.
Xwayland under Wayfire without relative mode was worse than in normal X11 forcing the camera to the ground and to the right as long as interaction was held down. With relative mode it behaved like X11.
SDL wayland on Wayfire without relative mode behaved like X11.
With relative mode it mostly behaved like X11 but the cursor was hitting the border of the screen.
Couldn't get the wayland backend working on Wayfire
@MCPO-Spartan-117 Hmmm try building gamescope with address sanitizer to see if finds anything going wrong
add these meson flags to your PKGBUILD:
-Db_sanitize=address,undefined -Dc_args="-g1 -Wno-error=stringop-overflow -Wno-error=unused-but-set-variable -Wno-error=unused-variable -fno-omit-frame-pointer -U_FORTIFY_SOURCE -fsanitize-recover" -Dc_link_args="-g1 -Wno-error=stringop-overflow -Wno-error=unused-but-set-variable -Wno-error=unused-variable -fno-omit-frame-pointer -U_FORTIFY_SOURCE -fsanitize-recover" -Dcpp_args="-g1 -Wno-error=stringop-overflow -Wno-error=unused-but-set-variable -Wno-error=unused-variable -U_FORTIFY_SOURCE -fno-omit-frame-pointer -fsanitize-recover=all" -Dcpp_link_args="-g1 -Wno-error=stringop-overflow -Wno-error=unused-but-set-variable -Wno-error=unused-variable -U_FORTIFY_SOURCE -fno-omit-frame-pointer -fsanitize-recover=all"
And also add this line to your PKGBUILD:
options=(!strip)
Then after you’ve rebuilt and reinstalled gamescope
if you launch the game from steam, open up steam from the command line so that you can view gamescope’s stdout:
steam &| tee gamescope_steam.log
And before launching Starcitizen, edit the launcher options like so:
ASAN_OPTIONS=detect_stack_use_after_return=true:strict_string_checks=true:detect_invalid_pointer_pairs=2:dump_instruction_bytes=true:halt_on_error=false:detect_leaks=false:leak_check_at_exit=false:intercept_tls_get_addr=true gamescope <insert gamescope args here> -- env LD_PRELOAD=/usr/lib/libasan.so %command%
if launching outside of steam:
ASAN_OPTIONS=detect_stack_use_after_return=true:strict_string_checks=true:detect_invalid_pointer_pairs=2:dump_instruction_bytes=true:halt_on_error=false:detect_leaks=false:leak_check_at_exit=false:intercept_tls_get_addr=true gamescope <insert gamescope args here> -- env LD_PRELOAD=/usr/lib/libasan.so <insert binary/executable/game here> |& tee gamescope_starcitizen.log
Then you can paste the log on gist.github.com and post a link to it here
How is loading the library inside gamescope going to help? wouldn't this be debugging wine or urxvt?
How is loading the library inside gamescope going to help? wouldn't this be debugging
wineorurxvt?
It’s possible that there’s some edgecase bug that’s only triggered when running something like Starcitizen under gamescope…
And I would assume that you don’t experience this issues when running Starcitizen outside of gamescope
Btw, the LD_PRELOAD=/usr/lib/libasan.so is needed because gamescope has a vulkan WSI layer that gets loaded into vulkan/dxvk games that run under it. Without the LD_PRELOAD thing, address sanitizer will complain that the address sanitizer shared library was not loaded early enough. It’s some weird funky stuff with how vulkan layers work w/ the vulkan loader…
If you’re wondering why an address sanitizer shared library has to be loaded into all the gamescope stuff: the gist is that in order for asan to catch stuff like memory errors, it has to deal with stuff like malloc() & whatnot that are sourced from your system’s shared libraries like libgcc_s.so et al.
Also the asan shared library can sometimes catch some memory errors from binaries that weren’t even compiled w/ address sanitizer
Both my custom and distro Wine fails to start for different reasons both inside and outside of my bubblewrap and gamescope with that library.
A test with winecfg outside of my bubblewrap and gamescope.
https://gist.github.com/MCPO-Spartan-117/01f25b6ed9314ca135524405405cf028#file-custom-wine-log
https://gist.github.com/MCPO-Spartan-117/01f25b6ed9314ca135524405405cf028#file-distro-wine-log
My custom wine is definitely striped so that is probably why it's only 600 lines vs 10000 lines.
Not sure how far i'll go with this, i don't even like this game lol.
@MCPO-Spartan-117 Ohhh I think I know why asan isn’t working: Wine has a memory range that overlaps a memory range that asan uses https://github.com/llvm/llvm-project/issues/25840
removing the LD_PRELOAD might allow you to run gamescope w/ wine again
Asan might complain about initialization order, but I don’t think it’ll exit due to that, and the initialization order thingy should only affect asan’s analysis of gamescope’s vulkan WSI layer, which is separate from gamescope itself
ASAN_OPTIONS=detect_stack_use_after_return=true:strict_string_checks=true:detect_invalid_pointer_pairs=2:dump_instruction_bytes=true:halt_on_error=false:detect_leaks=false:leak_check_at_exit=false:intercept_tls_get_addr=true gamescope -r 168 -w 2064 -h 864 -F fsr --fsr-sharpness 0 --reshade-effect LUT.fx -- bwrap-DXVK.sh --embd --lug |& tee /tmp/...
bwrap-DXVK.sh --embd --lug starts a urxvt terminal in a bubblewrap i use to start wine.
https://gist.github.com/MCPO-Spartan-117/e5b5bf46dbd38f52727a0fad533fd3e4#file-embedded-gamescope-log https://gist.github.com/MCPO-Spartan-117/e5b5bf46dbd38f52727a0fad533fd3e4#file-x11-gamescope-log
Nested X11 didn't give any asan output, so i don't know how useful embedded will be.
With embedded i opened a door, called a elevator and went to the roof on Orison. X11 i pretty much just periodically held interaction down and moved the mouse around.
I also have this issue with star citizen. It happens whether I launch gamescope nested in X11 or in wayland. I would just download an old version of gamescope, but the dependencies have been updated since then and it won't compile, and I don't have the technical know how to fix them.
EDIT
If you want to avoid all the issues that i have reported in this issue and in the past like https://github.com/ValveSoftware/gamescope/issues/1191 and https://github.com/ValveSoftware/gamescope/issues/1265, commit https://github.com/ValveSoftware/gamescope/commit/9e46c89ffc56c0bc6359ef4269274804f0c9d382 should be free of all of them.
The commit listed here did not fix the issue for me either. :(
I also had to modify some of the files in this commit. anywhere that had calloc(sizeof( *something* ), *something*) I had to put the sizeof function in the second half of the calloc function
I believe the underlying bug is this one: https://bugs.kde.org/show_bug.cgi?id=484797 however older versions of gamescope would be able to get around the issue by using --force-grab-cursor. Newer versions don't.
The game has issues in embedded Gamescope with the drm backend as well. I suspect the game itself does something cursed with the cursor code in their "interaction layer" for in-game menus and prompts.
I also have this issue with star citizen. It happens whether I launch gamescope nested in X11 or in wayland. I would just download an old version of gamescope, but the dependencies have been updated since then and it won't compile, and I don't have the technical know how to fix them.
EDIT
If you want to avoid all the issues that i have reported in this issue and in the past like #1191 and #1265, commit 9e46c89 should be free of all of them.
The commit listed here did not fix the issue for me either. :( I also had to modify some of the files in this commit. anywhere that had
calloc(sizeof( *something* ), *something*)I had to put the sizeof function in the second half of the calloc function
Specify which problems you are still having, there are 3 reported in this issue.
The game has issues in embedded Gamescope with the drm backend as well. I suspect the game itself does something cursed with the cursor code in their "interaction layer" for in-game menus and prompts.
This isn't the only thing wrong with this game :), wouldn't be surprised if it's some scuffed React code mixed with some memory management related issues.
Specify which problems you are still having, there are 3 reported in this issue.
Apologies, issue is the first one. (technically also have the second one, but that's only without gamescope but in wayland)
I will say that Joshua Ashton did push out some recent cursor/mouse related tweaks/fixes to master in the past day or two, btw no clue if it actually fixes any of these issues tho
I will say that Joshua Ashton did push out some recent cursor/mouse related tweaks/fixes to master in the past day or two, btw no clue if it actually fixes any of these issues tho
I just installed it and tried it, and it did not fix the issue.
Ok, so after a boat load of testing, my findings in regards to bug 1 and 2 from the original post are as follows (note, all testing done with the --force-grab-cursor flag):
Bug 1 seems to be caused by something in one of these functions which were all added in commit https://github.com/ValveSoftware/gamescope/commit/fb5e86b7c5f2e3dfb998eb1d93a759bd9e43319b. These functions have remained unchanged since, but I have not had the time to go through them and see what the issue might be (it also doesn't help that I have no experience with C++, wlroots, or the source code of gamescope in general):
GamescopePointerConstraint
wlserver_warp_to_constraint_hint
wlserver_update_cursor_constraint
wlserver_constrain_cursor
handle_pointer_constraint_set_region
handle_constraint_destroy
handle_pointer_constraint
Bug 2 I have had more time to look at, and it seems to be caused by the line wlr_seat_pointer_notify_motion( wlserver.wlr.seat, time, wlserver.mouse_surface_cursorx, wlserver.mouse_surface_cursory ); in the function wlserver_mousemotion
Basically what I noticed is that when that line is commented out, the cursor position, and the visible cursor position do not match. (for example, the cursor could be in the middle of the screen, but the visible cursor could be at the bottom left).
This was the case in menus, as well as in the interaction menu. However, with the line uncommented, the cursor worked as expected in menus, but incorrectly in star citizen's interaction menu.
What I think is going on is, this function is trying to pull the cursor position to the visible cursor, but star citizen has some kind of built in cursor that works independently of the wlroots cursor. What is essentially happening is, when you move the cursor in game, the star citizen cursor gets snapped to the visible cursor, but once you stop moving the cursor, it snaps back to its old position, relative to your mouse movement. This causes the flickering effect and is why you need rapid mouse movements to click things.
I have no idea how to fix this, and, tbh, it seems to be a wlroots issue, not a gamescope issue, since I'm pretty sure the wlr_seat_pointer_notify_motion function is an wlroots function. I guess a temporary fix would be to force the visible cursor to move to the cursor position rather than having the position move to the visible, but I don't know how to make that change.
@Joshua-Ashton Previously, when gamescope used to use x11-based cursor barriers instead of the wayland-based cursor barriers used now: Were the barriers being placed on gamescope’s surface, or on the game’s surface? Because I would imagine that the wayland-based barriers are just placed on gamescope’s surface…
Ok, I have figured out exactly what is going on that causes bug 2, and possibly the other bugs as well. Please direct your attention to the following code in wlserver.cpp:
void wlserver_mousemotion( double dx, double dy, uint32_t time )
{
assert( wlserver_is_lock_held() );
wlserver_perform_rel_pointer_motion( dx, dy );
if ( !wlserver_apply_constraint( &dx, &dy ) )
{
wlr_seat_pointer_notify_frame( wlserver.wlr.seat );
return;
}
wlserver.ulLastMovedCursorTime = get_time_in_nanos();
wlserver.bCursorHidden = false;
wlserver.mouse_surface_cursorx += dx;
wlserver.mouse_surface_cursory += dy;
wlserver_clampcursor();
wlserver_oncursorevent();
wlr_seat_pointer_notify_motion( wlserver.wlr.seat, time, wlserver.mouse_surface_cursorx, wlserver.mouse_surface_cursory );
wlr_seat_pointer_notify_frame( wlserver.wlr.seat );
}
So, in this code there are 2 lines that are important:
wlserver_perform_rel_pointer_motion( dx, dy );wlr_seat_pointer_notify_motion( wlserver.wlr.seat, time, wlserver.mouse_surface_cursorx, wlserver.mouse_surface_cursory );
To my understanding, these lines do the following.
Line 1: Sets the relative pointer position, which seems to control things like the camera. Line 2: I think this syncs the visible cursor and the surface pointer together, this mostly allows for interacting with menus and window elements. But to be honest, I'm not entirely sure what this controls, all I know is that without it, the visible cursor, and the spot that interacts with stuff don't match.
In most games this will work without issue, as games will usually stick to using one pointer or the other at a time, or at the very least, the two are properly synced and thus move together. But not star citizen.
In star citizen, the player camera is controlled by the relative pointer, menus are controlled by the surface pointer, and the interact menu is controlled by BOTH. Essentially what is happening, is that when the cursor is moving, the point of interaction is synced to the surface pointer, and when the cursor is stationary, it is synced to the relative pointer. I can confirm this behavior by commenting out line 2, and the interaction point will ONLY be synced to the relative pointer. And if I comment out line 1, the interaction point will be synced to the bottom right of the screen when the cursor isn't moving.
So in order to fix bug 2, (and possibly the others as well) the surface pointer needs to be synced up to the location of the relative pointer, or vice versa.
It's also possible that the relative pointer is being synced up to the surface pointer, but star citizen is hijacking the relative pointer when in the interact menu. Though, I'm not sure this is the case due to the effect that commenting out line 1 has.
Simply put, as matte-schwartz said earlier, CURSED CURSOR CODE.