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

Neither TIOCGWINSZ nor 14t allow introspection of the window size in pixels #11799

New Issue
Open
opened 2026-01-31 02:57:49 +00:00 by claunia · 16 comments
claunia commented 2026-01-31 02:57:49 +00:00
Owner
Copy Link

Originally created by @csdvrx on GitHub (Dec 14, 2020).

Environment

Windows 10 Pro 20H2 (amd64)

Latest Windows Terminal Preview, running either msys2 or wsl

Steps to reproduce

compile and run the following code

#include <sys/ioctl.h>
#include <stdio.h>

int main (void)
{
    struct winsize ws;
    ioctl(1, TIOCGWINSZ, &ws);
    printf("rows: %d cols: %d xpixel: %d ypixel: %d\n", ws.ws_row, ws.ws_col, ws.ws_xpixel, ws.ws_ypixel);
}

Separately, send the xterm 14t sequence as documented in https://www.xfree86.org/current/ctlseqs.html :

 P s = 1 4 → Report xterm window in pixels as CSI 4 ; height ; width t

You can do that from a shell with:

echo -en "\033[14t\033\\"

Expected behavior

Both should work and return identical non 0 values

On mintty for example:

$ /d/wingetsize.exe
rows: 27 cols: 88 xpixel: 1056 ypixel: 729

This means the terminal is 729x1056

On wsltty running debian (WSL) for example:

$ echo -en "\033[14t\033\\"
^[[4;480;880t

This means the terminal is 880x480

Actual behavior

On a Windows Terminal running msys2:

$ /d/wingetsize.exe
rows: 25 cols: 98 xpixel: 0 ypixel: 0

The problem is not related to msys2 but purely Windows Terminal, as the above was obtained on a Windows Terminal running the exact same binaries and bash environment.

The absence of msys2 doesn't help: on a Windows Terminal running an official debian image (WSL) :

$ /mnt/d/wingetsize
rows: 21 cols: 84 xpixel: 0 ypixel: 0

To ignore any API issues, you can also try to send the specific xterm control sequence that should return the window size in pixels, and notice it returns nothing.

$ echo -en "\033[14t\033\\"

This properly returns the size on wsltty running debian-slim in WSL, so the problem is not related to WSL either:

wsltty-example

This issue may be related to #3718 (querying the colors via OSC) if you only consider the xterm control sequence. However the 0 values in TIOCGWINSZ is a tty ioctl, making this a wider problem, so I believe this is a separate issue.

At least one of these methods should work: introspection is required by some software to adjust their rendering to the actual space available on the terminal.

The absence of TIOCGWINSZ also impacts issue #448, as explained more precisely in https://github.com/microsoft/Terminal/issues/448#issuecomment-639003989 and illustrated in https://github.com/microsoft/Terminal/issues/448#issuecomment-707765406 : the screen size, along with the number of row and columns would allow inferring the font size, to avoid sixel images being stretched, squizzed, or a fraction of the correct size by sending them to the right size (in pixels) for their placeholder (in characters)

Originally created by @csdvrx on GitHub (Dec 14, 2020). # Environment Windows 10 Pro 20H2 (amd64) Latest Windows Terminal Preview, running either msys2 or wsl # Steps to reproduce compile and run the following code ``` #include <sys/ioctl.h> #include <stdio.h> int main (void) { struct winsize ws; ioctl(1, TIOCGWINSZ, &ws); printf("rows: %d cols: %d xpixel: %d ypixel: %d\n", ws.ws_row, ws.ws_col, ws.ws_xpixel, ws.ws_ypixel); } ``` Separately, send the xterm 14t sequence as documented in https://www.xfree86.org/current/ctlseqs.html : ``` P s = 1 4 → Report xterm window in pixels as CSI 4 ; height ; width t ``` You can do that from a shell with: ``` echo -en "\033[14t\033\\" ``` # Expected behavior Both should work and return identical non 0 values On mintty for example: ``` $ /d/wingetsize.exe rows: 27 cols: 88 xpixel: 1056 ypixel: 729 ``` This means the terminal is 729x1056 On wsltty running debian (WSL) for example: ``` $ echo -en "\033[14t\033\\" ^[[4;480;880t ``` This means the terminal is 880x480 # Actual behavior On a Windows Terminal running msys2: ``` $ /d/wingetsize.exe rows: 25 cols: 98 xpixel: 0 ypixel: 0 ``` The problem is not related to msys2 but purely Windows Terminal, as the above was obtained on a Windows Terminal running the exact same binaries and bash environment. The absence of msys2 doesn't help: on a Windows Terminal running an official debian image (WSL) : ``` $ /mnt/d/wingetsize rows: 21 cols: 84 xpixel: 0 ypixel: 0 ``` To ignore any API issues, you can also try to send the specific xterm control sequence that should return the window size in pixels, and notice it returns nothing. ``` $ echo -en "\033[14t\033\\" ``` This properly returns the size on wsltty running debian-slim in WSL, so the problem is not related to WSL either: <img width="224" alt="wsltty-example" src="https://user-images.githubusercontent.com/49044530/102041519-4ad7a500-3d95-11eb-8aaf-ddd770dbbcb1.png"> This issue may be related to #3718 (querying the colors via OSC) if you only consider the xterm control sequence. However the 0 values in TIOCGWINSZ is a tty ioctl, making this a wider problem, so I believe this is a separate issue. At least one of these methods should work: introspection is required by some software to adjust their rendering to the actual space available on the terminal. The absence of TIOCGWINSZ also impacts issue #448, as explained more precisely in https://github.com/microsoft/Terminal/issues/448#issuecomment-639003989 and illustrated in https://github.com/microsoft/Terminal/issues/448#issuecomment-707765406 : the screen size, along with the number of row and columns would allow inferring the font size, to avoid sixel images being stretched, squizzed, or a fraction of the correct size by sending them to the right size (in pixels) for their placeholder (in characters)
claunia added the Product-ConhostArea-VTProduct-TerminalArea-ServerIssue-Scenario labels 2026-01-31 02:57:50 +00:00
claunia commented 2026-01-31 02:57:50 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Dec 14, 2020):

Related: #5094

@skyline75489 commented on GitHub (Dec 14, 2020): Related: #5094
claunia commented 2026-01-31 02:57:50 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 14, 2020):

