Cursor/Mouse Region options in Steam Input stay invisible after initial 3000ms timeout, Mouse/Joystick Mouse work as expected #1602
Comments
|
Was able to narrow down the issue quite a bit, major difference seems to be in how "Mouse Region" Steam Input events (or "Cursor", which is Grim Dawn's default right trackpad UI binding) get treated for presentation by gamescope with a visible cursor vs how "As Mouse" Steam Input events get treated for presentation. Mouse Region events went from always showing a visible cursor in a similar manor to "As Mouse" to only showing a visible cursor for the 3000ms timeout set in This lines up with what was reported by another user: ValveSoftware/SteamOS#1681 (comment) but in Diablo II Resurrected |
|
A workaround for this is binding right pad touch to "Mouse > Move Cursor by amount > 1 in X or Y", then go to settings and enable "hold to repeat (turbo)". These "move by amount" events force the cursor to always be shown. |
|
from my digging today, I'm almost certain the issue lies somewhere in the handling of MouseCursor but I've unfortunately not made much progress in terms of fixing things. debugging patch for the logs below: https://gist.github.com/matte-schwartz/91a2f601e55dd890bc5041abbdb0476a (ignore log_xcursor, thats irrelevant here) when using "Cursor" or "Mouse Region" in Steam Input:you can see it constantly bounce between MouseCursor_Constrained and MouseCursor_NonConstrained, but neither of which draws a cursor consistently, and the pointer events don't get picked up and forwarded from wl_server -> gamescope_ei when using "Mouse" or "Joystick Mouse" in Steam Input: (or while holding the "Steam" hotkey)you can see here that only MouseCursor_NonConstrained gets called, and the pointer is properly forwarded and drawn from wl_server -> gamescope_ei |
matte-schwartz
changed the title
|
As an experiment, I am able to at least get a visible cursor again in the absolute silliest way possible, by changing given this, it seems like we should probably look at |
|
EDIT: well Grim Dawn still fails to show the cursor with this change, while another game I tested did work, so I truly give up at this point :/ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there an existing issue for this?
Are you using any gamescope patches or a forked version of gamescope?
Current Behavior
Bisected to: d7758a8
Original report: ValveSoftware/SteamOS#1681
I investigated Grim Dawn (219990), and it regresses between 3.13.19 and 3.14.1 in the
jupiter-mainrepo which I then bisected between on my OLED Deck.After the bisected bad commit, the mouse in the menu of Grim Dawn goes from always showing when using the default layout and moving the mouse with the right touchpad to rarely showing under the same conditions. it does show properly until the 3000ms timeout if you touch the screen directly or if you invoke the cursor by holding the Steam button and using the touchpad.__
EDIT: the bad behavior continues on desktop when using both
gamescope -f -- %command%andgamescope -f --force-grab-cursor -- %command%on SteamOS 3.6.19Steps To Reproduce
The mouse will remain invisible while still interacting with the menu
The mouse will appear, but only for 3000ms as set in gamescope-session
Hardware information
Software information
Which gamescope backends have the issue you are reporting?
Logging, screenshots, or anything else
running gamescope with wlserver debug logging shows a ton of the same sequence of events whenever the cursor is moved
The text was updated successfully, but these errors were encountered: