Add support for the DECREQTPARM report #7852
Labels
Area-VT
Virtual Terminal sequence support
Issue-Task
It's a feature request, but it doesn't really need a major design.
Needs-Tag-Fix
Doesn't match tag requirements
Product-Conhost
For issues in the Console codebase
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Comments
j4james
added
the
Issue-Feature
ghost
added
Needs-Triage
|
Happy indeed to include it. 😄 |
DHowett
added
Area-VT
DHowett
pushed a commit
that referenced
this issue
Oct 15, 2020
This PR adds support for the `DECREQTPARM` (Request Terminal Parameters) escape sequence, which was originally used on the VT100 terminal to report the serial communication parameters. Modern terminal emulators simply hardcode the reported values for backward compatibility. The `DECREQTPARM` sequence has one parameter, which was originally used to tell the terminal whether it was permitted to send unsolicited reports or not. However, since we have no reason to send an unsolicited report, we don't need to keep track of that state, but the permission parameter does still determine the value of the first parameter in the response. The response parameters are as follows: | Parameter | Value | Meaning | | ---------------- | ------ | ------------------------ | | response type | 2 or 3 | unsolicited or solicited | | parity | 1 | no parity | | data bits | 1 | 8 bits per character | | transmit speed | 128 | 38400 baud | | receive speed | 128 | 38400 baud | | clock multiplier | 1 | | | flags | 0 | | There is some variation in the baud rate reported by modern terminal emulators, and 9600 baud seems to be a little more common than 38400 baud, but I thought the higher speed was probably more appropriate, especially since that's also the value reported by XTerm. ## Validation Steps Performed I've added a couple of adapter and output engine tests to verify that the sequence is dispatched correctly, and the expected responses are generated. I've also manually tested in Vttest and confirmed that we now pass the `DECREQTPARM` test in the _Test of terminal reports_. Closes #7852
ghost
added
Needs-Tag-Fix
DHowett
pushed a commit
that referenced
this issue
Oct 19, 2020
This PR adds support for the `DECREQTPARM` (Request Terminal Parameters) escape sequence, which was originally used on the VT100 terminal to report the serial communication parameters. Modern terminal emulators simply hardcode the reported values for backward compatibility. The `DECREQTPARM` sequence has one parameter, which was originally used to tell the terminal whether it was permitted to send unsolicited reports or not. However, since we have no reason to send an unsolicited report, we don't need to keep track of that state, but the permission parameter does still determine the value of the first parameter in the response. The response parameters are as follows: | Parameter | Value | Meaning | | ---------------- | ------ | ------------------------ | | response type | 2 or 3 | unsolicited or solicited | | parity | 1 | no parity | | data bits | 1 | 8 bits per character | | transmit speed | 128 | 38400 baud | | receive speed | 128 | 38400 baud | | clock multiplier | 1 | | | flags | 0 | | There is some variation in the baud rate reported by modern terminal emulators, and 9600 baud seems to be a little more common than 38400 baud, but I thought the higher speed was probably more appropriate, especially since that's also the value reported by XTerm. ## Validation Steps Performed I've added a couple of adapter and output engine tests to verify that the sequence is dispatched correctly, and the expected responses are generated. I've also manually tested in Vttest and confirmed that we now pass the `DECREQTPARM` test in the _Test of terminal reports_. Closes #7852 (cherry picked from commit 30e363e)
|
🎉This issue was addressed in #7939, which has now been successfully released as Handy links: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the new feature/enhancement
DECREQTPARMwas a sequence used on the VT100 to report the serial communication parameters - things like baud rate, parity, etc. There's absolute no use for it nowadays, and I don't think it was even supported on later DEC terminals, but it seems to be quite widely implemented by modern terminal emulators. This includes XTerm (in VT100 mode), VTE (since around v0.53.0 I think), Konsole, Urxvt, Mintty, and many others.I have no idea why everyone supports it, but I'd like for us to do so too. It's an easy addition, and If nothing else, it lets us pass another test in Vttest.
Proposed technical implementation details (optional)
It's fairly straightforward to implement. Everyone just returns a hard coded response (technically two responses, since the first response value depends on the request parameter). I've got a PR ready to go if you're happy to include it, but it's branched from PR #7799, so I'm waiting for that to merge first.
The text was updated successfully, but these errors were encountered: