If you're playing Guild Wars and your Steam Deck goes into standby mode, when you bring it out of standby some time later, the game is still running and acts like it is still connected, but you can no longer move or interact.
The game's connection is still active, as verified using the ss tool in desktop mode. As you try to move or interact, the receive queue keeps growing, but a disconnect event never occurs.
Reproduction
Launch Guild Wars on a Steam Deck, log into the game
Push the power button to put the device in standby mode
Wait 15 seconds
Push the power button again to bring the device out of standby mode
Try to move your character or otherwise interact with the game, observe that no interactions work but no disconnect occurs
Some period of time later (minutes), the player will receive a disconnect notification.
Debugging details:
Post-resume, no notifications are being received via the IO completion port associated with the socket.
send() calls to the socket report success (all bytes transmitted), but never get transmitted (and also don't cause the socket to timeout locally and trigger a disconnect)
Using desktop mode and monitoring watch -n 1 "ss -tunap", we can verify that the game server connection socket still exists and its receive queue is monotonically increasing as the client tries to send messages (see screenshot, the circled row is the zombie connection)
Compatibility Report
System Information
steam-29720.log
I confirm:
steam-29720.log
Symptoms
If you're playing Guild Wars and your Steam Deck goes into standby mode, when you bring it out of standby some time later, the game is still running and acts like it is still connected, but you can no longer move or interact.
The game's connection is still active, as verified using the ss tool in desktop mode. As you try to move or interact, the receive queue keeps growing, but a disconnect event never occurs.
Reproduction
Some period of time later (minutes), the player will receive a disconnect notification.
Debugging details:
Post-resume, no notifications are being received via the IO completion port associated with the socket.
send() calls to the socket report success (all bytes transmitted), but never get transmitted (and also don't cause the socket to timeout locally and trigger a disconnect)
Using desktop mode and monitoring
watch -n 1 "ss -tunap", we can verify that the game server connection socket still exists and its receive queue is monotonically increasing as the client tries to send messages (see screenshot, the circled row is the zombie connection)