GoDesk: streaming a remote desktop and replaying gamepad input

What the project is, and where the full version lives

GoDesk is a remote control tool that streams your game and desktop frames to other devices and replays gamepad, keyboard and mouse events on the host PC. The README puts it as an alternative to TeamViewer, ToDesk, RustDesk and similar tools, and the Chinese description gives the same list, adding cloud gaming and gamepad simulation to the use cases.

The framing of the repository is unusual and worth understanding before you read the code. This is the open source version of GoDesk, and the full-featured version has been moved to Steam, with the README pointing at a Steam store page and a separate releases repository for downloads. There are demo videos on Bilibili for the enterprise features, for the general case and for the remote desktop case.

The naming matters, because the project appears twice in the description. The repository is GoDesk, and the streaming tool underneath is called GammaRay, with the project description in the README repeating the same wording under the GammaRay heading. The top level repository entries include a `main.cpp`, `src/`, `res.qrc` and `resources/`, so it is a native C++ desktop application rather than a browser or Electron project.

The build system is CMake, with a `CMakeLists.txt` at the root, a `config.cmake`, `env_settings.cmake`, `version.cmake`, an `app_config.h.in` and a `version_config.h.in`, which is the shape of a project that generates a version header and an application config header at configure time. There is also a `CMakeSettings.json` for Visual Studio, a `deps/` directory and `.gitmodules`, so there are third party dependencies fetched as submodules, and a `prebuild/` directory for prebuilt artefacts.

The project is written in C++, the licence is one GitHub cannot classify, the last push was on 2026-06-29, and the release history runs v1.1.9 from 2024-10-17, v2.0.1 from 2025-08-25 with the note New Architecture, and v3.0.1 from 2026-03-03. The official site is godesk.uk with documentation at docs.godesk.uk.

Two connection modes, and a direct path inside the relay one

The work modes section describes two ways of getting a signal from the host to the client, and the second one has a property that is easy to misread.

The first is Connect Directly, which is the obvious arrangement: the client reaches the host directly and the traffic goes between the two machines.

The second is Relay, where the connection is forwarded through a relay server rather than established end to end. The note attached to it says that you can also connect directly in this mode, and the Chinese version of the note says the same thing. Put differently, the relay mode is not exclusively relayed; a direct connection is still possible within it.

That detail changes what the mode is for. If relay were a strict fallback, the mode would be a privacy switch, and the note would not be there. Since a direct connection remains available inside it, the mode is better read as a discovery and reachability arrangement, where the relay is how the two ends find each other and possibly how traffic flows, and the direct path is still on the table. A client behind a restrictive NAT and a host on a home connection are exactly the case where a relay is needed to establish anything at all, and the direct path is there for the case where it is not needed.

The support table gives the platform picture with a two-state vocabulary, Ready and Developing, and there is only one row with a Developing entry:

The table has two columns, Client and Server, and two platform rows, Windows and Android. The Windows client and the Windows server are both marked Ready. The Android client is Ready and the Android server is marked Developing.

So the Windows client and server are both ready, the Android client is ready, and the Android server is still in development. The practical reading is that a Windows host is the supported configuration today, with an Android device acting as the controller, and the reverse, an Android host serving a session, is the piece that is not finished.

The documentation for both is in the repository rather than in the README, with a How To Use document and a How To Build document under `docs/`.

Multi-screen, file transfer, clipboard and recording

The key features section is a list of capabilities with demonstration clips, and the first group is the one that matters most for the cloud gaming use case.

Display multiple screens of remote computers comes in two forms. There is switch display, where the client sees one remote screen at a time and can switch between them, and there is simultaneous display, where several screens are shown at once. For a game, that difference is the difference between a two monitor setup where you alt-tab and a three monitor setup where you keep an inventory panel visible while you play, so the simultaneous mode is the one a game-specific client needs.

File transfer is the next feature, and the claim about it is about speed rather than capability, with the transmission speed described as very fast. Transferring files via clipboard is listed separately, with the same speed claim, and it is the more useful of the two for many purposes, since copying a file on the remote machine and pasting it locally avoids the need to browse a remote file system at all.

