chore(decky): bump submodule to v1.2.0

[lobinuxsoft]

Summary

Bumps the Decky plugin submodule from v1.1.0 to v1.2.0.

The v1.2.0 release fixes the long-standing boot-time mDNS bug (agent invisible to the Hub until the user manually toggled the plugin off/on) and adds an event-driven lifecycle with toast notifications for every state transition.

Closes lobinuxsoft/decky-capydeploy#28
Closes lobinuxsoft/decky-capydeploy#29

What v1.2.0 brings

• fix(mdns): wait for network at boot and re-register on IP change
• feat(mdns): event-driven lifecycle callbacks (register / unregister / waiting)
• feat(ui): toast notifications for mDNS transitions ("Waiting for network…" / "CapyDeploy ready · Listening at :")
• fix(mdns): re-register after network recovery (suspend/wake)

Full release notes: https://github.com/lobinuxsoft/decky-capydeploy/releases/tag/v1.2.0

Test plan

• Verified on a real Steam Deck across cold boots, suspend/wake cycles, and AP changes
• Hub auto-reconnects via mDNS ServiceUpdated in ~2.7s after network recovery
• CI: monorepo workflows run with the new submodule SHA

[kergoth]

For what it's worth, as a user, I verified the mdns fixes solve the issue for me on my Deck too. Very nice improvement to usability.

[lobinuxsoft]

Hi @kergoth, that's great news — thank you for testing on your own Deck. Independent confirmation on different hardware is exactly what this needed. If you run into any other quirks down the road, please don't hesitate to flag them; I'd much rather hear about a rough edge than have it silently affect your workflow.

A couple of things I wanted to check in on:

Mac support — I saw you've been working on Mac in your fork. I'd love to see where it's heading. If you'd like to open a PR with what you have, I'm up for reviewing and merging it. One caveat: if it ends up needing an Apple Developer account to build or sign, we should probably skip that route 😅 — happy to figure out alternatives if it comes up.

The RPCS3 launcher pattern — did you make further progress on the emulator deployment experiment you described earlier? It's a clever use case and I'd love to document or even add first-class support for it. My only hesitation is whether automating that flow might attract attention from Sony — I'd rather keep the plugin sustainable than risk it. Curious about your read.

Last ask — would you be willing to drop a quick line in decky-plugin-database PR #984 confirming the test you ran here? A user-side testing report there would help unblock the review cycle a lot — even just a sentence pointing back to this comment would be perfect.

Thanks again — your feedback has been one of the most useful things to happen to this project in a while.

[kergoth]

Hi @kergoth, that's great news — thank you for testing on your own Deck. Independent confirmation on different hardware is exactly what this needed. If you run into any other quirks down the road, please don't hesitate to flag them; I'd much rather hear about a rough edge than have it silently affect your workflow.

Will do. This is the best tool I've found for putting decomps/recomps/pc ports onto the Steam Deck, as well as other self-contained games like freeware and free itch.io games. Prior approaches were rsync + steamtinkerlaunch based. Other candidates I considered were creating a custom store in Junk-Store 2.0/3.0 to browse and install them from the Steam Deck rather than the host (still considering it, but for the future, as it's a larger effort). I'm loving CapyDeploy so far.

A couple of things I wanted to check in on:

Mac support — I saw you've been working on Mac in your fork. I'd love to see where it's heading. If you'd like to open a PR with what you have, I'm up for reviewing and merging it. One caveat: if it ends up needing an Apple Developer account to build or sign, we should probably skip that route 😅 — happy to figure out alternatives if it comes up.

My current approach is hacky and not well incorporated, but I do intend to clean it up, improve integration, and submit a PR, even if it's unsigned to start with.

The RPCS3 launcher pattern — did you make further progress on the emulator deployment experiment you described earlier? It's a clever use case and I'd love to document or even add first-class support for it. My only hesitation is whether automating that flow might attract attention from Sony — I'd rather keep the plugin sustainable than risk it. Curious about your read.

I'm using it today, works great. Whether it's worth using as an example would be your call. It's certainly a slightly unusual use case. Currently I have a launcher script that lives next to the pkg/rap files which does:

1. Ensures that the PS3 bios is installed into RPCS3 if it hasn't been already.
2. Opens RPCS3 to install all pkg/rap files in the game folder.
3. Verifies the title successfully installed to the RPCS3 hard disk.
4. Additionally installs .desktop files to the ps3 folders of an EmuDeck/RetroDeck install, to allow them to be playable from Emulation Station Desktop Edition rather than solely via the non-steam launcher in Steam.

Last ask — would you be willing to drop a quick line in decky-plugin-database PR #984 confirming the test you ran here? A user-side testing report there would help unblock the review cycle a lot — even just a sentence pointing back to this comment would be perfect.

Will do.

[lobinuxsoft]

Will do. This is the best tool I've found for putting decomps/recomps/pc ports onto the Steam Deck, as well as other self-contained games like freeware and free itch.io games. Prior approaches were rsync + steamtinkerlaunch based... I'm loving CapyDeploy so far.

Thank you, that genuinely means a lot. The more people use it that way the better — CapyDeploy was conceived exactly for that crowd: dev workflows for PC port / decomp authors, DRM-free libraries, itch.io grabs, anything self-contained that Steam treats as a second-class citizen. Hearing it lands the way it was designed to is the best feedback I could ask for, and helps the project become more visible.

My current approach is hacky and not well incorporated, but I do intend to clean it up, improve integration, and submit a PR, even if it's unsigned to start with.

Sounds great. To be transparent: I don't own any Mac hardware, so I genuinely can't validate Mac builds locally — your contribution would be the only realistic path forward for first-class Mac support in this project. Don't worry about the unsigned start either; we can iterate on signing/notarization later if/when that becomes worth solving. Really looking forward to the PR whenever you have it in shape.

I'm using it today, works great. Whether it's worth using as an example would be your call. It's certainly a slightly unusual use case. Currently I have a launcher script that lives next to the pkg/rap files which does:

1. Ensures that the PS3 bios is installed into RPCS3 if it hasn't been already.
2. Opens RPCS3 to install all pkg/rap files in the game folder.
3. Verifies the title successfully installed to the RPCS3 hard disk.
4. Additionally installs .desktop files to the ps3 folders of an EmuDeck/RetroDeck install, to allow them to be playable from Emulation Station Desktop Edition rather than solely via the non-steam launcher in Steam.

I'm a strong believer in game preservation, so I'm not going to pretend to have reservations there — if you'd like to send a PR with your progress (the launcher script pattern, the EmuDeck/RetroDeck .desktop integration, any of it) it's absolutely welcome. Worth documenting properly so others can build on it.

Will do.

Much appreciated. That comment on #984 will probably make the difference for getting the store-side review cycle moving again.