This is likely complicated by the fact that the Windows console subsystem does not and has never tried to support TTY IOCTLs. None of those requests ever reach Terminal because they’re shimmed out by whatever application compatibility layer you’re using to actually dispatch a TIOC... ioctl.

@DHowett commented on GitHub (Dec 14, 2020): This is likely complicated by the fact that the Windows console subsystem does not and _has never tried to_ support TTY IOCTLs. None of those requests ever reach Terminal because they’re shimmed out by whatever application compatibility layer you’re using to actually dispatch a `TIOC...` ioctl.
claunia commented 2026-01-31 02:57:51 +00:00
Author
Owner
Copy Link

@csdvrx commented on GitHub (Dec 15, 2020):

(oops, I accidentally hit Close instead of Comment, I'm not sure how to undo that, so I'm reopening the issue)

Related: #5094

@skyline75489 maybe exposing information to userland applications (as you must already keep track of the size of the window size somewhere :-) to let them adjust their behavior will be easier than controlling the terminal?

None of those requests ever reach Terminal because they’re shimmed out by whatever application compatibility layer you’re using

Then what about simply replying to OSC 14?

It's be nice to have TIOCGWINSZ , as several applications already use that (ex: tmux) but anything at all will be better than nothing :)

@csdvrx commented on GitHub (Dec 15, 2020): (oops, I accidentally hit Close instead of Comment, I'm not sure how to undo that, so I'm reopening the issue) > Related: #5094 @skyline75489 maybe exposing information to userland applications (as you must already keep track of the size of the window size somewhere :-) to let them adjust their behavior will be easier than controlling the terminal? > None of those requests ever reach Terminal because they’re shimmed out by whatever application compatibility layer you’re using Then what about simply replying to OSC 14? It's be nice to have TIOCGWINSZ , as several applications already use that (ex: tmux) but anything at all will be better than nothing :)
claunia commented 2026-01-31 02:57:51 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Dec 15, 2020):

I think @j4james might have more insights on this one.

And It's CSI 14t, right? Not OSC.