Screen recording supports simultaneous recording on multiple screens, which is a screen capture rather than a video encoding of the session, and the difference matters for a support or demonstration use case.

There is then detailed statistical information, shown in another clip, which for a remote control tool usually means connection quality and throughput rather than anything about the host machine.

The cloud and remote game recordings section is the one with named titles, and it is telling that the examples are Wukong, Ori and Elden Ring, three games that are demanding to stream, with the Chinese names alongside. A game with a fast camera and particle effects is a hard case for a remote streaming client, and the choice of demonstrations suggests the project has been tested against exactly that class of content.

A music spectrum feature is listed, with three clips, which reads as an audio visualiser. That is unusual for a remote desktop tool and suggests some kind of local rendering of the remote audio rather than a plain stream.

Finally there is a screenshots section with six images, covering the main window, a status view, a game view, a security view, a client view, a file transfer view and a client status view. The security and status screens in that set are the ones to look at first, because they tell you what the client shows the operator about the connection.

Gamepad replay is the feature that separates it from a plain remote desktop

The distinguishing capability is the one in the project description, and it is easy to underrate.

The tool can replay gamepad, keyboard and mouse events on the host PC. A conventional remote desktop does the second half of that, sending your keyboard and mouse input to the remote machine, which is what makes it a remote desktop. The gamepad half is different, because a gamepad is not a mouse and a keyboard, and a client on a phone or a handheld console has no physical gamepad to forward.

So the model is: the client captures input from whatever device it has, including a virtual gamepad, and the host replays it as a gamepad event to the game running there. That is what makes the cloud gaming case work. You sit with a phone or a Steam Deck, you play a game that is running on a PC somewhere else, and the game receives a gamepad rather than a stream of cursor clicks. The video comes back as frames, and the input goes forward as gamepad events, which is the arrangement a game actually expects.

The Windows and Android support table makes sense against that background. A phone is a plausible client, because the missing piece, a physical gamepad, is exactly what the software supplies. A phone as a server is much less useful, because a phone is not the machine holding the demanding game.

The other thing the feature list implies is that the client renders something for the gamepad. If the client is a phone, the on-screen controls have to be drawn and translated into gamepad button and stick positions, and the screenshots section, which includes a game view, is presumably where that interface appears. The README does not describe the on-screen controls in detail, so the specifics of the mapping from touch to gamepad are in the linked documentation rather than here.

The music spectrum feature fits the same pattern, incidentally. If the client is a handheld, showing a visual representation of the remote audio is a way of making the session feel local rather than a video window with sound.

The licence is personal use only until you get in touch

The licence section is the part to read most carefully, and it is short.

You are permitted to use these codes free in personal use, but not in business. If you want to use it in commerce, please contact the two addresses given. The Chinese version says the same thing, personal free use, do not use commercially without contacting them first.

So this is not an open source licence in the usual sense, and the licence GitHub shows for the repository is one the site cannot classify. There is no MIT, no Apache and no GPL grant here, and the terms are a personal use permission with a commercial licence available on request.

That has a practical consequence. If you are evaluating this for a company, an internal deployment across a team, or a product that bundles it, you cannot take the licence at face value and you have to have the conversation. The contact addresses are given in the README, so the path is clear, and a commercial licence negotiated with the project is a normal arrangement, but the default position is that using it at work without asking is not permitted.

The relationship between this repository and the downloadable full version is worth spelling out between this repository and the downloadable full version. The README points the open source version here and the full-featured version to a Steam release and a separate GammaRay releases repository, and the open source version is described as free. So the split the project has chosen is between an open source core and a commercially distributed build, with this repository being the former.

For a reader who wants to understand the project rather than deploy it, that split is fine. The source is here, the build instructions are in the repository under `docs/`, and the differences between the two versions are not described in the README, so anyone trying to work out whether the open source build includes the cloud gaming path is reading the code.

Editorial conclusion

Adopt GoDesk if you want to control or play a PC from another device, especially a phone, and you are using it personally, because the licence permits free personal use and requires a conversation for commercial use. Do not adopt it as a TeamViewer replacement for a company without checking the terms first, and check first which platform pair you need, because the support table shows the Windows client and server as ready while the Android server is still listed as in development.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. RGAA-Software/GoDesk on GitHub