Runtime changes of terminal size

[larsbrinkhoff]

This supdup implementation could be enhanced to accept the SIGWINCH signal when the terminal size changes. But I'm not sure there's a way in the SUPDUP protocol to send this information to the host? And if there were, I'm even less confident ITS or the applications would care to handle the change.

[dabridgham]

At one time I thought about writing an X11 SUPDUP client and realized I'd want this functionality. It would need a new command in the SUPDUP protocol and maybe a SMARTS bit saying the command was supported (I don't recall offhand what SUPDUP does with unknown commands). At the time I had no idea who I'd ask (or tell) about adding this new command. Now there's this community.

If ITS doesn't support the idea of a resize, it does support the idea of setting the terminal's size and SUPDUP has that command to trigger a redisplay.

[larsbrinkhoff]

Here is some information about how ITS handles resizing terminals: PDP-10/its#471

[larsbrinkhoff]

We should draft an RFC and submit it on April 1th.

[larsbrinkhoff]

There isn't a lot of room in the current protocol definition to send the resize information. All octets sent from the client to server are interpreted as keyboard input, except code 034. Code 034 is used to send input with bucky bits, and only if %TOFCI is set.

There are two unused bucky bits that could be used.

The graphics extension suggests another way. It states that Top-Y isn't normally meaningful as keyboard input. Why, I don't know. But maybe there are more such meaningless keyboard combinations.

[dabridgham]

Definitely tickled at the idea of submitting an April 1st RFC to update SUPDUP and then actually implementing the RFC. Likewise, someone ought to implement Mark Crispin's RFC 4042 (UTF-9 and UTF-18) in TECO and EMACS.

[dabridgham]

I had to refamiliarize myself with the SUPDUP protocol, it's been a while, but it looks to me like there's plenty of room in the input protocol. Near the bottom of page 6 of AIM 644 it says:

The encoded SUPDUP input consists entirely of byte values less than 200. Byte values 200 and above are used for special commands that are not "terminal input". On ITS, these commands are processed by the network server program, whereas 034 escape sequences are processed by the system's terminal driver.

It then goes on to describe the two byte sequence 300 301 that logs you out and 300 302 that introduces the "console location" text. If the screen resize is best handled in the network server program, it seems pretty easy to add 300 303 that introduces new screen size information.

If this function is better implemented in the system's terminal driver then it ought to fall under the 034 escape. For keyboard input, the character after the 034 is always greater than 200. Otherwise, that second character can be 034 to escape the 034 and 032 or 001 for flow control to non-network terminals. I'm not seeing anything else defined so it appears there's room there for new commands.

Or, the keyboard input says that the 2000 and 1000 bits are not currently defined. If they weren't grabbed by SUPER and HYPER or something like that, we could use them here. In fact, if I'm not messing up then there's room for a 10000 bit in the encoding of keyboard input.

In any case, a SUPDUP client ought not send this unless the server indicates it understands. The SUPDUP client would set a bit in either TTYOPT or TTYSMT saying it supports resizing the screen. The server that understands this would then issue a command to the client, enabling resizing. Only then would the client ever emit the command.

A small variation comes to mind as I look this over. Instead of being specifically a command to resize the screen, the command could preceed just re-sending those 36-bit initialization words that begin the SUPDUP connection. I don't know why you might want to change any of those other bits, but the option would be there.

[dabridgham]

There's no 10000 bit in the keyboard input; I found where my thinking went awry. Anyway, hopefully all this could be handled by the network server program and just use the 300 303 sequence. That's by far the easiest.

[larsbrinkhoff]

Right, I missed the 300 escape. 300 303 sounds great.

Whoever wants to work on the client, can assign themselves to this issue.

There's PDP-10/its#581 if working on the SUPDUP server sounds more interesting.

[larsbrinkhoff]

These seem to be relevant for submitting an RFC:

• https://tools.ietf.org/html/rfc4846
• https://www.rfc-editor.org/about/independent/
• https://www.rfc-editor.org/faq/#april

I didn't know there are special considerations for April 1th RFC submissions. The deadline for those is March 18th.

[dabridgham]

As much as the idea of an April 1st RFC amuses me, I see this as a legitimate enhancement to the SUPDUP protocol and potentially implemented on two server and two client code bases. Of course, it's an enhancement to what most people think of as a long obsolete protocol and it probably is so perhaps that makes it a joke. Anyway, the procedure to make an individual submission of an RFC seems reasonable and straightforward.