@skyline75489 commented on GitHub (Dec 15, 2020): I think @j4james might have more insights on this one. And It's `CSI 14t`, right? Not `OSC`.
claunia commented 2026-01-31 02:57:51 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 15, 2020):

I don't think it's worth considering until we have a genuine use case for it. Right now we don't support Sixel, and if we did, our implementation would probably have to be independent of font size, so there's no value in reporting a window pixel size for that (other than maybe faking the values if that's necessary to make some apps work).

On top of that, it's not obvious to me what this sequence is even meant to report. I think it was originally defined as the window size, which some terminals interpret as the actual application window including chrome (i.e. title bar, borders, status bar, etc.), while others report some variation of the text area (although not necessarily the exact writeable area).

Then there's the issue of physical pixels vs density-independent pixels (i.e. on a high-dpi device with scaling). I would have thought DIP pixels made the most sense (otherwise how do you deal with a multi monitor setup with varying DPI), but most terminals I've been able to test seem to report physical pixels.

Another thing to bear in mind is that CSI t is also the DECSLPP sequence, so some terminals will simply interpret CSI 14 t as setting the screen height to 14 lines. That's admittedly rare - I think most that support DECSLPP only accept heights of 24 or more - but given the variability of the responses, even when supported, this doesn't seem like something you'd want to rely on.

It's also worth mentioning that TIOCGWINSZ has similar problems - in some cases it reports the windows size (i.e. including chrome), and some report the text area. In the few terminals I've found that supported both TIOCGWINSZ and CSI 14 t, most did not return the same values for them (although I haven't tested enough to suggest that that's typical behaviour).

@j4james commented on GitHub (Dec 15, 2020): I don't think it's worth considering until we have a genuine use case for it. Right now we don't support Sixel, and if we did, our implementation would probably have to be independent of font size, so there's no value in reporting a window pixel size for that (other than maybe faking the values if that's necessary to make some apps work). On top of that, it's not obvious to me what this sequence is even meant to report. I think it was originally defined as the window size, which some terminals interpret as the actual application window including chrome (i.e. title bar, borders, status bar, etc.), while others report some variation of the text area (although not necessarily the exact writeable area). Then there's the issue of physical pixels vs density-independent pixels (i.e. on a high-dpi device with scaling). I would have thought DIP pixels made the most sense (otherwise how do you deal with a multi monitor setup with varying DPI), but most terminals I've been able to test seem to report physical pixels. Another thing to bear in mind is that `CSI t` is also the `DECSLPP` sequence, so some terminals will simply interpret `CSI 14 t` as setting the screen height to 14 lines. That's admittedly rare - I think most that support `DECSLPP` only accept heights of 24 or more - but given the variability of the responses, even when supported, this doesn't seem like something you'd want to rely on. It's also worth mentioning that `TIOCGWINSZ` has similar problems - in some cases it reports the windows size (i.e. including chrome), and some report the text area. In the few terminals I've found that supported both `TIOCGWINSZ` and `CSI 14 t`, most did not return the same values for them (although I haven't tested enough to suggest that that's typical behaviour).
claunia commented 2026-01-31 02:57:52 +00:00
Author
Owner
Copy Link

@csdvrx commented on GitHub (Dec 16, 2020):

And It's CSI 14t, right? Not OSC.

@skyline75489 my mistake!

BTW I'd love to try your Windows Terminal branch with sixel support, especially if advanced SGR sequences are also supported!

I don't think it's worth considering until we have a genuine use case for it.

@j4james, the use case is being compatible with... about every other terminal emulator.

Right now we don't support Sixel,

Well, eventually you may, and I already do, through tmux-sixel (to be released soon) which passes the sixel sequence "as-is" if the terminal supports them, and if not adapts that into a fallback rendition that works about everywhere.

Here is an example: tmux-sixel-fallback-161-40

You will recognize the current Windows Terminal Preview, straight from the store. It's showing a picture thanks to a conversion of the sixels in colored unicode blocks. Unfortunately, TIOCGWINSZ only works on remote hosts.

I need the size of the terminal in pixels to "maintains compatibility with existing implementations so images do not run off the edge of the screen or only fill half the screen" as mentioned by @OhMeadhbh in https://github.com/microsoft/Terminal/issues/448#issuecomment-708127508

IMHO, that's at least 3 usecases: compatibility with xterm, proper sixel supoprt, sixel fallback mode support.

and if we did, our implementation would probably have to be independent of font size,

That's very wrong, for reason explained in #448 with several example - images will be stretched or will not fit with the rest of the TUI. Also, it will mess with the display as soon as the font size is altered - something as fast as a ctrl-+ to make the text more legible

so there's no value in reporting a window pixel size for that (other than maybe faking the values if that's necessary to make some apps work).

Well, maybe I'm wrong, but after reading this, it seems to me you want to play the clock on sixel support, waiting out until enough people complain with their "genuine use cases", after which you've already decided you'll do a shoddy job by reporting fake values - basically doing the bare minimum so that apps work poorly -- but hey, at least they may not crash thanks to the fake values!

It doesn't seem very ambitious, and it certainly doesn't inspire me trust in the Terminal future...

On top of that, it's not obvious to me what this sequence is even meant to report

Let's make an educated guess here: don't you think that, maybe, an application drawing pixels on a canvas is interested by the size of the actual canvas it's drawing on, and not by the window decorations?

If in doubt, just fire xterm, and do measurements, you'll see.

some terminals interpret as the actual application window including chrome (i.e. title bar, borders, status bar, etc.), while others report some variation of the text area (although not necessarily the exact writeable area).

Some terminals even report different sizes between TIOCGWINSZ and 14t, until the window is resized and then the values match, like https://github.com/mintty/mintty/issues/1071

There's a name for that: a bug. I documented it in detail as I'm preparing a software demo, and making sure everything will go according to the script.

Another thing to bear in mind is that CSI t is also the DECSLPP sequence, so some terminals will simply interpret CSI 14 t as setting the screen height to 14 lines. That's admittedly rare - I think most that support DECSLPP only accept heights of 24 or more - but given the variability of the responses, even when supported, this doesn't seem like something you'd want to rely on

Terminals are 80x25, as you say yourself DECSLPP only accept heights of 24 or more. But even if it was >25, this is irrelevant: let's not forget that CSI 14t is send not by the terminal, but by the application to ask the terminal size, The only thing Windows Terminal has to do is to answer the query. I fail to see how answering the query may cause issues.

An application that needs to query the terminal may not have been run on a DEC terminal that did interpret 14t as a resize (!!!)

Still, if you believe answering the query from an app making use of xterm control sequences may cause issues, make it a flag: have by default the Terminal refuse do anything.

IMHO that's a bad default, but at least that's something I may be able to work with!

@csdvrx commented on GitHub (Dec 16, 2020): > And It's `CSI 14t`, right? Not `OSC`. @skyline75489 my mistake! BTW I'd love to try your Windows Terminal branch with sixel support, especially if advanced SGR sequences are also supported! > I don't think it's worth considering until we have a genuine use case for it. @j4james, the use case is being compatible with... about every other terminal emulator. > Right now we don't support Sixel, Well, eventually you may, and I already do, through tmux-sixel (to be released soon) which passes the sixel sequence "as-is" if the terminal supports them, and if not adapts that into a fallback rendition that works about everywhere. Here is an example: <img width="900" alt="tmux-sixel-fallback-161-40" src="https://user-images.githubusercontent.com/49044530/102044900-6ba3f880-3d9d-11eb-9c5e-4758e8b2cecf.png"> You will recognize the current Windows Terminal Preview, straight from the store. It's showing a picture thanks to a conversion of the sixels in colored unicode blocks. Unfortunately, TIOCGWINSZ only works on remote hosts. I need the size of the terminal in pixels to "maintains compatibility with existing implementations so images do not run off the edge of the screen or only fill half the screen" as mentioned by @OhMeadhbh in https://github.com/microsoft/Terminal/issues/448#issuecomment-708127508 IMHO, that's at least 3 usecases: compatibility with xterm, proper sixel supoprt, sixel fallback mode support. > and if we did, our implementation would probably have to be independent of font size, That's very wrong, for reason explained in #448 with several example - images will be stretched or will not fit with the rest of the TUI. Also, it will mess with the display as soon as the font size is altered - something as fast as a ctrl-+ to make the text more legible > so there's no value in reporting a window pixel size for that (other than maybe faking the values if that's necessary to make some apps work). Well, maybe I'm wrong, but after reading this, it seems to me you want to play the clock on sixel support, waiting out until enough people complain with their "genuine use cases", after which you've already decided you'll do a shoddy job by reporting fake values - basically doing the bare minimum so that apps work poorly -- but hey, at least they may not crash thanks to the fake values! It doesn't seem very ambitious, and it certainly doesn't inspire me trust in the Terminal future... > On top of that, it's not obvious to me what this sequence is even meant to report Let's make an educated guess here: don't you think that, maybe, an application drawing pixels on a canvas is interested by the size of the actual canvas it's drawing on, and not by the window decorations? If in doubt, just fire xterm, and do measurements, you'll see. > some terminals interpret as the actual application window including chrome (i.e. title bar, borders, status bar, etc.), while others report some variation of the text area (although not necessarily the exact writeable area). Some terminals even report different sizes between TIOCGWINSZ and 14t, until the window is resized and then the values match, like https://github.com/mintty/mintty/issues/1071 There's a name for that: a bug. I documented it in detail as I'm preparing a software demo, and making sure everything will go according to the script. > Another thing to bear in mind is that CSI t is also the DECSLPP sequence, so some terminals will simply interpret CSI 14 t as setting the screen height to 14 lines. That's admittedly rare - I think most that support DECSLPP only accept heights of 24 or more - but given the variability of the responses, even when supported, this doesn't seem like something you'd want to rely on Terminals are 80x25, as you say yourself DECSLPP only accept heights of 24 or more. But even if it was >25, this is irrelevant: let's not forget that CSI 14t is send not by the terminal, but *by the application* to ask the terminal size, The only thing Windows Terminal has to do is to answer the query. I fail to see how answering the query may cause issues. An application that needs to query the terminal may not have been run on a DEC terminal that did interpret 14t as a resize (!!!) Still, if you believe answering the query from an app making use of xterm control sequences may cause issues, make it a flag: have by default the Terminal refuse do anything. IMHO that's a bad default, but at least that's something I may be able to work with!
claunia commented 2026-01-31 02:57:52 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 16, 2020):

