Conversation
| break; | ||
| case EscActionCodes::DECID_IdentifyDevice: | ||
| success = _dispatch->DeviceAttributes(); | ||
| TermTelemetry::Instance().Log(TermTelemetry::Codes::DA); |
There was a problem hiding this comment.
Note that I've reused the DA telemetry code here, since this is essentially an alias for the Device Attributes report, but I'd be happy to create a separate telemetry code for it if that's preferable.
There was a problem hiding this comment.
meh, it's not like that's used for anything anyways 😛
| break; | ||
| case EscActionCodes::DECID_IdentifyDevice: | ||
| success = _dispatch->DeviceAttributes(); | ||
| TermTelemetry::Instance().Log(TermTelemetry::Codes::DA); |
There was a problem hiding this comment.
meh, it's not like that's used for anything anyways 😛
carlos-zamora
left a comment
There was a problem hiding this comment.
Wow, that was pretty straightforward haha
|
Hello @DHowett! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
🎉 Handy links: |
This PR adds support for the `DECID` (Identify Device) escape sequence, which allows for querying the terminal type in a way that is backwards compatible with VT52 terminals. This simply checks for the `ESC Z` sequence in the `ActionEscDispatch` method of output state machine, and forwards the query to the existing `DeviceAttributes` dispatch method, since the expected response is identical to a `DA` report. ## Validation Steps Performed I've added an output engine test that verifies that the `ESC Z` sequence is correctly interpreted as a `DA` query when in ANSI mode, and as a VT52 identification query when in VT52 mode. Closes microsoft#8857
This PR adds support for the
DECID(Identify Device) escape sequence,which allows for querying the terminal type in a way that is backwards
compatible with VT52 terminals.
This simply checks for the
ESC Zsequence in theActionEscDispatchmethod of output state machine, and forwards the query to the existing
DeviceAttributesdispatch method, since the expected response isidentical to a
DAreport.Validation Steps Performed
I've added an output engine test that verifies that the
ESC Zsequenceis correctly interpreted as a
DAquery when in ANSI mode, and as aVT52 identification query when in VT52 mode.
Closes #8857