Runtime changes of terminal size about supdup HOT 10 OPEN

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.

from supdup.

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

from supdup.

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

from supdup.

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.

from supdup.

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.

from supdup.

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.

from supdup.

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.

from supdup.

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.

from supdup.

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.

from supdup.

from supdup.