Virtual Mouse "Disconnects" After Exactly 3.0 seconds, causing compatability issue with some games

[john-parton]

Your system information

• Steam client version: 1726683985
• SteamOS version: 3.6.19 (20241021.100)
• Opted into Steam client beta?: No
• Opted into SteamOS beta?: No
• Have you checked for updates in Settings > System?: Yes

Please describe your issue in as much detail as possible:

When using an emulated mouse mapped to the right track pad, it appears that mouse "disconnects" after exactly 3 seconds. In a previous versions of SteamOS, I believe that maybe the mouse stayed "connected" even when inputs were not being provided.

In my specific case, this affects Diablo 2 Resurrected running under Proton 8, 9 and Experimental. The game has an mouse cursor that accepts input from both an actual mouse, as well as the joystick and inputs from the d-pad. The game presents a circular cursor or reticle. The reticle doesn't appear unless mouse inputs are provided. The reticle disappears exactly three seconds after mouse inputs are provided.

To test this, I bound "mouse move relative" to a back button, took a video and counted frames. The video was at 30fps and the cursor was on screen for exactly 90 frames (dumped frames using ffmpeg and just counted).

I've attached a video of the behavior, including narrative which is mostly just what I have written here.

Some users on reddit reported this as starting just yesterday as well:
https://www.reddit.com/r/SteamDeck/comments/1f39jmx/comment/ltgi0gn/
https://www.reddit.com/r/SteamDeck/comments/1f39jmx/comment/ltgnb76/

Steps for reproducing this issue:

1. Install Diablo 2 resurrected under Proton
2. Boot up game and get into a game
3. Move mouse cursor, reticle appears
4. Wait three seconds, reticle disappears

Possible solutions

If it's not possible to revert the change, nor possible to increase the timeout to a much longer time, it would be nice if this value were somehow exposed to a user (i.e. me) so that an appropriate value can be input per game.

out.mp4

[john-parton]

I'm not sure if it's an open-source repo, or if it's internal source code, but I would search through the code bases and look for any magic "3000" ms constant.

[matte-schwartz]

Cursors are set to auto hide after 3000ms in /usr/bin/gamescope-session with --hide-cursor-delay 3000

[john-parton]

Interesting. I'm not familiar with the internals here. Is there a simple way to adjust this? Launch parameters?

[matte-schwartz]

The only way I'm aware of is unlocking the rootfs and directly changing or removing that line in the script, but that will get overwritten every SteamOS update. Probably a good feature request to give a user-facing way to alter that, maybe as a part of user configurations that's being worked on in Gamescope.

[john-parton]

Yikes. Definitely something I could probably do, but not fun for the vast majority of users.

Where's that located exactly? A quick modification with an environmental variable would be allow for fixing it

EDIT I'll make the modification and report back if it resolves this issue. I'm not sure why this wasn't an issue before the latest update however.

[matte-schwartz]

it's possible it regressed in some other way, and the delay is only now presenting the issue, since that launch parameter is not new with 3.6

[john-parton]

Must be. I adjusted it to be 30000 (corresponding to 30 seconds) and the behavior now happens at exactly 30 seconds.

Will try setting it to -1 and report back.

EDIT Apparently -1 has the same behavior as zero, where the cursor is immediately hidden. My intuition/guess would be that -1 would correspond to infinity. I'll set it to some arbitrarily large number.

Instructions to implement this workaround

Enter desktop mode.

Set a sudo password if you haven't already:

A. Open a console
B. Enter the passwd command
C. Enter your password twice. Do not forget this password, there isn't an easy way to recover it.

Disable readonly mode

i. Open a console
ii. Enter sudo steamos-readonly disable
iii. You will be prompted to enter your sudo password.

Modify /usr/bin/gamescope-session

1. Find the file /usr/bin/gamescope-session and open it with a text editor (Kate)
2. Edit the line --hide-cursor-delay 3000 to read --hide-cursor-delay 86400000
3. Save the file. You will be prompted to enter your sudo password.

After a SteamOS update, you might need to repeat steps 1 through 3 again.

EDIT 2

You must "jiggle" the mouse (not joystick) at least once after launching the game. I have mouse movement bound to the right track pad.

Certain things will cause the bug to crop back up. In particular:

• Opening the virtual keyboard
• Opening the steam or options menus

If that happens, just jiggle the mouse again and it should be back.

EDIT 3

You must also be using Proton 9 or Experimental for this to work.

