[GH-ISSUE #332] Steam Deck Support in Game mode and Desktop mode (Client) - Flatpak needed? #175

New issue

Open

opened 2026-05-05 22:12:49 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 22:12:49 -06:00

Owner

Originally created by @pushpinderv on GitHub (Oct 24, 2025).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/332

Is there a way currently to run lan-mouse as a client on the steam deck? Do we need a flatpak for it?

Goal is to be able to run the lan-mouse client receiver in both Game mode (Wayland) and Desktop mode (X11).
And is it possible to have it auto-start when the Deck boots directly to Game mode or switches modes? (Basically client should always keep running on the deck, and work in both game and desktop modes).

I'm willing to purchase Synergy if it can work flawlessly this way - but I need to be sure if this is even technically possible.

Originally created by @pushpinderv on GitHub (Oct 24, 2025). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/332 Is there a way currently to run lan-mouse as a client on the steam deck? Do we need a flatpak for it? Goal is to be able to run the lan-mouse client receiver in both Game mode (Wayland) and Desktop mode (X11). And is it possible to have it auto-start when the Deck boots directly to Game mode or switches modes? (Basically client should always keep running on the deck, and work in both game and desktop modes). I'm willing to purchase Synergy if it can work flawlessly this way - but I need to be sure if this is even technically possible.

gitea-mirror commented

2026-05-05 22:12:51 -06:00

Author

Owner

@DrYak commented on GitHub (Oct 24, 2025):

Fellow steamdeck user here:
I run it on my deck, but I self-compile it locally in my home (I use an environment setup by miniforge for work-related reasons) instead of trying some flatpak.
I've only used it in desktop mode (I don't need keyboard/mouse sharing in game mode for my own use case).

lan-mouse detects which API to talk to the server upon starting, so switching between Wayland and X11 on-the-fly will not be possible (maybe auto-starting after the graphical interface is started?)

I am not sure wether it will work in game mode at all as steamOS uses its own Wayland compositor (Gamescope) which unlike, e.g., Kwin_wayland, might not have all the necessary API that lan-mouse relies upon. This could affect all mouse-sharing tools (including commercial Synergy - check if they explicitely cover game mode before spending).

@DrYak commented on GitHub (Oct 24, 2025): Fellow steamdeck user here: I run it on my deck, but I self-compile it locally in my home (I use an environment setup by miniforge for work-related reasons) instead of trying some flatpak. I've only used it in desktop mode (I don't need keyboard/mouse sharing in game mode for my own use case). lan-mouse detects which API to talk to the server upon starting, so switching between Wayland and X11 on-the-fly will not be possible (maybe auto-starting after the graphical interface is started?) I am not sure wether it will work in game mode at all as steamOS uses its own Wayland compositor (Gamescope) which unlike, e.g., Kwin_wayland, might not have all the necessary API that lan-mouse relies upon. This could affect all mouse-sharing tools (including commercial Synergy - check if they explicitely cover game mode before spending).

gitea-mirror commented

2026-05-05 22:12:52 -06:00

Author

Owner

@feschber commented on GitHub (Oct 24, 2025):

What @DrYak says sums it up pretty well.

wlr-virtual-pointer-unstable
and
virtual-keyboard-unstable are in fact not supported in gamescope, as you can see from the linked pages.

When #297 is merged, it should work in gamescope as well with additional configuration.

For desktop mode, you dont need to compile it yourself, you can just download the binary from the releases section.
If you want it to autostart on login, you can setup the systemd service, as described in the README (you will likely need to change the exec path).

@feschber commented on GitHub (Oct 24, 2025): What @DrYak says sums it up pretty well. [wlr-virtual-pointer-unstable](https://wayland.app/protocols/wlr-virtual-pointer-unstable-v1) and [virtual-keyboard-unstable](https://wayland.app/protocols/virtual-keyboard-unstable-v1) are in fact not supported in gamescope, as you can see from the linked pages. When #297 is merged, it should work in gamescope as well with additional configuration. For desktop mode, you dont need to compile it yourself, you can just download the binary from the releases section. If you want it to autostart on login, you can setup the systemd service, as described in the README (you will likely need to change the exec path).

gitea-mirror commented

2026-05-05 22:12:53 -06:00

Author

Owner

@pushpinderv commented on GitHub (Oct 25, 2025):

I did not expect such fast responses! :')
Thank you @DrYak and @feschber.

Since I'm fixated on having full compatibility, game mode and desktop mode, #297 is my only hope, right?
If so, I'll wait, or try to help if I can, to get #297 in - and have this up and running flawlessly between the deck and my windows 10 machine.

Please let me know if I can help in any way.

@pushpinderv commented on GitHub (Oct 25, 2025): I did not expect such fast responses! :') Thank you @DrYak and @feschber. Since I'm fixated on having full compatibility, game mode and desktop mode, #297 is my only hope, right? If so, I'll wait, or try to help if I can, to get #297 in - and have this up and running flawlessly between the deck and my windows 10 machine. Please let me know if I can help in any way.

gitea-mirror commented

2026-05-05 22:12:53 -06:00

Author

Owner

@feschber commented on GitHub (Oct 25, 2025):

If you want, you could try compiling the PR yourself and set the necessary permissions, as discussed.
The layer-shell backend should at least partially work for input capturing, making it at least functional for receiving input (https://wayland.app/protocols/keyboard-shortcuts-inhibit-unstable-v1 apparently is not supported)

@feschber commented on GitHub (Oct 25, 2025): If you want, you could try compiling the PR yourself and set the necessary permissions, as discussed. The layer-shell backend should at least partially work for input capturing, making it at least functional for receiving input (https://wayland.app/protocols/keyboard-shortcuts-inhibit-unstable-v1 apparently is not supported)