tabby
tabby copied to clipboard
Eugeny
Sixel not working for wsl?
Discussed in https://github.com/Eugeny/tabby/discussions/6987
Originally posted by benhaotang August 16, 2022
problem
I have enabled sixel support in settings, but lsix and viu in ubuntu-wsl2 still reports that "Error: Your terminal does not report having sixel graphics support.", I open this directly from the local distro tab.
I am using tabby 183 on win11 with ubuntu-wsl2, can confirm that lsix work on x11 xterm and wsltty. I also can confirm that through ssh, sixel works for tabby on remote sessions.
how to solve this? is there any setting that I have done wrong? is there some problems for wsl?
All I could think of is that since Tabby just routes through the particular WSL terminal, that Sixel is turned off on the WSL terminal side of things. I couldn't tell you how to turn that on though and it probably depends on which distro you're using. A quick Google tells me that Ubuntu doesn't support Sixel graphics without installing additional programs, but there's tools like FIM offer such functionality, see also https://net2.com/how-to-display-images-in-the-command-line-in-linux-ubuntu/
Sorry if that doesn't help you!
net2
Updated on 5/5/2022- For users who work with the command line in Linux most of the time, it could be convenient to view images within their terminal
All I could think of is that since Tabby just routes through the particular WSL terminal, that Sixel is turned off on the WSL terminal side of things. I couldn't tell you how to turn that on though and it probably depends on which distro you're using. A quick Google tells me that Ubuntu doesn't support Sixel graphics without installing additional programs, but there's tools like FIM offer such functionality, see also https://net2.com/how-to-display-images-in-the-command-line-in-linux-ubuntu/
Sorry if that doesn't help you!
net2**How to display Images in the command line in Linux/Ubuntu**Updated on 5/5/2022- For users who work with the command line in Linux most of the time, it could be convenient to view images within their terminal
well, xterm and wsltty works fine, I think this is not the sixel support problem. But https://github.com/Eugeny/tabby/discussions/6987 here he points out that may be related to the windows conhost when routing output, I think this maybe more close to the truth. But still, thanks for your detailed answer.
Updated on 5/5/2022- For users who work with the command line in Linux most of the time, it could be convenient to view images within their terminal
https://github.com/Eugeny/tabby/discussions/6987#discussioncomment-3411063 I think it's Windows console host's fault. Currently Tabby uses conhost as a middle layer. The conhost works like screen/tmux, the command line program output to conhost, then conhost update it's "screen" and output changed parts of the screen to terminal. So if conhost doesn't understand something, it would just ignore.
Some months ago I created a similar issue #5453. We need a way to bypass Windows' console host, talking directly to the "real TTY". Conhost exists only for compatibility, since there's lots of Win32 cli programs still use Win32's console API, the conhost act as a compatibility layer to translate them to VT sequence.
#6987 (reply in thread) I think it's Windows console host's fault. Currently Tabby uses conhost as a middle layer. The conhost works like screen/tmux, the command line program output to conhost, then conhost update it's "screen" and output changed parts of the screen to terminal. So if conhost doesn't understand something, it would just ignore.
Some months ago I created a similar issue #5453. We need a way to bypass Windows' console host, talking directly to the "real TTY". Conhost exists only for compatibility, since there's lots of Win32 cli programs still use Win32's console API, the conhost act as a compatibility layer to translate them to VT sequence.
I'm not sure I know of a method to directly communicate with the real/native TTY through WSL, let alone then also porting that through Tabby, seems like a massive undertaking if you ask me. Could be worth the trouble maybe but I'm not sure. I'm also not an expert when it comes to this type-a stuff though.
The problem with SIXEL and windows is ConPty. The way they shaped it internally cuts most wsl applications from higher features of the POSIX terminal interface. (Background: ConPty basically acts like a multiplexer mangling escape sequences through their terminal buffer, which is mostly inspired from old windows console API for compat reasons. The windows terminal devs already admitted that it was not a good idea to do it that way, thus there is some discussion about a TTY passthrough mode. Recently there was some progression in that field.) You can read more about that here https://github.com/microsoft/terminal/issues/448.
I'm not sure I know of a method to directly communicate with the real/native TTY through WSL
Back in WSL1 there was a tiny binary for bridging raw file descriptors through to windows via named pipes. This could be used to fake a full pty interface by forwarding the master fd (+adding some control shims). But this comes to a price - ConPty mainly exists to guarantee interop between windows and linux cmdline apps (IO streams are visable/understood on both ends) - with directly hooking into WSL pipes you'd lose windows app compat (not a big deal if you ask me, but understandable that MS thinks here otherwise). Since I left windows+WSL dev before WSL2 took part, I cannot tell, whether such a pipe shim is still easy possible with WSL2.