To work around the HDR bug, you need to open the graphics settings and "apply" them again. You don't have to make any changes, just apply.

[john-parton]

Setting it to 86400000 (corresponding to 24 hours) essentially "solves" this problem. The remaining problems I see are:

1. Requires running sudo steamos-readonly disable
2. Affects every game, not just this one game where this behavior is a problem
3. There's probably some good (or maybe not-so-good) reason the default is three seconds. I truly have no idea, so I'm not sure if there's some hidden consequence of changing this.

I tried using an environmental variable, but my understanding of how steam actually launches games is deficient.

I did

--hide-cursor-delay "${STEAM_GAMESCOPE_HIDE_CURSOR_DELAY:-3000}"

in gamescope-session

And then in the steam launcher, tried

STEAM_GAMESCOPE_HIDE_CURSOR_DELAY=30000 %command% under launch options, but that didn't work as expected. I imagine it's because gamescope isn't launch/re-launched per game? Just started once with the steam session? Or maybe the environmental variables aren't scoped down to that level?

[john-parton]

Should I post this to the gamescope repo? Or is this the right place for continued work?

[kisak-valve]

Hello @john-parton, I knee-jerk transferred this issue report to the gamescope issue tracker based on the direction the conversation was going, but that was incorrect. If that's the root cause of the behavior you're seeing, then this is an issue in the way the SteamOS distro uses gamescope, not an issue with gamescope itself.

[john-parton]

Thanks, that makes sense. I'm happy to run some additional tests.

I'm not even sure which component the change would have been in to cause the regression. If I had to talk a wild stab, I would think the video driver or the graphics API translation layer. Maybe DXVK? Although I thought DXVK was bundled with Proton, not directly with SteamOS?

Unrelated/off topic, but there's also a bug with HDR where the saturation levels in D2R are wrong unless you go into the graphics settings in game and "reapply" the settings. It was honestly just a minor annoyance, and I didn't even know where to report it. Proton probably?

[ubeogesh]

The workaround of increasing the delay doesn't help much. It shows the cursor, but the visible cursor actually won't move (but the actual, invisible cursor does move, it can highlight different things, e.g. different inventory items)

Here's how it looks for me

bug_noaudio.mp4

[john-parton]

I played for multiple hours yesterday, and it did help a ton. Someone on Reddit also reported that it improved (but did not completely fix) the issue

Probably there's some differences between our configs.

Some ideas:

• What version of proton are you using?
• Do you have the video settings set up "full screen" or "windowed" in d2?
• Any other customizations?

[john-parton]

Oh, and I realize maybe you didn't watch the video, so there's a detail missing from the text:

You have to jiggle the virtual mouse at least once. I have mouse movement bound to right track pad. It's not enough just to edit the file.

You can also bind a move mouse relative command to a button if you want a "jiggle the mouse" button

I've updated my comment above with some more info

IDEALLY the underlying issue would be fixed, but we're here right now.

[ubeogesh]

moving the mouse helps the cursor to appear, but the visual cursor still won't move by the joystick. The cursor will only "respawn" after the game "unhides" it (after you put an item down)

I tried both windowed and full screen, result doesn't change

bug_with_mouse.mp4

P.s. One thing i might have slightly unusual, is that I launch D2R.exe directly, without the battle.net launcher. Oh and I also use proton 8.0.5 (i had some odd crashes messages on v9 after exiting the game)

P.P.S. upping proton to 9.0.3 made the workaround functional, i.e. joystick can now move the cursor. But unfortunately with proton 9.0.3 or experimental games colors are all messed up - all oversaturated. It only is fixed by going to the menu and "touching" the brightness calibration (open and save without changing), but I have to do it after every single restart... If I turn off HDR (via DXVK_HDR=0) this problem goes away

[ubeogesh]

I would also like to add that I normally play in Mouse & Keyboard mode ("Mouse Region" assigned to right pad) and there I have a different issue. After dropping\putting an item down in D2R, the cursor doesn't always reappear. I can't quite understand when it reappears and when it doesn't tho, but it's VERY OFTEN (about half the time). It doesn't reproduce with a real mouse.

On a side note, something has changed in the latest release, and " --hide-cursor-delay -1" no longer works. I have to set it to a big positive value instead

[john-parton]

Yes, I also commented that negative one doesn't work. That's why I suggested setting it to 24 hours.

The HDR issue is also very annoying.

It's only necessary to hit "Apply" (without making changes) for the saturation levels to be fixed in my testing.

