XTSMGRAPHICS "Read sixel graphics geometry" returns the different value from xterm.

[kumattau]

Contour Terminal version

0.3.1-unreleased-master-7f13fbb0

Installer source

Github: source code cloned

Operating System

Ubuntu Linux 20.04

Architecture

x86-64

Other Software

No response

Steps to reproduce

cat <<EOF > test.sh
IFS=';' read -a REPLY -s -t 0.25 -d "S" -p $'\e[?2;1;0S'
echo "width=\${REPLY[2]} height=\${REPLY[3]}"
EOF
bash test.sh

Expected Behavior

Returned width and height are smaller than or equal to screen width and height (same as the latest xterm).

Actual Behavior

Returned width and height are always 1920 and 1080 regardless of screen size.

Additional notes

By this problem, https://github.com/hackerb9/lsix can not layout pictures as expected position.

contour

xterm

ref: xterm implementation:

https://github.com/ThomasDickey/xterm-snapshots/blob/834b501a1416d7f14b1c38705083f413aea92eee/charproc.c#L4625

[uspasojevic96]

@christianparpart doesnt this just return whatever is defined in the contour.yml?

EDIT: yes it does

contour/src/contour/TerminalSession.cpp

Line 964 in 88b4d96

terminal_.setMaxImageSize(config_.maxImageSize);

[christianparpart]

Good morning. I'm not sure about how a real VT340 would respond to this, but due to the nature of the fact, that a VT340 is fairly limited to what a modern VTE is capable of, I can't judge for either side. (EDIT: It would not respond at all, as XTSMGRAPHICS is an extension from xterm).

But to my understanding, XTSMGRAPHICS is used to query the limits, that's not necessarily the same as how big a screen (terminal viewport in pixels) is. For that there is another VT sequence, CSI 14 t (XTWINOPS), as introduced by dterm, and extended by xterm (just losely quoting here).

@hackerb9, what's your stance on this? Objectively looking at it, I'd rather change lsix to use XTWINOPS on top of XTSMGRAPHICS to query the screen width as the minimum of both values.

[christianparpart]

https://github.com/ThomasDickey/xterm-snapshots/blob/834b501a1416d7f14b1c38705083f413aea92eee/charproc.c#L4622-L4626

The problem I'm (personally) having with this code, is, that screen size may be changed due to the user, using CSI 14 t (IMHO) clearly tells that you are querying viewport width/height in pixels (which is subject to change), whereas CSI [ ? 2 ; 1 ; 0 S (by looking at the docs) reads the sixel canvas size in pixels attribute, not stating its relation to the actual window's size in pixels.

[j4james]

A couple of points worth mentioning:

1. XTSMGRAPHICS is an XTerm invention - a real VT340 would not have responded to that.
2. XTerm's initial implementation of the 2;1 query returned the maximum geometry size, the same as you're doing now (see here).
3. A few other terminals copied that initial implementation, and while some have been updated to match XTerm's current behavior, I think some still report the maximum size.
4. CSI 14 t is also not a VT340 standard, and has its own problems, but it's more widely implemented, and more reliable in general.

So personally, I'd recommend apps just rely on CSI 14 t if they need to determine the screen size (taking into account that some rounding may be required). But if you also want to use XTSMGRAPHICS as a backup, only do so if it's smaller than the dimensions returned by CSI 14 t - that should give you the most accurate results.

[christianparpart]

Sounds absolutely reasonable. Thanks @j4james ;)

[kumattau]

This is just my personal opinion,

XTSMGRAPHICS is an XTerm invention, so other terminals should follow XTerm's current spec.

https://github.com/ThomasDickey/xterm-snapshots/blob/834b501a1416d7f14b1c38705083f413aea92eee/ctlseqs.txt#L569-L622

As the following explanation,

• Pa = 1 should return minimum of the window size (maybe text (screen) area size) and the maximum graphic size.
• Pa = 4 should return the maximum graphic size.

