I've experienced a few terminal detection issues with SET TERM/INQ, so I decided to track them down and figure out what was going on.

First, xterm: it continues to be updated with new features and bug fixes, and the current version claims to be a VT420. When I run "set term/inq", it pauses for a few seconds, then is unable to get the terminal size.

Logging what VMS sends to a file, I see this sequence:

CSI c -> query primary device attributes
CSI " v -> DECRQDE (times out)
CSI 62"p -> set to VT200+, 8-bit controls
ESC <space> F -> select 7-bit controls (S7C1T)
ESC > -> keypad numeric mode (DECKPNM)

So the problem is that VT400 terminals should support DECRQDE (request displayed extent) to request the window width and height, as well as the column number of the leftmost column, line number of the top line, and the page number.

I don't think any Linux terminal emulator supports DECRQDE, especially since there's a different xterm escape sequence to get window size that UNIX normally uses and all the GUI terminal emulators support. "vttest" can test DECRQDE, although it's listed as a VT320 feature, not a VT420 one.

I have a different issue with Ubuntu's GNOME terminal. It claims to be a VT500 series, so SET TERM/INQ behaves a bit differently:

CSI c -> query primary device attributes
ESC 7 -> save cursor state
CSI 255;255H -> set cursor pos. to 255,255
CSI 6n -> ask for cursor pos. report
ESC 8 -> restore cursor state
CSI 62"p -> set to VT200+, 8-bit controls
ESC <space> F -> select 7-bit controls (S7C1T)
ESC > -> DECKPNM: keypad characters

With this sequence, OpenVMS does correctly get the window width and height from gnome-terminal, but then I run into a different bug. "show term" shows the terminal is in 8-bit mode, but the 8-bit controls don't work, so when I run "edit" or "monitor", I see visible ESC sequences that don't work. The workaround I found is to "set term/noeight" before or after the /inq.

I'll work on a patch for xterm to add support for DECRQDE, but it looks like these issues can be fixed entirely on the VMS side, by using the VT500 sequence to get the window size on VT400 series terminals, and by not selecting 7-bit C1 control chars immediately after setting 8-bit controls.

Best regards,
Jake Hamby

On Tuesday, October 10, 2023 at 1:40:50 PM UTC-7, Jake Hamby wrote:
>
> With this sequence, OpenVMS does correctly get the window width and height from gnome-terminal, but then I run into a different bug. "show term" shows the terminal is in 8-bit mode, but the 8-bit controls don't work, so when I run "edit" or "monitor", I see visible ESC sequences that don't work. The workaround I found is to "set term/noeight" before or after the /inq.

Oops, the second bug was user error: I was running GNOME terminal in UTF-8 mode. After I changed the profile from "High Contrast (UTF-8)" to "High Contrast", everything worked properly in 8-bit mode. BTW, PuTTY defaults to UTF-8 and if you don't change it to ISO 8859-1, or check the box that says to draw DEC line graphics even in UTF-8 mode, the DEC box art in MONITOR renders as lowercase letters.

I also have a theory about why VMS is using a different sequence for xterm than for GNOME to get the window size. xterm returns more primary device attributes. From vttest:

xterm:

Test of Device Attributes report (what are you)

