XTSMGRAPHICS ought be supported if supporting Sixel

[dankamongmen]

Describe the bug

wezterm reports that it supports Sixel by replying to a "Send Device Attributes" with a payload including the number 4. This is all well and good. Unfortunately, it does not seem to repond to a subsequent XTSMGRAPHICS escape, unlike all other known Sixel implementations. It also lacks support for the 8452 DECSDM control. These are pretty useful for Sixel applications. See dankamongmen/notcurses#1484 for an example of an application locking up due to missing XTSMGRAPHICS support.

https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
https://vt100.net/docs/vt3xx-gp/chapter14.html

Environment (please complete the following information):

• OS: Linux 5.11.11, Xorg
• Version: wezterm 20210314-114017-04b7cedd-110-g9a793ed4
• US keyboard

To Reproduce

• Query the terminal with Device Send Attributes: CSI c
• wezterm replies with [?65;4;6;18;22c indicating sixel support
• Query the terminal with XTSMGRAPHICS: CSI ?1;1;0S
• wezterm does not reply

Configuration

No configuration

Expected behavior

I expect wezterm to reply with the relevant XTSMGRAPHICS parameters, in this case the number of color registers.

[wez]

I took a crack at responding to this, but I confess to being lazy and just implementing to what is on the xterm ctlseqs page without clicking through to really verify the meaning of the parameters...

wezterm's sixel implementation supports an arbitrary number of color registers, but returns 64k.
Querying sixel graphics geometry returns the pixel dimensions of the entire window.

Attempting to set the values has no effect.

 echo -e "\e[?1;1;0S" ; xxd

^[[?1;0;65536S
00000000: 1b5b 3f31 3b30 3b36 3535 3336 530a       .[?1;0;65536S.

[dankamongmen]

Beautiful, more than enough for me to jazz with. Thanks, good sir! I'll give it a quick test and provide you with a verification.

[dankamongmen]

looks good:

[schwarzgerat](0) $ ./caps-rendered

 notcurses 2.2.4 by nick black et al on vte-256color
  63 rows (22px) 80 cols (10px) (78.75KiB) 256 colors+RGB
  compiled with gcc-10.2.1 20210110, little-endian 16B cells
  terminfo from ncurses 6.2.20201114
  avformat 58.45.100 avutil 56.51.100 swscale 5.7.100
 Colors: 256 rgb: y ccc: y setaf: y setab: y
 sgr: y sgr0: y
 op: y fgop: y bgop: y
 rows: 63 cols: 80 rpix: 22 cpix: 10 (1386x800)
 max bitmap size: 1386x800 colorregs: 65536   <----------------------------------
 UTF8: y sextants: y braille: y images: y videos: y
 background isn't interpreted as transparent
 cup: y vpa: y hpa: y
[schwarzgerat](0) $

i'm seeing problems when i actually try to display one, but img2sixel is working fine, so that's probably my fault. thanks a lot!

[dankamongmen]

i'm seeing problems when i actually try to display one, but img2sixel is working fine, so that's probably my fault. thanks a lot!

actually, img2sixel is also having problems with the same images. i probably just need a release build. anyway, i'll look into this, and if there's a real problem, i'll file a bug on it. the work is much appreciated!

[dankamongmen]

yep, all problems went away with a release build; i didn't realize the differences could be that stark, geez. nice work!

i'm seeing one other thing, regarding transparent sections; i'll make a new bug. notcurses-demo, about as intensive a TUI program as exists, now works perfectly on wezterm otherwise. =]

[dankamongmen]

pixel + text overlay works, yay

[wez]

Yeah, the rust image crate that wezterm uses really needs to be built in release mode otherwise it is super slow.
Glad to hear that things are happier!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.