Additionally, XTWINOPS (CSI 14 t) should return text area size.

       Pa = 1  -> read attribute.
       Pa = 2  -> reset to default.
       Pa = 3  -> set to value in Pv.
       Pa = 4  -> read the maximum allowed value.

      Notes:
      o   The current implementation allows reading the graphics
          sizes, but disallows modifying those sizes because that is
          done once, using resource-values.
      o   Graphics geometry is not necessarily the same as "window
          size" (see the dtterm window manipulation extensions).
          XTerm limits the maximum graphics geometry according to
          the maxGraphicSize resource.
          The maxGraphicSize resource can be either an explicit
          heightxwidth (default: 1000x1000 as of version 328) or the
          word "auto" (telling XTerm to use limits the decGraphicsID
          or decTerminalID resource to determine the limits).
      o   XTerm uses the minimum of the window size and the graphic
          size to obtain the maximum geometry.
      o   While resizing a window will always change the current
          graphics geometry, the reverse is not true.  Setting
          graphics geometry does not affect the window size.
      o   If xterm is able to support graphics (compile-time), but
          is not configured (runtime) for graphics, these responses
          will indicate a failure.  Other implementations which do
          not use the maximum graphics dimensions but are configured
          for graphics should report zeroes for the maximum geometry
          rather than a failure.

So personally, I'd recommend apps just rely on CSI 14 t if they need to determine the screen size (taking into account that some rounding may be required). But if you also want to use XTSMGRAPHICS as a backup, only do so if it's smaller than the dimensions returned by CSI 14 t - that should give you the most accurate results.

The Applications just only are forced to work around for supporting various terminals, but the terminals should not expect the application's work-around effort and should keep the compatibility for the standard as possible.

[christianparpart]

The Applications just only are forced to work around for supporting various terminals, but the terminals should not expect the application's work-around effort and should keep the compatibility for the standard as possible.

I'm currently (today) busy at work, I can respond later tonight more detailed. But I absolutely agree with you here that apps should not suffice from implementation semantic differences.

[jerch]

My 2cents on XTSMGRAPHICS:

The sequence feels weirdly xterm implementation dependent to me, it mostly reflects restrictions/settings on xterm, that other terminals might not have in the same way. In general I think terminal sequences should stay in the general and portable interface realms, and not surface implementation details at all costs, unless the sequence is marked for private usage only. XTSMGRAPHICS fails in that part imho.

Now with xterm things are more tricky - it is treated by many app devs and even terminal devs as the de-facto terminal interface standard these days, which makes it hard to ignore any sequence, xterm comes up with. Thats the reason, why I implemented XTSMGRAPHICS as well, but only parts of it, that could be answered reasonably:

• ReGIS - all nope, answered with GaStatus.ITEM_ERROR
• colors registers - READ | SET_DEFAULT | SET | READ_MAX supported (up to 4096)
• sixel geometry - READ | READ_MAX supported, all others will fail

For sixel geometry READ it returns the current viewport size in pixels, for READ_MAX I had to cheat and return the square* of the pixel limit of the sixel decoder (default 4096x4096). The last thing is somewhat unlucky, as it is not really limited by that (an image can happily run up to 32k pixel width, if height * width stays within pixelLimit).

The impl can be found here: https://github.com/jerch/xterm-addon-image/blob/75deeccd20172e753cf8b38846140462d05b9467/src/ImageAddon.ts#L259

---

Edit: [*] square root 😸

[j4james]

Just to be clear, I agree with everyone that is saying you should match XTerm's current behavior if you're going to implement this sequence. But I'd still recommend applications avoid using it if possible.

The sequence feels weirdly xterm implementation dependent to me, it mostly reflects restrictions/settings on xterm, that other terminals might not have in the same way. In general I think terminal sequences should stay in the general and portable interface realms, and not surface implementation details at all costs, unless the sequence is marked for private usage only. XTSMGRAPHICS fails in that part imho.

I fully agree with this. That's why I've just chosen not to implement it. And if I come across an application or library that depends on it, I've encouraged them to avoid that dependency, and support a reasonable fallback.

[kumattau]

Yes, the main problem is that, as the title says, XTSMGRAPHICS "Read sixel graphics geometry" returns the different value from xterm.
It makes application confused.
The terminal can ignore unknown CSI (by not implementing CSI) and XTSMGRAPHICS defines error.
So, if implementing XTSMGRAPHICS is difficult for the terminal, it should ignore or return error rather than return unexpected value.