Well hold up.

after which you've already decided you'll do a shoddy job by reporting fake values [...] It doesn't seem very ambitious, and it certainly doesn't inspire me trust in the Terminal future...

You do not need to slander us into doing your preferred thing 😄

If in doubt, just fire xterm, and do measurements, you'll see.

Fortunately, the inimitable egmontkob did exactly this and found existing terminal emulators to be lacking.

"base" means that the reported numbers are the number of cells multiplied by each cell's size,
"extended" means it also includes the standard padding (border), the extra padding in case the
window size is not grid-aligned (e.g. maximized), and the scrollbar.

                \e[14t       ws_[xy]pixel
xterm            base(*)      extended
urxvt            extended     base
pterm (putty)    extended     base
st (suckless)    -            base
VTE              base         -
konsole          -            -
terminology      -            -

(*) Ctrl + right click -> Allow Window Ops

I especially "love" how xterm and urxvt are the exact opposite of each other :-)

(source (2017))

But even if it was >25, this is irrelevant: let's not forget that CSI 14t is send not by the terminal, but by the application to ask the terminal size

Right. I believe that's James' point: the application would also be the source of DECSLPP. The xterm control sequences documentation does call out the alternate treatment of DECSLPP and XTWINOPS.

@DHowett commented on GitHub (Dec 16, 2020): Well hold up. > after which you've already decided you'll do a shoddy job by reporting fake values [...] It doesn't seem very ambitious, and it certainly doesn't inspire me trust in the Terminal future... You do not need to slander us into doing your preferred thing :smile: > If in doubt, just fire xterm, and do measurements, you'll see. Fortunately, the inimitable egmontkob _did exactly this_ and found existing terminal emulators to be lacking. ``` "base" means that the reported numbers are the number of cells multiplied by each cell's size, "extended" means it also includes the standard padding (border), the extra padding in case the window size is not grid-aligned (e.g. maximized), and the scrollbar. \e[14t ws_[xy]pixel xterm base(*) extended urxvt extended base pterm (putty) extended base st (suckless) - base VTE base - konsole - - terminology - - (*) Ctrl + right click -> Allow Window Ops I especially "love" how xterm and urxvt are the exact opposite of each other :-) ``` ([source](https://bugzilla.gnome.org/show_bug.cgi?id=782576) (2017)) > But even if it was >25, this is irrelevant: let's not forget that CSI 14t is send not by the terminal, but by the _application_ to ask the terminal size Right. I believe that's James' point: the _application_ would also be the source of `DECSLPP`. The [xterm control sequences](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html) documentation does call out the alternate treatment of `DECSLPP` and `XTWINOPS`.
claunia commented 2026-01-31 02:57:52 +00:00
Author
Owner
Copy Link

@csdvrx commented on GitHub (Dec 16, 2020):

Well hold up.

I don't want to assume wrongly, but I just don't understand at all the logic behind what was proposed in the answer. Seriously.

So I gave the only reasonable explanation that could connect all the dots, since the proposed choices seems contradictory with the stated goals of having a terminal that doesn't break compatibility.

after which you've already decided you'll do a shoddy job by reporting fake values [...] It doesn't seem very ambitious, and it certainly doesn't inspire me trust in the Terminal future...

You do not need to slander us into doing your preferred thing 😄

It's not about doing "my" preferred thing: fake values are in general a bad idea, here especially because it's ignoring the precedent set by what you are trying to replace, thus breaking backwards compatibility.

It's not about preferences or tastes: breaking backwards compatibility without good reasons is very wrong, and I'm sorry but laziness is not a valid reason 😄

If in doubt, just fire xterm, and do measurements, you'll see.

Fortunately, the inimitable egmontkob did exactly this and found existing terminal emulators to be lacking.

Actually, I'd say he found out exactly what I was saying: xterm returns the base through \e[14t.

I especially "love" how xterm and urxvt are the exact opposite of each other :-)

Let's be honest: Windows Terminal aims to replace the currently deployed terminals whenever possible, and besides not breaking compatibility whenever possible, that means putting a focus on the most widely used, not on the obscure ones.

Do you really think there're a lot of corporate deployments of st and urxvt? Especially when compared to xterm?

Personally, I don't think so, but if you REALLY want to cover all bases, add 2 flags:

  • one to plainly ignore 14t queries, which should be answered by default
  • one to return extended instead of base (even if I can't honestly see any reason to use the extended coordinates, and it seems to me to be a historical bug that became a quirk)

If you can "telemetry" that, I think you'll find <0.5% of people using Windows Terminal will use them

Right. I believe that's James' point: the application would also be the source of DECSLPP. The xterm control sequences documentation does call out the alternate treatment of DECSLPP and XTWINOPS.

So what you say is that you want to reserve the opportunity to answer DECSLPP requests in the future? Fair enough! More backwards compatibility is better!

Here's an idea:

  • 14t will mean 99.5% of the time "give me the coordinates", as terminals are 80x25, and 14<<<25 enough to be barely usable, and without a clear goal (setting to 2 lines? I could buy that, to have a command prompt somwhere. 25? I could buy that, to restore to normal. >25? Of course! But nothing makes 14 special)
  • so a safe default would be, resize with any other values besides 14, but with 14 answer the query by providing the size of the base window
  • have a flag to "remove" this exception for 14 if you are really worried about people with terminals having 14 lines
  • eventually have another flag to answer 14 by giving the extended coordinates if you are really worried about keeping compatibility with the anecdotal terminals like st and urxvt
@csdvrx commented on GitHub (Dec 16, 2020): > Well hold up. I don't want to assume wrongly, but I just don't understand *at all* the logic behind what was proposed in the answer. Seriously. So I gave the only reasonable explanation that could connect all the dots, since the proposed choices seems contradictory with the stated goals of having a terminal that doesn't break compatibility. > > after which you've already decided you'll do a shoddy job by reporting fake values [...] It doesn't seem very ambitious, and it certainly doesn't inspire me trust in the Terminal future... > > You do not need to slander us into doing your preferred thing 😄 It's not about doing "my" preferred thing: fake values are in general a bad idea, here especially because it's ignoring the precedent set by what you are trying to replace, thus breaking backwards compatibility. It's not about preferences or tastes: breaking backwards compatibility without good reasons is very wrong, and I'm sorry but laziness is not a valid reason 😄 > > If in doubt, just fire xterm, and do measurements, you'll see. > > Fortunately, the inimitable egmontkob _did exactly this_ and found existing terminal emulators to be lacking. Actually, I'd say he found out exactly what I was saying: xterm returns the base through \e[14t. > I especially "love" how xterm and urxvt are the exact opposite of each other :-) Let's be honest: Windows Terminal aims to replace the currently deployed terminals whenever possible, and besides not breaking compatibility whenever possible, that means putting a focus on the most widely used, not on the obscure ones. Do you really think there're a lot of corporate deployments of st and urxvt? Especially when compared to xterm? Personally, I don't think so, but if you *REALLY* want to cover all bases, add 2 flags: - one to plainly ignore 14t queries, which should be answered by default - one to return extended instead of base (even if I can't honestly see any reason to use the extended coordinates, and it seems to me to be a historical bug that became a quirk) If you can "telemetry" that, I think you'll find <0.5% of people using Windows Terminal will use them > Right. I believe that's James' point: the _application_ would also be the source of `DECSLPP`. The [xterm control sequences](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html) documentation does call out the alternate treatment of `DECSLPP` and `XTWINOPS`. So what you say is that you want to reserve the opportunity to answer DECSLPP requests in the future? Fair enough! More backwards compatibility is better! Here's an idea: - 14t will mean 99.5% of the time "give me the coordinates", as terminals are 80x25, and 14<<<25 enough to be barely usable, and without a clear goal (setting to 2 lines? I could buy that, to have a command prompt somwhere. 25? I could buy that, to restore to normal. >25? Of course! But nothing makes 14 special) - so a safe default would be, resize with any other values besides 14, but with 14 answer the query by providing the size of the base window - have a flag to "remove" this exception for 14 if you are really worried about people with terminals having 14 lines - eventually have another flag to answer 14 by giving the extended coordinates if you are really worried about keeping compatibility with the anecdotal terminals like st and urxvt
claunia commented 2026-01-31 02:57:53 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 17, 2020):

@zadjii-msft If you agree, yank Triage. Conhost backlog, requires server work (we don't even have support for ioctls, and no windows console API allows for pixel sizing) and design. Did some prototyping on a new communication channel in the hax/l9 branch to see how easy it would be for us to extend the Windows API without shipping a new version of Windows. Impacts all three product areas (terminal, conhost, conpty) but I only marked the two.

@DHowett commented on GitHub (Dec 17, 2020): @zadjii-msft If you agree, yank Triage. Conhost backlog, requires server work (we don't even have support for ioctls, and no windows console API allows for pixel sizing) and design. Did some prototyping on a new communication channel in the hax/l9 branch to see how easy it would be for us to extend the Windows API without shipping a new version of Windows. Impacts all three product areas (terminal, conhost, conpty) but I only marked the two.
claunia commented 2026-01-31 02:57:53 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Dec 17, 2020):

@csdvrx I appreciate your interest in my work. However, my sixel branch should be considered very obsolete. The main blocker is the performance. It takes a huge amount of refactoring to implement streaming sixel data directly to the terminal and make it possible to fix the performance issue. Until then my branch is just a PoC.

If you’re still interested, @yatli actually got it up and running, I believe. He might had a better idea than I do.

@skyline75489 commented on GitHub (Dec 17, 2020): @csdvrx I appreciate your interest in my work. However, my sixel branch should be considered very obsolete. The main blocker is the performance. It takes a huge amount of refactoring to implement streaming sixel data directly to the terminal and make it possible to fix the performance issue. Until then my branch is just a PoC. If you’re still interested, @yatli actually got it up and running, I believe. He might had a better idea than I do.
claunia commented 2026-01-31 02:57:53 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 17, 2020):

Sure yea, we can stick this on the backlog, with the caveat of I'm upgrading this to a scenario, because implementing an entirely new API layer through conpty to the Terminal is definitely not something I'd consider a "task" or even "deliverable" 😄

@zadjii-msft commented on GitHub (Dec 17, 2020): Sure yea, we can stick this on the backlog, with the caveat of I'm upgrading this to a scenario, because implementing an entirely new API layer through conpty to the Terminal is definitely not something I'd consider a "task" or even "deliverable" 😄
claunia commented 2026-01-31 02:57:53 +00:00
Author
Owner
Copy Link

@csdvrx commented on GitHub (Dec 19, 2020):

implementing an entirely new API layer through conpty to the Terminal

@zadjii-msft Maybe I'm not correctly perceiving the magnitude of the problem, but without talking about TIOCGWINSZ, is it that difficult for the terminal to intercept the 14 sequence and reply with its own geometry? Or is it because you want to make a more generic solution?

The way I see it, the terminal must knows about the font it's using, and the geometry of the canvas it's flowing the text to, so it seems to be just a multiplication away.

@DHowett About the difference between xterm and urxvt, I've learned xterm now supports 14;2 which gives the dimension with the decorations included: https://github.com/mintty/mintty/issues/1071#issuecomment-748347668

@skyline75489 Yes, I'm very interested in sixel support for some very specific reasons, so thanks a lot for the suggestion, I'll follow up with yatli!

@csdvrx commented on GitHub (Dec 19, 2020): > implementing an entirely new API layer through conpty to the Terminal @zadjii-msft Maybe I'm not correctly perceiving the magnitude of the problem, but without talking about TIOCGWINSZ, is it that difficult for the terminal to intercept the 14 sequence and reply with its own geometry? Or is it because you want to make a more generic solution? The way I see it, the terminal must knows about the font it's using, and the geometry of the canvas it's flowing the text to, so it seems to be just a multiplication away. @DHowett About the difference between xterm and urxvt, I've learned xterm now supports 14;2 which gives the dimension with the decorations included: https://github.com/mintty/mintty/issues/1071#issuecomment-748347668 @skyline75489 Yes, I'm very interested in sixel support for some very specific reasons, so thanks a lot for the suggestion, I'll follow up with yatli!
claunia commented 2026-01-31 02:57:54 +00:00
Author
Owner
Copy Link

@benjajaja commented on GitHub (Oct 6, 2024):

This is relevant once again, now that there is sixel support. The use case is that a sixel image can be displayed, but it is unknown what area will be covered by it or if it fits at all in the window. It is desirable to know the window size in pixel, so that together with the already implemented cols*rows it can be determined how many "cells" a sixel image covers. Only then can the image can be placed inside TUIs.

@benjajaja commented on GitHub (Oct 6, 2024): This is relevant once again, now that there is sixel support. The use case is that a sixel image can be displayed, but it is unknown what area will be covered by it or if it fits at all in the window. It is desirable to know the window size in pixel, so that together with the already implemented cols*rows it can be determined how many "cells" a sixel image covers. Only then can the image can be placed inside TUIs.
claunia commented 2026-01-31 02:57:54 +00:00
Author
Owner
Copy Link

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

@benjajaja We added CSI 14 t and CSI 16 t in PR #17504. That was released at the same time as the sixel support.

@j4james commented on GitHub (Oct 6, 2024): @benjajaja We added `CSI 14 t` and `CSI 16 t` in PR #17504. That was released at the same time as the sixel support.
claunia commented 2026-01-31 02:57:54 +00:00
Author
Owner
Copy Link

@benjajaja commented on GitHub (Oct 6, 2024):

@j4james I didn't even know these existed! Thank you many times!

@benjajaja commented on GitHub (Oct 6, 2024): @j4james I didn't even know these existed! Thank you many times!
claunia commented 2026-01-31 02:57:54 +00:00
Author
Owner
Copy Link

@mikoto2000 commented on GitHub (Nov 14, 2024):

I have tried CSI 14 t and CSI 16 t in Windows Terminal Preview and it seems to work fine.

However, the TIOCGWINSZ pixel in ioctl still returns zero.
Are there any plans to provide support for this?

See: #18192

@mikoto2000 commented on GitHub (Nov 14, 2024): I have tried `CSI 14 t` and `CSI 16 t` in Windows Terminal Preview and it seems to work fine. However, the `TIOCGWINSZ` pixel in `ioctl` still returns zero. Are there any plans to provide support for this? See: #18192
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-Server Area-VT Issue-Scenario Product-Conhost Product-Terminal
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#11799
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?