pty: forward client pixel size (ws_xpixel/ws_ypixel) from window size messages - #1560
Open
ViktorBarzin wants to merge 1 commit into
Open
pty: forward client pixel size (ws_xpixel/ws_ypixel) from window size messages#1560ViktorBarzin wants to merge 1 commit into
ViktorBarzin wants to merge 1 commit into
Conversation
… messages Programs that query the terminal's pixel dimensions via TIOCGWINSZ currently always see 0x0 under ttyd, because the winsize passed to forkpty()/TIOCSWINSZ hard-codes ws_xpixel/ws_ypixel to 0. The most visible casualty is sixel graphics under tmux: tmux (>= 3.4, built with sixel) refuses to scale and re-emit sixel images to a client whose tty reports a zero pixel size (tty.c: tty_cmd_sixelimage falls back to the "SIXEL IMAGE (WxH)" text placeholder), so image tools like viu or img2sixel show placeholders inside tmux even when the browser terminal renders sixel natively. Accept optional "xpixel"/"ypixel" fields in the initial JSON handshake and in RESIZE_TERMINAL messages, and carry them into the pty's winsize on spawn and resize. Clients that don't send the fields get exactly the previous behavior (0x0). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Problem
Programs that query the terminal's pixel dimensions via
TIOCGWINSZalways see0x0under ttyd: thewinsizepassed toforkpty()/TIOCSWINSZhard-codesws_xpixel/ws_ypixelto 0.The most visible casualty is sixel graphics under tmux. tmux (≥ 3.4, built with sixel) stores images emitted by pane programs, but refuses to scale and re-emit them to a client whose tty reports a zero pixel size —
tty.c: tty_cmd_sixelimagefalls back to theSIXEL IMAGE (WxH)text placeholder. So image tools (viu, img2sixel, matplotlib sixel backends) show placeholders inside tmux under ttyd, even when the frontend (e.g. xterm.js with@xterm/addon-image) renders sixel natively.Change
Accept optional
xpixel/ypixelfields in the initial JSON handshake and inRESIZE_TERMINALmessages, and carry them into the pty'swinsizeon spawn and resize.0x0).ResizePseudoConsolehas no pixel concept).Testing
Verified end-to-end against tmux 3.4 (sixel-enabled) with an xterm.js 5.5 +
@xterm/addon-imagefrontend sending real cell metrics: with the fields present, tmux re-emits sixel and real images render through tmux in the browser (first paint, after resizes, and across reconnects); without them, behavior is byte-identical to current master. Happy to extend the bundled html client to send these fields in a follow-up if you're open to it.🤖 Generated with Claude Code