Starcitizen mouse issues like wild mouse movement and unable to interact normally. somewhat related to last mouse lock issue

[MCPO-Spartan-117]

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.

[sharkautarch]

@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

[MCPO-Spartan-117]

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

[Faceless3882]

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.

[Zk2u]

@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

[Faceless3882]

Yes quite a difference with HDR on my OLED 🙂

[misyltoad]

Do other games have this problem? I don't see why Star Citizen would be special.

[Faceless3882]

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?

[MCPO-Spartan-117]

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.

[Faceless3882]

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

[sharkautarch]

@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

[MCPO-Spartan-117]

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

[misyltoad]

We do not use the wlroots drm backend

[MCPO-Spartan-117]

That explains the error then, guess it's time to make another issue on the PKG i use.

[MCPO-Spartan-117]

@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

[sharkautarch]

@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

[MCPO-Spartan-117]

How is loading the library inside gamescope going to help? wouldn't this be debugging wine or urxvt?

[sharkautarch]

How is loading the library inside gamescope going to help? wouldn't this be debugging wine or urxvt?

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

[MCPO-Spartan-117]

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.

[sharkautarch]

@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

[MCPO-Spartan-117]

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.

[DoomSlinger]

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

[Faceless3882]

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.

[matte-schwartz]

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.

[MCPO-Spartan-117]

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.

[DoomSlinger]

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)

[sharkautarch]

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

[DoomSlinger]

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.

[DoomSlinger]

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.

[sharkautarch]

@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…

[DoomSlinger]

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:

1. wlserver_perform_rel_pointer_motion( dx, dy );
2. 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.

[Faceless3882]

Replying to https://github.com/ValveSoftware/gamescope/issues/1319#issuecomment-2238080363

Top tier analysis right there! So who do we @ in order to fix this? Is it a wlroots bug, Wayland, kwin or gamescope?

[DoomSlinger]

So who do we @ in order to fix this? Is it a wlroots bug, Wayland, kwin or gamescope?

So the thing is, bug 2 happens in gamescope and KDE wayland independently (though the behavior is a bit different in kwin, I'm assuming it's the same bug and kwin just handles these two pointers differently than gamescope). And the issue, to my knowledge, doesn't happen in other wayland desktop managers. I've only seen people complain about kwin and gamescope. So I think it is a gamescope issue AND a kwin issue, but one is not causing the other. I think that the way both have tried to implement these pointer behaviors is just scuffed at the moment, but in different ways.

[Faceless3882]

So who do we @ in order to fix this? Is it a wlroots bug, Wayland, kwin or gamescope?

So the thing is, bug 2 happens in gamescope and KDE wayland independently (though the behavior is a bit different in kwin, I'm assuming it's the same bug and kwin just handles these two pointers differently than gamescope). And the issue, to my knowledge, doesn't happen in other wayland desktop managers. I've only seen people complain about kwin and gamescope. So I think it is a gamescope issue AND a kwin issue, but one is not causing the other. I think that the way both have tried to implement these pointer behaviors is just scuffed at the moment, but in different ways.

That makes sense. Are you able to add your analysis to the kwin bug I linked above? It might help the KDE team.

[Faceless3882]

@Joshua-Ashton anything you can do related to the above mate?

[DoomSlinger]

Just adding this because I just found it by accident. Whenever running the game from terminal, if I move the mouse while the interaction layer is active, I get this spammed in the terminal:

wlserver: [types/wlr_pointer_constraints_v1.c:46] destroying constraint 0x5722287cd940
wlserver: [types/wlr_pointer_constraints_v1.c:278] new confined_pointer 0x5722287cd7a0 (res 0x572228665750)
wlserver: [types/wlr_pointer_constraints_v1.c:46] destroying constraint 0x5722287cd7a0
wlserver: [types/wlr_pointer_constraints_v1.c:278] new locked_pointer 0x5722287cdaf0 (res 0x5722287cc640)

Can't figure out what is calling the function that is generating this log though.

[DoomSlinger]

in wlserver.cpp, if you comment out the line wlserver_warp_to_constraint_hint(); in the function handle_constraint_destroy it will fix bug 1.

This probably has something to do with my last post where constraints are getting created and destroyed constantly while in the interaction menu. Still haven't figured out why that is happening.

When that line isn't commented out, that function is constantly warping the mouse to the bottom right of the screen (the max width and height of your monitor)

[DoomSlinger]

Alright, I think I've found about as much as I'm going to find. The only new thing I've found is that the wlserver_warp_to_constraint_hint(); line from my last post seems to also lock the relative cursor to the bottom right, but I don't know how it does it.

I just am not familiar enough with wayland and wlroots to keep digging through the source code to debug this, so I'm just going to leave it to @Joshua-Ashton or whoever else to actually fix it.