Report is: <27> [ ? 6 4 ; 1 ; 2 ; 6 ; 9 ; 1 5 ; 1 6 ; 1 7 ; 1 8 ; 2 1 ; 2 2 ; 2
8 c VT400 family
1 = 132 columns
2 = printer port
6 = selective erase
9 = national replacement character-sets
15 = DEC technical set
16 = locator device port (ReGIS)
17 = terminal state reports
18 = user windows
21 = horizontal scrolling
22 = color
28 = rectangular editing

GNOME terminal:

Test of Device Attributes report (what are you)

Report is: <27> [ ? 6 5 ; 1 ; 9 c VT500 family
1 = 132 columns
9 = national replacement character-sets

I suspect that the reported presence of "user windows" and/or "horizontal scrolling" features may be influencing VMS to use the unsupported-by-third-parties DECRQDE sequence instead of the more compatible sequence to get the screen width/height.

Now I'm wondering whether xterm actually supports all of the features that it claims to. UNIX doesn't exercise terminals like VMS does, or at least not in normal use.

Regards,
Jake Hamby

On 2023-10-10, Jake Hamby (Solid State Jake) <jake.hamby@gmail.com> wrote:
> I've experienced a few terminal detection issues with SET TERM/INQ, so
> I decided to track them down and figure out what was going on.
>
> First, xterm: it continues to be updated with new features and bug
> fixes, and the current version claims to be a VT420. When I run "set
> term/inq", it pauses for a few seconds, then is unable to get the
> terminal size.
>
> Logging what VMS sends to a file, I see this sequence:
>
> CSI c -> query primary device attributes CSI " v -> DECRQDE (times
> out) CSI 62"p -> set to VT200+, 8-bit controls ESC <space> F -> select
> 7-bit controls (S7C1T) ESC > -> keypad numeric mode (DECKPNM)
>
> So the problem is that VT400 terminals should support DECRQDE (request
> displayed extent) to request the window width and height, as well as
> the column number of the leftmost column, line number of the top line,
> and the page number.

Ah, interesting. Thanks for tracking this down! I always use xterm and
have noticed that undesirable behavior when connecting to VMS, which
I've worked around by setting XTerm*VT100.decTerminalID: vt102 in my X
resources. However, that causes a different problem in another
application, so I've recently removed it and have to remember to start
up another dedicated xterm that I can set that option on for playing
with VMS. It's been an annoyance, so nice to know why it was happening.

> I'll work on a patch for xterm to add support for DECRQDE

If that makes it into xterm, that would be fantastic! Thank you!

Thanks,
Matthew

On 2023-10-11 01:00, Matthew R. Wilson wrote:
> On 2023-10-10, Jake Hamby (Solid State Jake) <jake.hamby@gmail.com> wrote:
>> I've experienced a few terminal detection issues with SET TERM/INQ, so
>> I decided to track them down and figure out what was going on.
>>
>> First, xterm: it continues to be updated with new features and bug
>> fixes, and the current version claims to be a VT420. When I run "set
>> term/inq", it pauses for a few seconds, then is unable to get the
>> terminal size.
>>
>> Logging what VMS sends to a file, I see this sequence:
>>
>> CSI c -> query primary device attributes CSI " v -> DECRQDE (times
>> out) CSI 62"p -> set to VT200+, 8-bit controls ESC <space> F -> select
>> 7-bit controls (S7C1T) ESC > -> keypad numeric mode (DECKPNM)
>>
>> So the problem is that VT400 terminals should support DECRQDE (request
>> displayed extent) to request the window width and height, as well as
>> the column number of the leftmost column, line number of the top line,
>> and the page number.
>
> Ah, interesting. Thanks for tracking this down! I always use xterm and
> have noticed that undesirable behavior when connecting to VMS, which
> I've worked around by setting XTerm*VT100.decTerminalID: vt102 in my X
> resources. However, that causes a different problem in another
> application, so I've recently removed it and have to remember to start
> up another dedicated xterm that I can set that option on for playing
> with VMS. It's been an annoyance, so nice to know why it was happening.

I would set it to answer as a VT220. Then you have most of the "modern"
capabilities, but not some of the more fancy stuff that came later. I
think the VT220 emulation is much more complete in xterm.
Main thing lacking is just soft fonts, as far as I can remember.

Johnny

On Wednesday, October 11, 2023 at 2:11:14 AM UTC-7, Johnny Billquist wrote:
>
> I would set it to answer as a VT220. Then you have most of the "modern"
> capabilities, but not some of the more fancy stuff that came later. I
> think the VT220 emulation is much more complete in xterm.
> Main thing lacking is just soft fonts, as far as I can remember.

I'll definitely need to do some exploration with VTTEST. The current xterm claims that it can emulate anything from a VT52 to a VT525, but it's missing features like soft fonts, as well as the VT400 request displayed extent (DECRQDE) command that led to my investigation.

If I run xterm with "-ti vt220" or "-ti vt320", then I don't have any problems. I'll try to find some time this week, when I'm not job hunting, to work on a patch for xterm to add the missing feature, and check to see if xterm really implements every feature that it claims to support in device attributes.

Cheers,
Jake