We should probably make a report on proton

[john-parton]

I've created an issue with Proton here regarding the HDR issue: ValveSoftware/Proton#8195

If you have anything to add regarding that, I believe that's the correct place for that, although I'm not 100% sure.

[john-parton]

Regarding the "negative one" change. Here's what I believe happened.

In an older version of gamescope, the value was directly assigned using atoi

Old code here: https://github.com/ValveSoftware/gamescope/blob/b14d851137f00a1dade22279ed6aeaed72e21337/src/steamcompmgr.cpp#L7439C22-L7439C26

In newer versions, it's explicitly cast and also multiplied by a constant. Maybe the value needs to be in microseconds or something?

https://github.com/ValveSoftware/gamescope/blob/056b79e5f8a40568bb7e7927ce77868f243a3d3e/src/steamcompmgr.cpp#L7419

Regardless, I don't think the "negative one means forever" feature was actually intentional. I believe what happened is that negative one was returned using twos complement and then cast to an unsigned int. Negative one is all ones in twos complement (so 11111111 in eight bits, 64 ones in 64-bit). When that's case to unsigned, its results in it being the largest possible unsigned number for whatever width you happen to be using.

[ubeogesh]

Good find, I tried to find where that value is parsed but couldn't find where it goes past the main.cpp...

In this case, the cursor not showing up after you put down an item (in kb/m mode) is probably it's own thing? Or could be related to the gamepad cursor problem?

[john-parton]

I think actually the negative one thing might be TANGENTIALLY related, but just in the sense that there's been some change to the hide cursor logic.

I'll ponder on it and maybe do some digging

[john-parton]

Someone on Reddit reported a similar/identical issue with Titan Quest and Grim Dawn.

https://www.reddit.com/r/SteamDeck/s/HVKrRWpTsB

I don't have any additional info beyond that

[matte-schwartz]

I can clearly see the issue in Grim Dawn, will see if I can bisect

edit: the broken behavior in Grim Dawn starts to happen between tags 3.13.19 and 3.14.1 in gamescope, will narrow down further later

[john-parton]

Latest SteamOS update still has this issue.

I created a desktop file to apply the fix with a click.

#!/usr/bin/env xdg-open
[Desktop Entry]
Comment[en_US]=
Comment=
Exec=/bin/bash -c 'sudo steamos-readonly disable && sudo sed -i -E "s/--hide-cursor-delay [0-9]+/--hide-cursor-delay 86400000/" /usr/bin/gamescope-session'
GenericName[en_US]=
GenericName=
Icon=uav
MimeType=
Name[en_US]=MouseFix
Name=MouseFix
Path=
StartupNotify=true
Terminal=true
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=
X-KDE-SubstituteUID=false
X-KDE-Username=

Attached file MouseFix.txt You need to rename it to MouseFix.desktop.

[matte-schwartz]

Can you send a screenshot of what your steam input layout looks like for the game as well? On the game entry, press the controller button and click on View Layout, and then the Steam button + R1 (right bumper) should work to take a screenshot.

Also, in the game, what's the behavior like if you hold down the Steam button for a couple of seconds to put the right touchpad in Steam's own mouse mode and then continue to use the touchpad with that override held down?

[ubeogesh]

I have an interesting updated regarding the keyboard and mouse control mode (bound via steam input) in Diablo 2 Resurrected.

The following issue is only when playing on BattleNet!

When you pick up an item and place it back in your inventory, the cursor doesn't re-appear.

But in single player, it does re-appear. I think it's because all inventory manipulations in Diablo II are transactional and thus have latency (picking up item "into the cursor" is a transaction; cursor item slot is present in the save file).
This also explains why SOMETIMES, the cursor does reappear on battlenet (but rarely)
It is even more noticeable when playing on a remote server, e.g. i am in Europe and if I log in to Korean server i will have very noticeable latency between clicking an item in inventory and the item replacing my cursor.

[ubeogesh]

@matte-schwartz unfortunately it screenshots the game, not the overlay. Here's a photo instead

[john-parton]

Layout is pretty much standard gamepad, but mouse bound to right track pad.

[john-parton]

Steam button and right joystick work fine as the emulated mouse.

Not exactly sure what you wanted to test

[ubeogesh]

In my case with kb/mouse setup, using right pad with the steam button forces the cursor to re-appear.

P.s.:

Eureka. The issue is with the "mouse region" setting specifically. Using it doesn't make the cursor re-appear. If i change right pad to just "mouse", the cursor does re-appear reliably.

