Add basic support for the DECRQSS settings query #11152
Conversation
| @@ -141,6 +141,8 @@ class Microsoft::Console::VirtualTerminal::ITermDispatch | |||
| const DispatchTypes::DrcsFontUsage fontUsage, | |||
| const VTParameter cellHeight, | |||
| const DispatchTypes::DrcsCharsetSize charsetSize) = 0; // DECDLD | |||
|
|
|||
| virtual StringHandler RequestSetting() = 0; // DECRQSS | |||
There was a problem hiding this comment.
/cc @oising we were chatting about how to indicate what "sub-things" we support for things that have multiple .. well, sub-things.
| const auto iterator = std::back_insert_iterator(response); | ||
| if (color.IsIndex16()) | ||
| { | ||
| const auto index = XtermToWindowsIndex(color.GetIndex()); |
There was a problem hiding this comment.
Is this conversion backwards? Won't GetIndex() return the windows index, which we'll want to use as a VT index?
There was a problem hiding this comment.
Semantically yes, but in practice it's a bidirectional operation (if that's the right term). It's just swapping bits 0 and 2. I suppose we could create a couple of aliases for these functions to makes things more readable, but I really would like to just get rid of them one day.
There was a problem hiding this comment.
well I'll be danged, that does happen to work the other way, doesn't it
| const auto id = idBuilder->Finalize(ch); | ||
| switch (id) | ||
| { | ||
| case VTID('m'): |
There was a problem hiding this comment.
Why'd we use the raw constants here instead of the predefined ones like SGR_SetGraphicsRendition? Is it just because they live in an annoying-to-get-to place?
There was a problem hiding this comment.
Yeah, I would have liked to use them. But maybe we can move them somewhere more accessible at some point in the future.
|
Thanks for doing this! |
DHowett
added
the
AutoMerge
|
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 (
|
ghost
merged commit 
|
🎉 Handy links: |
This PR adds support for querying the color indices set by the `DECAC` control, using the existing `DECRQSS` implementation. ## References and Relevant Issues The initial `DECRQSS` support was added in PR #11152. The `DECAC` functionality was added in PR #13058, but at the time we didn't know how to format the associated `DECRQSS` query. ## Detailed Description of the Pull Request / Additional comments For most `DECRQSS` queries, the setting being requested is identified by the final characters of its escape sequence. However, for the `DECAC` settings, you also need to include a parameter value, to indicate which color item you're querying. This meant we needed to extend the `DECRQSS` parser, so I also took this opportunity to ensure we correctly parsed any parameter prefix chars. We don't yet support any setting requiring a prefix, but this makes sure we don't respond incorrectly if an app does query such a setting. ## Validation Steps Performed Thanks to @al20878, we've been able to test how these queries are parsed on a real VT525 terminal, and I've manually verified our implementation matches that behavior. I've also extended the existing `DECRQSS` unit test to confirm that we are responding to the `DECAC` queries as expected. Closes #13091
This PR adds support for querying the cursor style - technically the state of the `DECSCUSR` setting - using a `DECRQSS` escape sequence. ## References and Relevant Issues The initial `DECRQSS` support was added in PR #11152, but it wasn't practical to report the cursor style until conpty passthrough was added in PR #17510. ## Detailed Description of the Pull Request / Additional comments If the user has chosen a cursor style that isn't one of the shapes supported by the `DECSCUSR` control, we report those as 0 (i.e. the default style). That way, if an application later tries to restore the cursor using the returned value, it should still be reset to its original state. I also took the opportunity in this PR to do some refactoring of the other `DECRQSS` reports, since several of them were using unnecessary appending that could be simplified to a single `fmt::format` call, or even just static strings in some cases. ## Validation Steps Performed I've checked the reports are working as expected in Vttest, and also added some unit tests. ## PR Checklist - [x] Tests added/passed
This PR adds support for the
DECRQSS(Request Selection or Setting)escape sequence, which is a standard VT query for reporting the state of
various control functions. This initial implementation only supports
queries for the
DECSTBMmargins, and theSGRgraphic renditionattributes.
This can be useful for certain forms of capability detection (#1040). As
one example in particular, it can serve as an alternative to the
COLORTERMenvironment variable for detecting truecolor support(#11057).
Of the settings that can be queried by
DECRQSS, the only other onethat we could be supporting at the moment is
DECSCUSR(Cursor Style).However, that would require passing the query through to the conpty
client, which is a lot more complicated, so I thought it best to leave
for a future PR.
For now this gets the basic framework in place, so we are at least
responding to queries, and even just supporting the
SGRattributesquery is useful in itself.
Validation
I've added a unit test verifying the reports for the
DECSTBMandSGRsettings with a range of different parameters. I've also tested the
DECSTBMandSGRreports manually in Vttest, under menu 11.2.5.3.6(Status-String Reports).