Add optional Nested Desktop and Steam desktop integration

[Janleyx]

Summary

This contribution adds optional SteamOS-style desktop integration without replacing Armada's normal KWin Desktop Mode:

• Add Nested Desktop for brief Plasma access from Gaming Mode.
• Add Armada Native so native non-Steam launchers can be explicitly kept out of Proton.
• Add Add to Steam actions for Dolphin and Plasma's application launcher.
• Start Steam reliably in full Desktop Mode so Steam Input provides gamepad desktop controls.
• Keep Nested Desktop and the physical handheld panel on independent display profiles.

Rebased for current Armada

This branch is rebuilt directly on current main after testing Armada beta 20260729.d812101 on an AYN Odin 2 Pro.

Current Armada already ships plasma-nm, bluedevil, upower, corrected desktop ownership, armada-jupiter-hw-support, and a kernel with CONFIG_UNICODE=y. The earlier copies of those changes have therefore been removed from this PR. There is no SD-card workaround or package layering in this branch.

The existing desktop-bootstrap is preserved, including its newer device and dual-screen logic. The only bootstrap change is a four-line guard preventing the physical-panel setup from running inside Nested Desktop.

Nested Desktop

Nested Desktop is opt-in and has no runtime effect unless a user adds and launches it. Direct KWin Desktop Mode remains preferred for performance and extended desktop work.

The launcher:

• runs fullscreen KWin under the current Gamescope display path;
• creates an isolated runtime and D-Bus session while sharing the parent PipeWire sockets;
• clears Gaming Mode's forced Qt/X11 backend so Plasma creates a native Wayland panel;
• uses normal landscape orientation and 150% logical scaling without forcing a render resolution; and
• isolates legacy KScreen and current KWin output state because the Odin's physical DSI-1 panel and Gamescope's synthetic X11-0 output can report the same display identity.

That final isolation prevents Nested Desktop's landscape transform from making full Desktop Mode portrait, while leaving external-monitor profiles untouched.

Validation

Validated through reboots and repeated Gaming Mode → Nested Desktop → Desktop Mode cycles on an AYN Odin 2 Pro:

• Armada updated cleanly to beta 20260729.d812101 with no local RPM layering.
• Nested Desktop launches at 1920×1080, landscape, 150% scale (1280×720 logical), with a responsive Plasma panel.
• Full Desktop Mode remains independently landscape at 150% after Nested Desktop exits.
• Steam autostarts in full Desktop Mode for gamepad controls.
• NetworkManager, Bluetooth, and UPower services remain active from Armada's upstream packages.
• The SD card remains mounted and registered using Armada's native kernel/Jupiter support; the obsolete local SD overlay was removed from the test system.
• Shell launchers pass Bash syntax checks on the Odin, desktop application entries validate, and deployed files were checked for Linux line endings.

Related Armada-compatible work

• DeckBridge: https://github.com/Janleyx/DeckBridge
• Odin 2 ARM64 LSFG-VK fork: https://github.com/Janleyx/decky-lsfg-vk-for-Ayn-Odin-2
• Architecture-selection fix proposed upstream: Add automatic Armada ARM64 installation support xXJSONDeruloXx/decky-lsfg-vk#240

I would also be happy to help maintain and test Armada, and would love to join the team if you are looking for contributors.

[virtudude]

@Janleyx Thanks for the contribution! Can you tell me more about the purpose of the nested desktop? One thing that concerns me about it is that KWin is actually a more efficient compositor than gamescope on this hardware, so it might regress performance in desktop mode.

Also wondering if we still need the SD changes you have in here after I added jupiter-hw-support?

[Janleyx]

oh hi! om so pleased you reached out! first off love the work behind the project and have been working hard on trying to help along. The whole point of nested desktop is to have quick access to your desktop enviroment from within gamemode so you dont have to switch to desktop mode to then switch back essentially. I made it very performant too. So in professional lingo: The purpose is to access Plasma briefly without switching sessions while retaining Steam Input, QAM, and the Steam overlay.

