Better remote capture on Linux targets.

[zhangzhousuper]

Problem / Use case

Description of Feature

I would like RenderDoc to provide a first-class, out-of-box workflow for remote
capture and remote-backed replay on Linux/embedded targets.

Today the underlying pieces exist (remote server, remote replay, capture
retrieval), but the end-to-end workflow is still very manual for non-local targets.
In practice, users often need external scripting to:

• start and manage renderdoccmd remoteserver on the target
• set target-specific runtime environment before launch
• launch/inject the target application remotely
• wait for the target-control connection
• trigger capture
• decide whether to copy the capture back locally or keep replay remote-backed
• poll status during long upload/open steps
• interpret failures when the remote side is busy, slow, or partially initialized

This makes remote capture workable for experts, but not really out-of-box for
normal users.

What I am asking for is not FPGA-specific support. FPGA is only one example of a
broader class of remote targets: Linux, embedded, headless, or lab machines where
capture/replay must happen remotely.

Desired workflow

Ideally RenderDoc should support a single coherent remote workflow that can:

1. connect to a remote target (host[:port])
2. optionally start/manage the remote server
3. remotely launch/inject the target
4. trigger capture
5. either:
   • copy the capture back locally as a normal .rdc, or
   • keep the session remote-backed for analysis
6. report clear progress/state for long-running steps such as upload/open
7. surface actionable errors instead of generic "not loaded" style failures

Why this matters

The current workflow gap is not in basic capability, but in productization and UX:

• remote setup is manual
• session state during long remote operations is unclear
• local-vs-remote replay choice is left to the user
• recovery from transient remote failures is not first-class

A more integrated remote workflow would benefit any remote Linux/embedded debugging
setup, not just one specific board or vendor environment.

Environment

• RenderDoc version: 1.43
• Operating System: Linux host + Linux remote target
• Graphics API: Vulkan

Proposed solution

No response

Alternatives considered

No response

[BANANASJIM]

Phase 9 has landed (PRs #214 + #215 + #223)

6 of the 7 pain points in this issue are now resolved. End-to-end verification against your original post:

Your pain point	Resolution	Where
"start and manage renderdoccmd remoteserver on the target"	rdc remote setup HOST:PORT — verify-only + actionable hint on failure (e.g. "hint: rdc serve does not appear to be running on localhost:39920. On the target, run: rdc serve --daemon --port 39920") plus rdc remote status / rdc remote disconnect	PR #215
"wait for the target-control connection"	run_target_control_loop now prints "waiting for capture... (Ns)" on stderr every 5s	PR #214
"poll status during long upload/open steps"	Progress callback wired into CopyCaptureToRemote / CopyCaptureFromRemote / OpenCapture with tty/non-tty handling	PR #214
"interpret failures when the remote side is busy, slow, or partially initialized"	(a) 8 hint injection points with -- hint: <actionable suggestion> suffix. (b) _load_remote_replay failures now name which step failed (e.g. "remote replay setup failed at step 'match gpu' (RuntimeError): <msg>") instead of opaque Exception	PR #223
"decide whether to copy the capture back locally or keep replay remote-backed"	Existing --keep-remote / --proxy flags now surfaced via hint when OpenCapture fails locally: "hint: try 'rdc open --proxy HOST:PORT'"	PR #223 (builds on Phase 6/7)
'generic "not loaded" style failures'	Opaque except Exception broad catches split into per-step narrow catches with step labels and exception type name; outer except Exception preserved as safety net	PR #223
"1 command to bootstrap the remote serve" (implied — auto-start via SSH)	Deferred to Phase 9.1 as rdc remote setup --start-via ssh. Reason: RenderDoc upstream GetDeviceProtocolController only supports "adb", there is no PC-to-PC Device Protocol we can piggyback on; SSH wrapping has enough edge cases (exit-255 classification, Windows OpenSSH, auth prompts, env propagation) that we want real-world feedback on the verify-only variant first before investing	PR #223 does not include this

Give the new workflow a try — the most visible change for a Linux-to-Linux remote debug loop is:

# on the target (was always required, now explicitly surfaced by setup hint)
rdc serve --daemon --port 39920

# on the host (new entrypoint)
rdc remote setup 192.168.1.10:39920
rdc remote capture 192.168.1.10:39920 --app /path/to/app -o cap.rdc
rdc open cap.rdc   # or --proxy 192.168.1.10:39920 for remote-backed replay

Feedback welcome on remaining pain points, especially whether --start-via ssh is worth the complexity tax or whether the current "copy-pasteable hint command" suffices in practice. Keeping this issue open pending your confirmation, then we'll track 9.1 separately.

Thanks for the detailed writeup — that pain-point framing drove the whole Phase 9 design.