Support TIOCGWINSZ

[amarshall]

Environment: Darwin i386, tmux 2.7, xterm-kitty (outside tmux), screen (inside tmux), empty config

Use case is that kitty’s icat, which allows showing images in the terminal, requires support for ioctl’s TIOCGWINSZ. See also kovidgoyal/kitty#413.

Reproduction steps:

1. Use kitty as terminal emulator
2. Create some valid image file (e.g. cat.jpg)
3. Start tmux
4. In tmux, kitty +kitten icat cat.jpg
5. Expect an image to be displayed, but instead get error:

   Terminal does not support reporting screen sizes via the TIOCGWINSZ ioctl

[nicm]

tmux is not responsible for supporting this ioctl. If it is was actually missing you would need to speak to your kernel developers. More likely the error message is wrong and in fact something else is failing.

…

On Tue, 3 Jul 2018, 18:51 Andrew Marshall, ***@***.***> wrote: Environment: Darwin i386, tmux 2.7, xterm-kitty (outside tmux), screen (inside tmux), empty config Use case is that kitty <https://sw.kovidgoyal.net/kitty/>’s icat <https://sw.kovidgoyal.net/kitty/kittens/icat.html>, which allows showing images in the terminal, requires support for ioctl’s TIOCGWINSZ. See also kovidgoyal/kitty#413 <kovidgoyal/kitty#413>. Reproduction steps: 1. Use kitty <https://sw.kovidgoyal.net/kitty/> as terminal emulator 2. Create some valid image file (e.g. cat.jpg) 3. Start tmux 4. In tmux, kitty +kitten icat cat.jpg 5. Expect an image to be displayed, but instead get error: Terminal does not support reporting screen sizes via the TIOCGWINSZ ioctl — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1391>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASkc1r-nEQcYzjDewETo-5KyoVBBqcaks5uC68WgaJpZM4VBYZy> .

[amarshall]

Hmm… though it works as expected (sans error) outside of tmux. And I get the same behavior on Ubuntu 18.04 (Linux x86_64, tmux 2.6, identical $TERM, empty config).

I suppose, then, you believe it’s an issue with kitty, rather than tmux? (Unfortunately, the kitty dev states the opposite.)

[krader1961]

See https://sw.kovidgoyal.net/kitty/graphics-protocol.html for the documentation about how icat works.

The TIOCGWINSZ ioctl works fine on macOS inside and outside of tmux. It is the case, however, that tmux apparently only propagates the row and col attributes not the x and y pixel attributes. That could be changed but would have some limitations; see next paragraph.

The problem is how would this interact with the screen layout managed by tmux? Should tmux just set the pixel dimensions of each pane to the total size reported by the terminal? Should tmux do some math to calculate the size in pixels of each pane as @kovidgoyal states? That implies that tmux would have to inspect the "terminal graphics protocol" data to correctly adjust the image offset relative to the location of the pane. Pretty sure that will never happen. So taking the simple approach which leaves tmux completely unaware of this kitty mechanism for embedding images in the terminal means that if you have multiple panes it wouldn't matter in which pane you ran icat. It would always behave as if tmux wasn't present.

[krader1961]

Also, scrolling controlled by tmux would not be compatible with the icat mechanism. And in general there would be no way to make it compatible. So that's another limitation.

[nicm]

tmux is not going to support the escape sequence so it seems pointless to support xpixel and ypixel.

[krader1961]

@nicm I agree that it seems pointless to support xpixel and ypixel. Even if the kitty protocol for embedding images in an otherwise text based terminal was adopted by other terminals it does not make sense for tmux to support it. Not least because of the issues having to do with such support as I documented in my previous comment.

@amarshall What are your expectations with regard to executing icat inside a tmux pane? If it is anything other than to behave as if the tmux pane covered the entire terminal window then you have not considered the ramifications of your request.

[nicm]

I don't object to supporting it if someone wants to do it, it would be easy enough to work out pixels-per-cell and use that to fill in xpixel and ypixel. But it won't particularly help so I'm not going to rush to do it myself.

[nicm]

Actually, there is no realistic way for tmux to fill these in, because pixels/cell may vary for different terminals. If the same session is attached to two or more terminals, which value should tmux use? So I don't think we can do this.

[kovidgoyal]

Since, I was at-mentioned, I'll just address all the various issues mentioned here:

1. tmux already handles the IOCTL, it just neglects to fill in the pixel size parts, setting them, incorrectly to zero.

2. tmux can calculate the values and fill them in. It should use the values from whatever the controlling terminal is. I dont know if tmux allows multiple controlling terminals, if it does it can simply pick the first.

3. tmux already intercepts various escape codes and rewrites them (it has to do that for example, for cursor positioning escape codes), so it would need to do the same for the graphics ones to reposition the images based on the geometry it reports.

Of course whether the tmux maintainers are willing to do that work or not, is a whole other question.

Oh and just incidentally, there already exist escape codes to query screen size in pixels, <ESC>[14t tmux apparently parses it and filters it out, instead of passing on the response from the terminal.

[nicm]

No this doesn't make sense for tmux to do.

…

On Sun, 8 Jul 2018, 08:04 Kovid Goyal, ***@***.***> wrote: Since, I was at-mentioned, I'll just address all the various issues mentioned here: 1. tmux already handles the IOCTL, it just neglects to fill in the pixel size parts, setting them, incorrectly to zero. 2. tmux can calculate the values and fill them in. It should use the values from whatever the controlling terminal is. I dont know if tmux allows multiple controlling terminals, if it does it can simply pick the first. 3. tmux already intercepts various escape codes and rewrites them (it has to do that for example, for cursor positioning escape codes), so it would need to do the same for the graphics ones to reposition the images based on the geometry it reports. Of course whether the tmux maintainers are willing to do that work or not, is a whole other question. Oh and just incidentally, there already exist escape codes to query screen size in pixels, [14t tmux apparently parses it and filters it out, instead of passing on the response from the terminal. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1391 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASkc4-hPDFfiqYS2n5lLSZUNLy5yy8Cks5uEa8bgaJpZM4VBYZy> .

[watersb]

sorry if flogging an old thread, but I am working on similar tools at the moment.

FWIW the Terminal in Visual Studio Code responds to TIOCGWINSZ the same way, I believe.

@_exported import Darwin.C


var ws = winsize()

if ( ioctl(1, UInt(TIOCGWINSZ), &ws) != -1 ) {
    let width  = Int(ws.ws_col)
    let widpx  = Int(ws.ws_xpixel)
    
    let height = Int(ws.ws_row)
    let hghtpx = Int(ws.ws_ypixel)
    
    print( "w,h :  \(width),\t\(height)" )
    print( "x,y :  \(widpx),\t\(hghtpx)" )
}

getWS.swift.txt

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.