On Tuesday, October 10, 2023 at 4:40:50 PM UTC-4, Jake Hamby (Solid State Jake) wrote:
> I've experienced a few terminal detection issues with SET TERM/INQ, so I decided to track them down and figure out what was going on.
>
> First, xterm: it continues to be updated with new features and bug fixes, and the current version claims to be a VT420. When I run "set term/inq", it pauses for a few seconds, then is unable to get the terminal size.
>
> Logging what VMS sends to a file, I see this sequence:
>
> CSI c -> query primary device attributes
> CSI " v -> DECRQDE (times out)
> CSI 62"p -> set to VT200+, 8-bit controls
> ESC <space> F -> select 7-bit controls (S7C1T)
> ESC > -> keypad numeric mode (DECKPNM)
>
> So the problem is that VT400 terminals should support DECRQDE (request displayed extent) to request the window width and height, as well as the column number of the leftmost column, line number of the top line, and the page number.
>
> I don't think any Linux terminal emulator supports DECRQDE, especially since there's a different xterm escape sequence to get window size that UNIX normally uses and all the GUI terminal emulators support. "vttest" can test DECRQDE, although it's listed as a VT320 feature, not a VT420 one.
>
> I have a different issue with Ubuntu's GNOME terminal. It claims to be a VT500 series, so SET TERM/INQ behaves a bit differently:
>
> CSI c -> query primary device attributes
> ESC 7 -> save cursor state
> CSI 255;255H -> set cursor pos. to 255,255
> CSI 6n -> ask for cursor pos. report
> ESC 8 -> restore cursor state
> CSI 62"p -> set to VT200+, 8-bit controls
> ESC <space> F -> select 7-bit controls (S7C1T)
> ESC > -> DECKPNM: keypad characters
>
> With this sequence, OpenVMS does correctly get the window width and height from gnome-terminal, but then I run into a different bug. "show term" shows the terminal is in 8-bit mode, but the 8-bit controls don't work, so when I run "edit" or "monitor", I see visible ESC sequences that don't work. The workaround I found is to "set term/noeight" before or after the /inq.
>
> I'll work on a patch for xterm to add support for DECRQDE, but it looks like these issues can be fixed entirely on the VMS side, by using the VT500 sequence to get the window size on VT400 series terminals, and by not selecting 7-bit C1 control chars immediately after setting 8-bit controls.
>
> Best regards,
> Jake Hamby
CSI 6n is a VT100 sequence (actually ECMA-48 CPR, not just DEC).
GNOME-Terminal's identifying itself as a VT520 should be taken with a grain of salt.
It doesn't support NRCS, for instance (seen in the DA response).
Nor does it implement DECSCL (used in your example).

I added the DECRQDE test in vttest in August 1996, but was not at that time interested in adding it to xterm.
But the reason for changing xterm to identify as VT420 is in the FAQ:

https://invisible-island.net/xterm/xterm.faq.html#why_vt420

Eleven years passed before anyone commented on this feature, since I changed the DA response in 2012:

https://invisible-island.net/xterm/xterm.log.html#xterm_279

XTerm Control Sequences

https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

lists the sequences that xterm recognizes.

On Wednesday, October 11, 2023 at 2:38:36 PM UTC-7, Thomas Dickey wrote:
>
> CSI 6n is a VT100 sequence (actually ECMA-48 CPR, not just DEC).
> GNOME-Terminal's identifying itself as a VT520 should be taken with a grain of salt.
> It doesn't support NRCS, for instance (seen in the DA response).
> Nor does it implement DECSCL (used in your example).
>
> I added the DECRQDE test in vttest in August 1996, but was not at that time interested in adding it to xterm.
> But the reason for changing xterm to identify as VT420 is in the FAQ:
>
> https://invisible-island.net/xterm/xterm.faq.html#why_vt420
>
> Eleven years passed before anyone commented on this feature, since I changed the DA response in 2012:
>
> https://invisible-island.net/xterm/xterm.log.html#xterm_279
>
> XTerm Control Sequences
>
> https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
>
> lists the sequences that xterm recognizes.

Thank you so much for providing the links and the relevant history of xterm development!

Regards,
Jake Hamby

On Wednesday, October 11, 2023 at 1:38:20 PM UTC-4, Jake Hamby (Solid State Jake) wrote:
> On Wednesday, October 11, 2023 at 2:11:14 AM UTC-7, Johnny Billquist wrote:
> >
> > I would set it to answer as a VT220. Then you have most of the "modern"
> > capabilities, but not some of the more fancy stuff that came later. I
> > think the VT220 emulation is much more complete in xterm.
> > Main thing lacking is just soft fonts, as far as I can remember.
> I'll definitely need to do some exploration with VTTEST. The current xterm claims that it can emulate anything from a VT52 to a VT525, but it's missing features like soft fonts, as well as the VT400 request displayed extent (DECRQDE) command that led to my investigation.
>
> If I run xterm with "-ti vt220" or "-ti vt320", then I don't have any problems. I'll try to find some time this week, when I'm not job hunting, to work on a patch for xterm to add the missing feature, and check to see if xterm really implements every feature that it claims to support in device attributes.
>
> Cheers,
> Jake
I added a DECRQDE last night (xterm doesn't provide dual sessions, but screensize is simple).
That'll be in #387 in a few days, since I have a minor regression in a different feature.