You’re right that this means KWin is running underneath Gamescope, so it can be less efficient than the direct KWin Desktop Mode session. I’m not claiming it improves performance. It tested acceptably after correcting the resolution/scaling configuration, but I did not run formal compositor benchmarks. Normal Desktop Mode remains the better choice for performance and extended use.

The nested launcher has no runtime effect unless the user explicitly adds and launches it. That said, I’m happy to split Nested Desktop into a separate PR—or remove it from this one—if you would prefer the desktop integration changes independently.

Regarding the SD changes: I agree that the Armada-side checks are no longer necessary now that I have the complete history.

The failure was reproduced on the June 28 image, which predated your July 3 jupiter-hw-support integration. That older image was missing the formatter, automounter, polkit integration, and f3. It also ran the older kernel without CONFIG_UNICODE.

The current source already has the primary native fixes:

jupiter-hw-support is installed in the image.

The kernel package has CONFIG_UNICODE=y.

I can remove the SD build assertions from this PR. I submitted the remaining defense-in-depth formatter change separately in virtudude/armada-packages#3, where the Jupiter RPM is maintained. It makes -O casefold conditional on the running kernel’s advertised support and was successfully built as a complete RPM on the Odin 2.

[JPyke3]

I am a big fan of alot of the changes in this PR! I think we just need to keep the scope of the PRs to one feature at a time as it helps us to validate alot of these changes alot easier

[JPyke3]

Is this one strictly necessary? I believe if you don't check "Force use of a steam Compatibility Tool", this will effectively do the same thing?

If there is a reason why we need this in the compat tool list I am all ears, just not sure why

[Janleyx]

I added it as it didnt work to just disable the compaat tool. It uses the default proton by default but the armada native forces the os to run in linux the app.

[JPyke3]

I feel this one maybe deserves a seperate PR. It doesn't quite live in the scope of Nested Desktop.

I think it's something we do need to consider - we've talked about this a bit. But would prefer to have a seperate forum for it.

[Janleyx]

I agree it was my bad, i did this patch so that when you load up desktop mode you have controller support on desktop, another thing thta should be pre patched would be the desktop controls themselves which i had to manually do for the desktop but i think i could whip up a patch for that too.

[Janleyx]

what i mean to say for clarification, when you run steam on desktop mode the desktop configuration it has for the controller i believe its just gamepad, so no mouse on analog or anything like that is set by default to allow easy access and quality of life you know what i mean.

[JPyke3]

This one may need it's own PR. I actually am a huge fan of the idea - It's just quite difficult to talk about so many features in one PR and have them all merged and tested together, not sure if you could split this one out?

[Janleyx]

Yeah i saw that it wasnt a part of the os and it makes sense since its essentially fedora. I use the steam deck as much as windows since during the day i use my pc and at night i use the steam deck so theres features on the steamos that are a must for this type of device and I feel this is a must.

[Janleyx]

Its a nice quality of life improvement and saves time.

[JPyke3]

I don't believe this needs to live in the README. If merged we can track on issue @ https://github.com/armada-os/armadaos.dev

[Janleyx]

yeah, I'm pretty new on the scene my bad. I love you're os by the way im always testing games on it and building plugins with it in mind. Theres one im working but i feel the os is too early in development for it. Id love to talk to you about it if you ever have some free time.

[Janleyx]

What exactly do you need from me here? need me to divide theese into diferent pr's? the reason i have them all together its because i have them all under one patch.

[JPyke3]

What exactly do you need from me here? need me to divide theese into diferent pr's? the reason i have them all together its because i have them all under one patch.

Yes that's correct. From our perspective we need these features separate to allow for easier testing and review across a very broad set of devices.

Wouldn't have expected you to know this yet, as we have no contribution guide or pr template. We are hoping to fix this soon

Anything that really does belong to nested desktop can stay on this PR