starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

sixel inside tmux and ssh workaround #22172

New Issue
Closed
opened 2026-01-31 08:05:28 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 08:05:28 +00:00
Owner
Copy Link

Originally created by @galchinsky on GitHub (Aug 28, 2024).

Windows Terminal version

1.22.240823002-preview

Windows build number

10.0.22631.4037

Other Software

tmux next 3.5 (latest so far 34807388b064 commit built with --enable-sixel)

Steps to reproduce

In WSL2 tab img2sixel logo.png just works, hurray. It also works if I ssh to a remote server from the WSL2 tab.

Then I start tmux and run the same command. It outputs in a fallback mode

$ img2sixel logo.png
SIXEL IMAGE (12x6)
++++++++++++
++++++++++++
++++++++++++
++++++++++++
++++++++++++

Then I (similarly to a suggestion at https://github.com/wez/wezterm/issues/1236)

  • go to a Windows "Command Prompt" tab
  • ssh to WSL2 from there
  • create tmux session and type "img2sixel logo192.png" .

sixel output starts to work, even on a remote server + tmux combination. This is weird, because if it wasn't so, I would think it's a tmux bug. But now it seems something is off with how WSL2 tab works.

Expected Behavior

sixel output inside tmux

Actual Behavior

tmux outputs

SIXEL IMAGE (12x6)
++++++++++++
++++++++++++
++++++++++++
++++++++++++
++++++++++++

but works correctly if ssh to WSL2 from Windows

Originally created by @galchinsky on GitHub (Aug 28, 2024). ### Windows Terminal version 1.22.240823002-preview ### Windows build number 10.0.22631.4037 ### Other Software tmux next 3.5 (latest so far 34807388b064 commit built with --enable-sixel) ### Steps to reproduce In WSL2 tab `img2sixel logo.png` just works, hurray. It also works if I ssh to a remote server from the WSL2 tab. Then I start tmux and run the same command. It outputs in a fallback mode ``` $ img2sixel logo.png SIXEL IMAGE (12x6) ++++++++++++ ++++++++++++ ++++++++++++ ++++++++++++ ++++++++++++ ``` Then I (similarly to a suggestion at https://github.com/wez/wezterm/issues/1236) * go to a Windows "Command Prompt" tab * ssh to WSL2 from there * create tmux session and type "img2sixel logo192.png" . sixel output starts to work, even on a remote server + tmux combination. This is weird, because if it wasn't so, I would think it's a tmux bug. But now it seems something is off with how WSL2 tab works. ### Expected Behavior sixel output inside tmux ### Actual Behavior tmux outputs SIXEL IMAGE (12x6) ++++++++++++ ++++++++++++ ++++++++++++ ++++++++++++ ++++++++++++ but works correctly if ssh to WSL2 from Windows
claunia added the Issue-BugArea-VTNeeds-Tag-FixProduct-Conpty labels 2026-01-31 08:05:28 +00:00
claunia commented 2026-01-31 08:05:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 28, 2024):

Huh. That's super bizarre. Our best guess right now is that it's the same thing as #17813, but we'll leave this open for now to make sure we check this too. Thanks for filing!

@zadjii-msft commented on GitHub (Aug 28, 2024): Huh. That's super bizarre. Our best guess right now is that it's the same thing as #17813, but we'll leave this open for now to make sure we check this too. Thanks for filing!
claunia commented 2026-01-31 08:05:29 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Aug 29, 2024):

As far I can recall, tmux relies on a TIOCGWINSZ ioctl query to calculate the terminal's cell size, and if it doesn't get back something meaningful, it disables the sixel functionality. I'm not particularly knowledgable about Linux, but my understanding is that it's the responsibility of the terminal to communicate its window size to the OS (also via an ioctl call), and the OS can then pass that on to any apps that query it.

Obviously that's not going to work on Windows because we aren't a Linux app. I'm assuming WSL generates the character dimensions itself by using one of the win32 console APIs to monitor the console buffer size, but it can't know the pixel size, so it leaves those values as 0x0. This is actually not that uncommon a situation, because the pixel fields are not really standard AFAIK, and not all terminals fill them in.

And when it comes to a remote connection to Linux, it's up to ssh to pass the window dimensions to the remote server, but the WSL version of ssh would itself depend on the local TIOCGWINSZ state, so it still won't be able to provide the pixel size.

