fix(linux): steamdeck pointer orientation

[alanjds]

Description

I am experiencing an issue when using Moonlight Android that also affects its fork Artemis: When serving Sunshine from a SteamDeck, the pointer orientation does not match the screen orientation. I mean, when moving the finger horizontally, the mouse pointer on the streamed screen moves vertically.

My current suspicion is that the rotation sourced from DRM_MODE_ROTATE_270 changes the image orientation but does not change the input orientation.

So, instead of advocating for applying the same solution to input handling in Sunshine, I am experimenting with removing the image rotation on Sunshine and handling both the image and input rotation on client side.

That would be cleaner IMHO because Sunshine would be responsible to provide accurate image and input handling, and the decision on how to present these would be kept in full on the client side. Would still be useful if Sunshine provides the rotation info it discovered, as metadata to the client.

Why a Draft PR?

This PR is opened as Draft because I could compile a working binary from current master Sunshine on Ubuntu 24.04 but I failed to make it build any package with cpak, and the bare binary does not run on Steamdeck because some library missing.

So I am pushing a barebones PR just to make CI build the needed packages on my behalf, instead of preparing Steamdeck to build the stuff directly.

Issues Fixed or Closed

• Relates to Portrait screens in landscape orientation are seen as portrait with KMS #3203
• Relates to Wrong screen orientation on Steam Deck (Linux) using KMS #2439
• Practically reverts Steam Deck Gamingmode fix #711

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 New issue
1 New Code Smells (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[ReenigneArcher]

Thank you for the PR

This PR is opened as Draft because I could compile a working binary from current master Sunshine on Ubuntu 24.04 but I failed to make it build any package with cpak, and the bare binary does not run on Steamdeck because some library missing.

So I am pushing a barebones PR just to make CI build the needed packages on my behalf, instead of preparing Steamdeck to build the stuff directly.

I ran the workflow, artifacts should be available shortly. cpak won't create a package for ArchLinux, but there will be one generated by our CI.

[alanjds]

I ran the workflow, artifacts should be available shortly. cpak won't create a package for ArchLinux, but there will be one generated by our CI.

Hum... Thanks for triggering the CI. However I could not find the built artifacts. Where are they stored?

Just found the link inside the CI action: https://github.com/LizardByte/Sunshine/actions/runs/15139957404/artifacts/3161359794. Sorry for nudging.

[alanjds]

Btw, I am running Bazzite on that SteamDeck, so may AppImage be the best option, if I understood correctly the installation docs. Because it is not ArchLinux.

[alanjds]

I just tested the built AppImage in a standard Lenovo laptop with the screen correct and then rotated. Moonlight Android input handling worked correctly in both cases.

On Moonlight Android I now see black borders but correct input handling. On Artemis I can use some option to get rid of black borders if using the cellphone in Portrait mode when connecting. Then just turn the phone and kept using :)

Will test the same AppImage in SteamDeck before speaking more, but seems that this custom handling is indeed messing with the input handling of the clients.

[ReenigneArcher]

I ran the workflow, artifacts should be available shortly. cpak won't create a package for ArchLinux, but there will be one generated by our CI.

Hum... Thanks for triggering the CI. However I could not find the built artifacts. Where are they stored?

Just found the link inside the CI action: https://github.com/LizardByte/Sunshine/actions/runs/15139957404/artifacts/3161359794. Sorry for nudging.

Deb and Arch packages are in ci-docker. https://github.com/LizardByte/Sunshine/actions/runs/15139957392?pr=3893

[alanjds]

Done tests on SteamDeck running Bazzite. Both master and this custom patched version behave exactly the same. That is surprising.

On both servers (master and patched) the Moonlight Android seems to always respect the hardware orientation for image and the desktop orientation for input.

I am inclined to think that:

• The orientation patch now on master should be removed
• Input should be transformed from desktop to hardware somewhere.

This can be changed on Sunshine or on Moonlight. But as Sunshine is the one sending hardware orientation and interpreting input as desktop orientation, I think so far that Sunshine is the one that should "fix" this by making the orientation unique.

As changing the hardware output orientation seems harder (or impossible) as demonstrated by the lack of effect of this PR change, seems that desktop input orientation is the place possible to be patched.

For now I think that this is easier do on Sunshine side, because it already have the desktop orientation information available (DRM_MODE_ROTATION_* detection).

What do you think?

[ReenigneArcher]

I agree. The transformations should be done on the Sunshine side.