docs(h264): reconnect-blank is two stacked mstsc bugs (full xrdp mirror tried) - #9
Merged
Merged
Conversation
…or tried)
Corrects + supersedes the earlier "all three server-side avenues dead / mstsc
disconnect is always abrupt" conclusion. Re-opened because xrdp+mstsc reconnects
in-process cleanly, proving a server-side fix can work.
Findings: mstsc's connection-bar X (close, keep process) is a GRACEFUL disconnect
that arrives as an io-channel Shutdown Request ("Got disconnect request"); the
client loop exits Ok(RunState::Disconnect) with the socket still alive — so the
disconnect hook IS reachable (the earlier Broken-pipe was the 60fps frame-write
losing the select! race, not inherent). We then sent DELETE_SURFACE(all) + a
DYNVC_CLOSE of the Graphics channel there, fully mirroring xrdp's shutdown_full.
Result on real mstsc: symptom changed but didn't resolve — delete-only → still
black; delete + DYNVC_CLOSE → TRANSPARENT (client's local desktop shows through).
So the blank is TWO stacked mstsc bugs: (1) black = retains surface 0 across the
drop (channel-close FIXES this) and (2) transparent = won't re-composite a fresh
output surface on in-process reconnect (NOT server-fixable; xrdp gets past it via
its persistent-X-session reconnect architecture). DECISION: stop, documented
client limitation, recovery = close+reopen mstsc. Do not re-attempt unless layer
2 (reconnect re-composite) is cracked. Docs-only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Corrects + supersedes the earlier "all three server-side avenues dead / mstsc disconnect is always abrupt" note. Re-opened because xrdp+mstsc reconnects in-process cleanly, proving a server-side fix can work.
Findings: mstsc's connection-bar X (close, keep process) is a graceful disconnect arriving as an io-channel Shutdown Request — the client loop exits
Ok(RunState::Disconnect)with the socket still alive, so the disconnect hook IS reachable. (The earlierBroken pipewas the 60fps frame-write losing theselect!race, not inherent.) We then sentDELETE_SURFACE(all)+ aDYNVC_CLOSEof the Graphics channel there — fully mirroring xrdp'sshutdown_full.Result on real mstsc: symptom changed but didn't resolve — delete-only → still black; delete + DYNVC_CLOSE → transparent (client's local desktop shows through, non-interactive). So the blank is two stacked mstsc bugs:
Decision: stop — documented mstsc client limitation; recovery stays close+reopen mstsc (fresh process, neither layer's state). FreeRDP/Thincast unaffected. Do not re-attempt unless layer 2 (reconnect re-composite) is cracked. Docs-only.