I fully agree with this. That's why I've just chosen not to implement it.

I agree with your way.
I think that this is the right way to handle this if the terminal can not support this CSI for some reasons.

I'd still recommend applications avoid using it if possible.

I agree with you about implementing applications.

[christianparpart]

i can change that to match xterm (as much as I dislike that :D). But regardless of that, we could still kindly ask @hackerb9 to change the query order, first test CSI 14 t, and then go for XTSMGRAPHICS if the first fails, or use the minimum value of both (if both return something). Does this sound plausible?

[hackerb9]

i can change that to match xterm (as much as I dislike that :D). But regardless of that, we could still kindly ask @hackerb9 to change the query order, first test CSI 14 t, and then go for XTSMGRAPHICS if the first fails, or use the minimum value of both (if both return something). Does this sound plausible?

Hi! Thanks for the kind request. Possible, but not plausible given my current understanding of the situation.

First, some ancient history: If there are deficiencies in XTSMGRAPHICS being used for sixel geometry, I'm the one to blame, not XTerm nor XTerm's maintainer, Mr. Dickey. While that extension existed before for changing the pixel depth, I'm the one who proposed using it to also query the sixel geometry and worked with Mr. Dickey to get it working properly in XTerm. The problem at that time, and that still exists with dtterm window ops, like CSI14t, is that window size (or geometry in the old lingo) has been overloaded to mean different things. IIRC, the dtterm escape sequences were meant to be able to position the terminal on the screen, so the "size" originally included the blank border around the text area and even the width of the titlebar and other user interface widgets.

While it is a happy accident if CSI14t returns the correct sixel geometry, it is not incorrect for a terminal to do otherwise. Even excluding UI widgets, the dtterm window size may not match the renderable sixel area: a terminal might, for example, choose to always use an 800x480 sixel geometry, no matter what the window size is. On the other hand, if a terminal has implemented XTSMGRAPHICS in a way that it returns something other than the sixel screen size, then it is in error. (And, yes, XTerm itself was in error originally, but that has been fixed since 2019.)

So, I think using dtterm's size for sixel geometry is a mistake. But, as always, I'm fallible: Please let me know if I got something wrong.

[j4james]

I hate to be the one defending the CSI t sequences, because I really don't like them either, but I've tested quite a lot of sixel terminals, and the simple truth is that you get better results using CSI t than you do using XTSMGRAPHICS (at least in my experience). In time that may change, but for now if you want your app to work on as many terminals as possible, I'd recommend making the most of that happy accident.

[jerch]

Indeed, CSI t is quite convoluted, and even was subject of several security concerns up to CVEs. The WindowOps sequences kinda lost their primary purpose to tune certain desktop integration aspects long ago (mind you, many things simply dont work anymore, as they have no counterpart on modern DEs).

So the shift of meaning is a logical consequence as in any evolutionary system (we are just that atm, as we lack a higher authority giving us red/green lines regarding the terminal interface). The problem we all have with this (at least I find it painful) - there is no strict right or wrong in such a scenario, just a more likely/unlikely, which really sucks in terms of strict correctness (computers still need that, unlikely to change until we have QPU-NPUs).

Regarding XTSMGRAPHICS I think you should not blame yourself too hard (@hackerb9), while I dont like it for leaking xterm implementation details, it certainly has several pros:

• separation of concerns, graphical stuff is a very different and delicate thing for text-driven terminals
• no convolution of other sequences / overloaded meanings (as with CSI t, which happens to work more by accident)
• extensible interface (easy to put other protocols or graphical options there, once needed)
• reporting caps (just a minor nag from my side - would have made SET options non-reporting by default, and hide reporting behind a sequence flag)

So I try to see things more opportunistic here - since XTSMGRAPHICS is already there, and ppl are likely to use it (its still xterm, we cannot ignore that until some other TE dethrones it) - lets use it to our advantage (thats the reason why I proposed in another thread to put a "reload default palette" option there).

Edit: Ah well, I think I will just do that and load the default palette on SET_DEFAULT (technically not quite correct, as it is only meant to change the register numbers, but my impl currently lacks a single sequence for reloading color values only).