Xterm.js: Support for Extended Window Manager Hints

Created on 19 Oct 2018  路  17Comments  路  Source: xtermjs/xterm.js

When using xterm.js for Windows SAC sessions, the input line stays fixed in place without adjusting to the size of the terminal (screenshot below). This seems to be because xtermjs doesn't seem to support a Esc + [18t control sequence, which is emitted by SAC to determine the screen size. Order of events is as follows:

  1. SAC emits ESC + [18t (\x1b[18t)
  2. The terminal emulator is expected to reply with ESC + [8;RRR;CCCt (\x1b[8;RRR;CCCt)

    • RRR is the number of rows, and CCC is the number of columns

    • This must be sent by the terminal emulator within 3 seconds

Looks like in order for xtermjs to support Windows SAC resizing, there will need to be support added for the ESC + [18t control sequence. Can this be added?

image

help wanted typenhancement

Most helpful comment

I believe this can be done by executing the resize command and using the -s switch. Based upon my review of the resize code, that should issue a _[18t_ as part of what the docs describe as _Sun console escape sequences_. This is also described in the Miscellaneous section of the doc.

The idea being, as Alfred describes above:

  1. resize -s emits ESC + [18t
  2. xtermjs replies with ESC + [8;RRR;CCCt

    • RRR is the number of rows, and CCC is the number of columns

The results should be visible via the response from resize and via a stty -a command run before and after.

All 17 comments

@CraigWiand fyi

Whoever wants to work on this should look at how device status report works:

https://github.com/xtermjs/xterm.js/blob/5bc7fc4256edac39eeb340ec21f6ba0c4d877e00/src/InputHandler.ts#L1717

I expect the solution looks very similar to that.

@Tyriar , I will work on this :)

@Tyriar , I need some help on this :)
Is this about adding a new case in the deviceStatus function ?
Can you just give me a brief on how to tackle this ?
Thanks!

Perhaps I can help add a bit more info, hopefully @Tyriar will keep me honest:

The issue is really about keep the size consistent between the terminal and terminal emulator. In the xtermjs demo this is done by the client sending a resize request via another "channel" (i.e http request) to the server and the server doing a pty resize here. This works great for a remote command shell application, but not does work when the listener on the other end is an actual terminal, for example the serial port ttyS0. In this case, a different "command channel" must be issued to resize the terminal. We cannot assume the state of the serial terminal or that we could issue a Bash command like resize which would do this.

The _Extended Window Manager Hints (EWMH)_ as spec'd at: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html provide a way to do this if the terminal supports it.

@asinn826 gives the example of the Windows SAC console operating on ttyS0 would send the escape sequences described in the spec above. The ask for this issue is for xtermjs to support parsing of those EWMH sequences, sending the appropriate reply, and firing a new resize event so that the client can react to it.

I believe with the "device status report" pointer @Tyriar was providing an example of where similar parsing and response work is already done in xtermjs.

Thanks!

@CraigWiand is there some way that this could be tested on the demo during development?

@CraigWiand , Thanks for the info, I will look into this in more detail :)
I would need more help from @Tyriar on this as well :)
Thanks!

@skprabhanjan easiest way to do this would be to use a program that sends this sequence and uses it which I'm not sure about, after that you could write a test which sends the sequence and listens for the correct data event to fire.

@Tyriar, thanks for that :)
I will look into it.

I believe this can be done by executing the resize command and using the -s switch. Based upon my review of the resize code, that should issue a _[18t_ as part of what the docs describe as _Sun console escape sequences_. This is also described in the Miscellaneous section of the doc.

The idea being, as Alfred describes above:

  1. resize -s emits ESC + [18t
  2. xtermjs replies with ESC + [8;RRR;CCCt

    • RRR is the number of rows, and CCC is the number of columns

The results should be visible via the response from resize and via a stty -a command run before and after.

FWIIW, the Sun console sequence is not widely used, but I can confirm it works in the gnome-terminal.

Note that the command is used not only to query/read but also to set/write, as demonstrated out of gnome-terminal:

$ resize  # typical
COLUMNS=80;
LINES=25;
export COLUMNS LINES;

$ resize -s  # Sun
COLUMNS=80;
LINES=25;
export COLUMNS LINES;

$ echo -en '\x1b[18t'; read -s -n 15 -t 1 c
$ echo -n $c | hexdump -C
00000000  1b 5b 38 3b 32 35 3b 38  30 74                    |.[8;25;80t|
0000000a

$ echo -en '\x1b[8;30;100t'  # set terminal to 30 rows with 100 columns
$ resize
COLUMNS=100;
LINES=30;
export COLUMNS LINES;

@skprabhanjan : Thanks again for looking in this one. Just checking in on this to see if there were any questions or blockers?

@CraigWiand , sorry for not updating here .
I just could not figure out the exact sequence of steps to fix this and test it properly, I will give it a try again :)
Also I would like to leave it open for anyone who would like to take a look :)

Bumping this item...we're getting customer feedback about this issue specifically. Not sure how to bring this up in the community/ask for help with this, @Tyriar, do you have any suggestions on how we could ask for help from the community with this item?

@asinn826 The report part should be straight forward, the resize part is more tricky - imho this needs a terminal option whether slave side actually can do that at all. Otherwise it may break visual output for many integrated applications if they are not prepared for terminal component height/width changes from "within".

@asinn826 Opened a PR (#2393) for this. There are several things to fiddle out before we can support it in a clean way. See PR description for more details.

@asinn826 @CraigWiand which sequences exactly are you after? We discussed this a bit in PR and while reporting information is fine, I'm not the biggest fan of adding support for resizing (8t).

We actually now provide parser hooks in the API to let embedders do this sort of thing themselves. https://github.com/xtermjs/xterm.js/pull/2393#discussion_r321961123

For example (this might not be exactly right but gives you the gist of it):

// xterm 4 api:
term.parser.addCsiHandler({ final: 't' }, params => {
  if (params[0] === 8) {
    resizeMe(params[1], params[2]);
    // return that it was handles
    return true;
  }
  return false;
});

We've also previously discussed a compat addon to add this sort of stuff but my fear is that it would go unused and be overly complex with options.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Tyriar picture Tyriar  路  4Comments

johnpoth picture johnpoth  路  3Comments

goxr3plus picture goxr3plus  路  3Comments

circuitry2 picture circuitry2  路  4Comments

Tyriar picture Tyriar  路  4Comments