So why does it work when you ssh from Windows to WSL? That's the bit that was a surprise to me, so I just checked, and it seems that the Windows version of ssh just fakes the pixel dimensions - they're hardcoded to 640x480 regardless of the terminal size. This should be enough to get tmux to work, but I would expect images to be misshapen unless the terminal was exactly 64 columns by 24 rows. I don't have a recent copy of tmux, though, so I haven't actually tested that.

As for fixing this, I don't think there's anything we can do about it. It could be fixed by tmux if they used one of the CSI t queries to determine the cell size (and that would enable them to support a number of other terminals too). It could also possibly be fixed in WSL if they faked the TIOCGWINSZ pixel dimensions (taking the char dimensions and multiplying them by 10x20). That wouldn't work for most third-party terminals though.

@j4james commented on GitHub (Aug 29, 2024): As far I can recall, tmux relies on a `TIOCGWINSZ` ioctl query to calculate the terminal's cell size, and if it doesn't get back something meaningful, it disables the sixel functionality. I'm not particularly knowledgable about Linux, but my understanding is that it's the responsibility of the terminal to communicate its window size to the OS (also via an ioctl call), and the OS can then pass that on to any apps that query it. Obviously that's not going to work on Windows because we aren't a Linux app. I'm assuming WSL generates the character dimensions itself by using one of the win32 console APIs to monitor the console buffer size, but it can't know the pixel size, so it leaves those values as 0x0. This is actually not that uncommon a situation, because the pixel fields are not really standard AFAIK, and not all terminals fill them in. And when it comes to a remote connection to Linux, it's up to ssh to pass the window dimensions to the remote server, but the WSL version of ssh would itself depend on the local `TIOCGWINSZ` state, so it still won't be able to provide the pixel size. So why does it work when you ssh from Windows to WSL? That's the bit that was a surprise to me, so I just checked, and it seems that the Windows version of ssh just fakes the pixel dimensions - they're hardcoded to 640x480 regardless of the terminal size. This should be enough to get tmux to work, but I would expect images to be misshapen unless the terminal was exactly 64 columns by 24 rows. I don't have a recent copy of tmux, though, so I haven't actually tested that. As for fixing this, I don't think there's anything we can do about it. It could be fixed by tmux if they used one of the `CSI t` queries to determine the cell size (and that would enable them to support a number of other terminals too). It could also possibly be fixed in WSL if they faked the `TIOCGWINSZ` pixel dimensions (taking the char dimensions and multiplying them by 10x20). That wouldn't work for most third-party terminals though.
claunia commented 2026-01-31 08:05:30 +00:00
Author
Owner
Copy Link

@galchinsky commented on GitHub (Aug 29, 2024):

but I would expect images to be misshapen unless the terminal was exactly 64 columns by 24 row

That's true: if the window size is larger than ~24 rows, there is a big black area.

Also, if I fake xpixel and ypixel values in tmux/tty.c tty_resize function, sixel starts to work and it does query TIOCGWINSZ, so TIOCGWINSZ problem confirmed.

tmux-small-and-big-window

@galchinsky commented on GitHub (Aug 29, 2024): > but I would expect images to be misshapen unless the terminal was exactly 64 columns by 24 row That's true: if the window size is larger than ~24 rows, there is a big black area. Also, if I fake xpixel and ypixel values in `tmux/tty.c` `tty_resize` function, sixel starts to work and it does query TIOCGWINSZ, so TIOCGWINSZ problem confirmed. ![tmux-small-and-big-window](https://github.com/user-attachments/assets/e22bd888-3f2a-47b8-8a08-7436c32ab654)
claunia commented 2026-01-31 08:05:30 +00:00
Author
Owner
Copy Link

@galchinsky commented on GitHub (Sep 30, 2024):

Closing this as the patch suggested by @j4james in the last comment here was accepted to tmux (89adec0ca5)
I tested on 1.22.240823002-preview and the 25b1cc1e8e tmux build from github

@galchinsky commented on GitHub (Sep 30, 2024): Closing this as the patch suggested by @j4james in the last comment here was accepted to tmux ([89adec0ca5](https://github.com/tmux/tmux/commit/89adec0ca5f3cf7510b3854967b33b399871da7e)) I tested on 1.22.240823002-preview and the 25b1cc1e8e tmux build from github
claunia commented 2026-01-31 08:05:30 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Oct 1, 2024):

@galchinsky Thank you for doing the work to get this fixed in tmux. It's much appreciated.

@j4james commented on GitHub (Oct 1, 2024): @galchinsky Thank you for doing the work to get this fixed in tmux. It's much appreciated.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT Issue-Bug Needs-Tag-Fix Product-Conpty
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#22172
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?