vt: Xterm modifyOtherKeys can't be detected

[aymanbagabas]

Issue Description

Ghostty supports Xterm modifyOtherKeys mode 1 out-of-box and always on and mode 2 after enabling it. However, there's no way to query and or detect support for this. CSI ? 4 m doesn't report the current active mode. Mode 1 is always active and cannot be disabled (separate issue if we want that to be controlled). Since Ghostty supports modifyOtherKeys, it should report the current active mode via CSI ? 4 m.

Expected Behavior

Respond to CSI ? 4 m with either CSI > 4 ; 1 m (default) or CSI > 4 ; 2 m when mode 2 is active.

Actual Behavior

Ghostty doesn't respond to modifyOtherKeys queries CSI ? 4 m

Reproduction Steps

1. Open Ghostty
2. Run cat | printf '\x1b[?4m
3. Observe no response
4. Run cat -e and type shift+enter to see Ghostty supports mode 1 by default
5. Run printf '\x1b[>4;2m' && cat -e and type any key to see Ghostty supports mode 2 after enabling it

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS Tahoe 26.5.2

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

N/A

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[j4james]

Just a word of warning. It's preferable to report XTQMODKEYS via a DECRQSS query, because CSI ? 4 m is technically a private SGR sequence, which has been used in the past to indicate a superscript rendition. An app that is using the sequence in that context would not be expecting a response from the terminal. I don't think it was widely used, but it is still a risk you should be aware of.

And at the very least, I'd encourage you to support the DECRQSS query in addition to the SGR sequence if you still choose to go ahead with that.

[aymanbagabas]

Good point! I will add support for DECRQSS XTQMODKEYS report