starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Update the Device Attributes report #19016

New Issue
Closed
opened 2026-01-31 06:31:17 +00:00 by claunia · 2 comments
claunia commented 2026-01-31 06:31:17 +00:00
Owner
Copy Link

Originally created by @j4james on GitHub (Dec 4, 2022).

Description of the new feature/enhancement

Up to now, we've been identifying as a VT100, since we haven't fully met the conformance requirements for any of the higher level devices. But with the recent support that's been added for several VT extensions, I think it's time to consider an updated DA response.

The structure of a DA report is as follows: the first parameter value indicates the conformance level with a number in the range 61 to 69 (representing levels 1 to 9); subsequent parameters indicate the supported feature extensions. The early VT terminals didn't follow this standard, but their initial DA parameter would have always been below 60.

We still don't meet the requirements for level 2, so the first parameter in our DA response will have to be 61. But we do now support a number of feature extensions, which we can indicate with additional parameter values. Some of the more useful ones include:

7 = Soft Fonts (since PR #13965)
28 = Rectangular Editing (since PR #14285)
32 = Text Macros (since PR #14402, if accepted)

Applications that wish to take advantage of these features would be able to do so automatically if they could tell from the DA report that the terminal supported the necessary extensions.

Proposed technical implementation details (optional)

Updating the DA report seems like it ought to be a trivial change. However, the complication for us is this it's handled on the conhost side, but it needs to take into account the capabilities of the conpty client. For example, conhost supports Soft Fonts, but they won't work over conpty unless the conpty client also supports them (and for Terminal that's dependent on the configured renderer).

My proposed solution for this is that we fire off a DA request to the conpty client on startup (similar to the way we sometimes send a CPR request on startup). We then save the relevant information from the client's response (for now just the Soft Font support), and use that to determine what features we can include in our DA response.

Does that seem like a reasonable approach to take?

Originally created by @j4james on GitHub (Dec 4, 2022). # Description of the new feature/enhancement Up to now, we've been identifying as a VT100, since we haven't fully met the conformance requirements for any of the higher level devices. But with the recent support that's been added for several VT extensions, I think it's time to consider an updated `DA` response. The structure of a `DA` report is as follows: the first parameter value indicates the conformance level with a number in the range 61 to 69 (representing levels 1 to 9); subsequent parameters indicate the supported feature extensions. The early VT terminals didn't follow this standard, but their initial `DA` parameter would have always been below 60. We still don't meet the requirements for level 2, so the first parameter in our `DA` response will have to be 61. But we do now support a number of feature extensions, which we can indicate with additional parameter values. Some of the more useful ones include: 7 = Soft Fonts (since PR #13965) 28 = Rectangular Editing (since PR #14285) 32 = Text Macros (since PR #14402, if accepted) Applications that wish to take advantage of these features would be able to do so automatically if they could tell from the `DA` report that the terminal supported the necessary extensions. # Proposed technical implementation details (optional) Updating the `DA` report seems like it ought to be a trivial change. However, the complication for us is this it's handled on the conhost side, but it needs to take into account the capabilities of the conpty client. For example, conhost supports _Soft Fonts_, but they won't work over conpty unless the conpty client also supports them (and for Terminal that's dependent on the configured renderer). My proposed solution for this is that we fire off a `DA` request to the conpty client on startup (similar to the way we sometimes send a `CPR` request on startup). We then save the relevant information from the client's response (for now just the _Soft Font_ support), and use that to determine what features we can include in our `DA` response. Does that seem like a reasonable approach to take?
claunia added the Help WantedProduct-ConhostIssue-TaskIn-PRArea-VTNeeds-Tag-Fix labels 2026-01-31 06:31:18 +00:00
claunia commented 2026-01-31 06:31:19 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 12, 2022):

Seems sensible to me, though, we might want to be careful to be sure that the client can reply. Maybe we should gate it on --inheritCursor? er. Maybe not. There was some WSL issue IIRC that precipitated the need for --inheritCursor, rather than passing it all the time. Like, some scenarios where there was nothing actually processing the input, so if ConPTY just waits on startup for a reply, conpty might just HANG if no one ever replies. We might need some sort of timeout on startup to have conpty bail if conpty fires off a DA and doesn't get a response.

Maybe we could just not block startup on this. Fire off the DA, and just keep going. If we get a reply, then great, if not, then just keep 'er movin.

@zadjii-msft commented on GitHub (Dec 12, 2022): Seems sensible to me, though, we might want to be careful to be sure that the client can reply. Maybe we should gate it on `--inheritCursor`? er. Maybe not. There was some WSL issue IIRC that precipitated the need for `--inheritCursor`, rather than passing it all the time. Like, some scenarios where there was nothing actually processing the input, so if ConPTY just waits on startup for a reply, conpty might just HANG if no one ever replies. We might need some sort of timeout on startup to have conpty bail if conpty fires off a `DA` and doesn't get a response. Maybe we could just not block startup on this. Fire off the `DA`, and just keep going. If we get a reply, then _great_, if not, then just keep 'er movin.
claunia commented 2026-01-31 06:31:19 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 12, 2022):

Maybe we should gate it on --inheritCursor? er. Maybe not.

Yeah, --inheritCursor isn't an option since it doesn't seem to get used most of the time, and this has to be called every time if we want it to work correctly every time.

We might need some sort of timeout on startup to have conpty bail if conpty fires off a DA and doesn't get a response.

That kind of sucks, because if that really is necessary, we're again left with a solution that isn't going to work some of the time. And any apps that rely on the DA information being correct are going to then have inconsistent behavior - sometimes they'll work and sometimes they won't.

I'd love to know under what conditions this is expected to fail, and whether that's fixable. Like could we maybe delay sending the DA request until the client has reached a certain steady state?

@j4james commented on GitHub (Dec 12, 2022): > Maybe we should gate it on `--inheritCursor`? er. Maybe not. Yeah, `--inheritCursor` isn't an option since it doesn't seem to get used most of the time, and this has to be called every time if we want it to work correctly every time. > We might need some sort of timeout on startup to have conpty bail if conpty fires off a `DA` and doesn't get a response. That kind of sucks, because if that really is necessary, we're again left with a solution that isn't going to work some of the time. And any apps that rely on the `DA` information being correct are going to then have inconsistent behavior - sometimes they'll work and sometimes they won't. I'd love to know under what conditions this is expected to fail, and whether that's fixable. Like could we maybe delay sending the `DA` request until the client has reached a certain steady state?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT Help Wanted In-PR Issue-Task Needs-Tag-Fix Product-Conhost
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#19016
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?