In the meantime, commit https://github.com/ValveSoftware/gamescope/commit/febcf34de9993151261047007867bd385de28e57 does seem to work as intended.

Under that commit, I have to run the game (without gamescope) once under proton 8.0 from a fresh install so that HDR will work, then swap to wine-lutris-GE-proton8-26 to actually play the game in gamescope without it crashing. And head tracking will work too :)

[MCPO-Spartan-117]

Just looked at the LUG github and i noticed this line https://github.com/starcitizen-lug/knowledge-base/wiki/Troubleshooting#-unexpected-behavior-sometimes-also-crashes If you're using a version of gamescope newer than 3.11.51, an additional Gamescope setting is required. Set Relative Mouse Mode to on This is probably when relative became necessary in nested. Looking at the commit i stopped at i may have stopped right before finding the commit lol.

[Faceless3882]

Just looked at the LUG github and i noticed this line https://github.com/starcitizen-lug/knowledge-base/wiki/Troubleshooting#-unexpected-behavior-sometimes-also-crashes If you're using a version of gamescope newer than 3.11.51, an additional Gamescope setting is required. Set Relative Mouse Mode to on This is probably when relative became necessary in nested. Looking at the commit i stopped at i may have stopped right before finding the commit lol.

Yeah, I've tried with this setting on and it doesnt fix the issue for me.

[matte-schwartz]

If you know how to build gamescope, I would recommend trying gamescope built from latest git again to test: https://github.com/ValveSoftware/gamescope/commit/69610ec52429fecbe94c4c042cc42ab43e0491f8

this mostly fixes the interaction layer for me using embedded gamescope (drm backend, gamescope-session) but more testing is required :)

[Faceless3882]

If you know how to build gamescope, I would recommend trying gamescope built from latest git again to test: 69610ec

this mostly fixes the interaction layer for me using embedded gamescope (drm backend, gamescope-session) but more testing is required :)

Just compiled and installed from main and exremely happy to report it's fixed!! Can now play the one game that I couldnt on Linux! @Joshua-Ashton let me know how I can buy you a beer mate, honestly, bloody legend.

[SeeUnsharp]

If you know how to build gamescope, I would recommend trying gamescope built from latest git again to test: 69610ec

this mostly fixes the interaction layer for me using embedded gamescope (drm backend, gamescope-session) but more testing is required :)

I can also confirm that it is working now with commit 69610ec

You have to enable Relative Mouse Mode, otherwise the mouse goes crazy and mouse in inventory won't work.

[DoomSlinger]

If you know how to build gamescope, I would recommend trying gamescope built from latest git again to test: https://github.com/ValveSoftware/gamescope/commit/69610ec52429fecbe94c4c042cc42ab43e0491f8

this mostly fixes the interaction layer for me using embedded gamescope (drm backend, gamescope-session) but more testing is required :)

Worked for me as well while nested with the --force-grab-cursor flag, thanks @Joshua-Ashton !

[MCPO-Spartan-117]

• Interaction mode rotates 90-180 and usually looks to the floor Bad commit: fb5e86b7c5f2e3dfb998eb1d93a759bd9e43319b Fixed commit: 69610ec52429fecbe94c4c042cc42ab43e0491f8

• Need rapid mouse movement events(like 10-100ms per second) to click interactables to use Bad commits: dc911c1c488ea398b105428a4a75b97d8eeadec7...793dde773b8a8cbd82767a9d4a5f2a64dc9121df Fixed commit: still a issue

[DoomSlinger]

• Need rapid mouse movement events(like 10-100ms per second) to click interactables to use Bad commits: dc911c1c488ea398b105428a4a75b97d8eeadec7...793dde773b8a8cbd82767a9d4a5f2a64dc9121df Fixed commit: still a issue

This was fixed on my end in commit 69610ec, at least when using --force-grab-cursor. I haven't tried it without that though

[MCPO-Spartan-117]

It persists on embedded and X11 with it(good luck getting to the buttons without it), can't imagine Wayland being any better. Supposedly some wayland backend(SDL wayland, SDL Xwayland or gamescope wayland) doesn't have the issue.

[MCPO-Spartan-117]

Just want to make sure this is clear, interactables, menus in particular still require rapid movement to click in embedded and SDL(X/Wayland and X11) backends in latest git, the native Wayland backend seems mostly unaffected.

[matte-schwartz]

@MCPO-Spartan-117 what's the exact command you're using for embedded and the SDL backend, the same as your original post?

[MCPO-Spartan-117]

@matte-schwartz With SDL_VIDEODRIVER, --force-grab-cursor and --backend for the SDL and Wayland backends.

[MCPO-Spartan-117]

And now trying again on SC 3.24.1 the Wayland backend doesn't work...