I really hope you fix this guys, because "mouse region" is soooo mich better for this game.

P.p.s.:

I found a workaround for the "mouse region" mode!

To my left click (left trigger), i have added a second command: On release press, move mouse by 1 pixel on X axis, with fire start delay of 50ms (25 isn't always enough!). This forces the cursor to re-appear, and since my right thumb is on the "mouse region" trackpad, the movement actually isn't happening.

@matte-schwartz do you think i should create a separate bug for the "mouse region" mode?

[matte-schwartz]

Steam button and right joystick work fine as the emulated mouse.

Not exactly sure what you wanted to test

Some games seem to have different steam input behavior for cursor and mouse, was trying to make sure I was understanding the setup correctly here

[matte-schwartz]

Eureka. The issue is with the "mouse region" setting specifically. Using it doesn't make the cursor re-appear. If i change right pad to just "mouse", the cursor does re-appear reliably.

@matte-schwartz do you think i should create a separate bug for the "mouse region" mode?

@ubeogesh no, that is sounds 1:1 with what I am seeing in ValveSoftware/gamescope#1602 I'll update my issue report with this latest information in a bit.

The "cursor" preset for Grim Dawn has the same exact issue that you describe with "mouse region", and I can also see the same behavior with choosing "mouse region" with the vanilla M+K preset for steam input. however, choosing "as mouse" does not have the issue.

That's why I asked john-parton about their Steam Input setup to get a better understanding since it seems like there were multiple things reported here

[ubeogesh]

@matte-schwartz ok, in this case i'll mention the workaround in the linked grim dawn issue.

By the way, an EVEN BETTER workaround is, bind the "touch" on the right trackpad to "move cursor by 1px" with repeat (turbo) = on. This seems to work flawlessly.

[john-parton]

Was there anything else I can provide here? Local time was after midnight, so I wasn't exactly awake.

[matte-schwartz]

@john-parton I think I've seen everything relevant, thanks.

When using an emulated mouse mapped to the right track pad, it appears that mouse "disconnects" after exactly 3 seconds. In a previous versions of SteamOS, I believe that maybe the mouse stayed "connected" even when inputs were not being provided.

I rolled back to 3.15.19 to test a few different games that use Mouse + Keyboard input, and in all of them, the cursor does disappear after 3000ms just like it does on SteamOS 3.6. I don't own Diablo II Resurrected to test, but I would be surprised if the cursor lingered on the screen constantly when everything else I've tried does not seem to do that. I'm not a Valve employee, but maybe one of them has access to the game and can double check this just to be safe.

The disappearing cursor and having it not come back as ubeogesh reported does seem to be a regression, since I was able to reproduce in other titles and showed a clear change between 3.5.19 and 3.6.19

Personally, I think this is more of a feature request for a way to force the cursor always visible (which you have also stated in the original post) rather than a new bug. I make no promises, but I will try and explore some methods to force the cursor to be always visible for certain games, like maybe GAMESCOPE_FORCE_SHOW_CURSOR=1 or something in a game's launch settings.

[john-parton]

Thanks! Yeah, I wasn't sure if you were an official or not, but it's clear your knowledge on this topic far outstrips mine.

I've been playing Diablo 2 Resurrected since I got my deck in 2022, and the behavior definitely changed, although perhaps I'm not doing a very good job of describing the old behavior. In laymen's terms "it worked, and then it didn't," which is why I categorized it as a regression.

A launch option would be absolutely fantastic as far as I'm concerned.

[ubeogesh]

@matte-schwartz pardon me, but why not let the game decide whether to show the cursor or not? I am no expert, but I imagine the game issues some cursor show/hide commands when you pick up and put down items

@john-parton I have a workaround for you, that should work fine even with the standard 3000 hide cursor timeout.

• In the Controller Layout settings, go to your Left Joystick (or Right if you swapped joysticks in D2 settings)
• Select the Outer Ring Command
• under "Mouse" category choose "Move by amount"
• Specify 1 pixel on X or Y
• Click on the cog icon near the LEFT JOYSTICK BEHAVIOUR (NOT the outer ring command)
• Scroll down to the Outer Ring Radius setting and reduce it to a small value, but not down to 1! I have found that 4 steps from the left (3277) works the best.
• Now go back and click on the cog near outer ring command
• Enable Turbo and set repeat rate to the maximum value (1000).

Theses settings will make cursor to reappear constantly. It still disappears from time to time, but i find it very usable