bash window not respecting scaling settings

[smacdonald-kai]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

$ git --version --build-options
git version 2.53.0.windows.1
cpu: x86_64
built from commit: a5512bdee37ed7142c233d21e2d347ffc4860ff3
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
gettext: enabled
libcurl: 8.18.0
OpenSSL: OpenSSL 3.5.5 27 Jan 2026
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1

Windows version

Windows 11

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.26200.7623]
(c) Microsoft Corporation. All rights reserved.

Options set during installation

$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Default Branch Option: main
Path Option: CmdTools
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: FFOnly
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled

Other interesting things

I have a laptop with two external monitors:

Monitor 1 is the laptop's built in screen and is set:

Monitor 2 & 3 are both:

Monitor 3 is set as Primary.

This has been an issue since 2.49.0.

I've had a variety of issues with the 4K builtin monitor, scaling, and moving things to/from external monitors FHD monitors. This specific one is just easily reproducible.

This may very well be a Windows issue and not a Git for Windows issue.

Terminal/shell

Git for Windows' bash, started from the "Search" bar.

Commands that trigger the issue

I start a bash instance. It spawns on Monitor 3^^. I move it around with Windows' win-shift-arrow keychord.

If non-maximized, moving to Monitor 1 results in the title bar being okay, but the text in the terminal being super-tiny.
Moving back to Monitor 3 fixes the problem.

If maximized, moving to Monitor 1 results in tiny text and a tiny title bar. Actually, I just noticed that the scrollbar is also tiny.
Moving back to Monitor 3 fixes the text but results in what looks like 3x title bar and scrollbar.
Hm. Perhaps the scaling is _not_ applied on the initial move to Monitor 1, but _is_ undone in the move back to Monitor 3?
Un-maximizing and re-maximizing on Monitor 3 fixes the 3x title bar and scrollbar.

^^I don't know how to force Windows to spawn an application on a specific monitor, so I can't test [ the first move is from Monitor 1 to Monitor 3 ].

Expected behaviour

Scaling is always respected/obeyed. Text looks "normal" on Monitor 1 instead of tiny. Title bar and scrollbar never accidentally become 3x their usual size.

Actual behaviour

See above. This is 100% reproducible.

Repository

No repo involved.

[dscho]

@mintty is this a MinTTY bug?

[mintty]

I don't know how to force Windows to spawn an application on a specific monitor,

mintty has options for that, e.g. -o @N where N is a monitor number. Please try if scaling appears properly if started on directly on the high-resolution monitor (assuming that's not monitor 3 for you).

is this a MinTTY bug?

I cannot tell precisely as I don't have a 4K monitor for testing. I hope not. Mintty is DPI-aware and rescales when moving between different-dpi monitors in general.

[mintty]

Just had one idea: in MSYS2 and thus Git, mintty is wrapped into a binary launcher (and an additional cmd launcher).
Please check whether that launcher has dpi support declared by manifest, as original mintty has. See file res.mft in the mintty repository for this.
@smacdonald-kai, please check whether the same issue occurs if you invoke mintty directly, from the usr/bin subdirectory of the installation folder.

[dscho]

@mintty comparing https://github.com/mintty/mintty/blob/master/src/res.mft to what is in https://github.com/git-for-windows/git-sdk-64/blob/HEAD/usr/bin/mintty.exe, it sounds as if you're totally on the right track:

diff --git a/mintty.mft b/g4w.mft
index 8a2d718976..b0df3c7b97 100644
--- a/mintty.mft
+++ b/g4w.mft
@@ -13,9 +13,8 @@
     </dependentAssembly>
   </dependency>
   <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
-    <asmv3:windowsSettings>
-      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
-      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
+    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
+      <dpiAware>true</dpiAware>
     </asmv3:windowsSettings>
   </asmv3:application>
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

This is actually identical to the mintty.exe version MSYS2 has. Looking a bit further, I see that the change in question was introduced by mintty/mintty@0f61029, which is only on master, but not in any MinTTY release yet. MSYS2 has the latest release, v3.8.1, which does not contain that commit: mintty/mintty@3.8.1...master

@mintty any plans on releasing any time soon?

[mintty]

Oops, I wasn't aware that this change hasn't been released yet. On the other hand, I had thought it would be only a cosmetic change while the actual functionality was already in the code since 2.9.0 ("Enhanced multi-monitor DPI handling") but maybe I was wrong.

any plans on releasing any time soon?

Yes, this week.

The question remains whether the binary wrapper would need its own corresponding manifest, and whether that might even fix the issue on its own.

[dscho]

The question remains whether the binary wrapper would need its own corresponding manifest, and whether that might even fix the issue on its own.

Excellent question. @smacdonald-kai you have a uniquely suited setup to test this, please do so.

[smacdonald-kai]

mintty has options for that, e.g. -o @N where N is a monitor number. Please try if scaling appears properly if started on directly on the high-resolution monitor (assuming that's not monitor 3 for you).

The -o method did not work for me, but, mintty -p @1 did. (There is a bug with the @N option though, see #6093)

I am doing my reproduction steps "in reverse" in terms of the movement of the terminal between monitors. Otherwise the same steps in the same order.

[ Starting the terminal directly on the 4K built-in monitor via mintty -p @1 ]
Non-maximized, moving between all monitors works as expected. Scaling is always respected, and, the terminal appears roughly the same size everywhere. Nice!

When I maximize the terminal and retry, there is a bug: when moving off the 4K (Monitor 1) to Monitor 3, the terminal shrinks to a small box, located in the top left (at 0,0 I think), with part of the title bar and text off-screen. Screenshot attached (it's a full all-monitors screenshot, monitors ordered 3, 1, 2).
This behaviour undoes/resets when moving back to Monitor 1, or when using win-arrow keychords to change the size. hm The behaviour is always present when: maximize on the 4K (Monitor 1), win-shift-rightarrow.
The behaviour also resets if I left-click-and-drag the window by its title bar.

I cannot tell precisely as I don't have a 4K monitor for testing. I hope not. Mintty is DPI-aware and rescales when moving between different-dpi monitors in general.

I am a programmer and willing to test things. Windows/UI development is not my normal area but I've taken on a job that involves this and am learning a bunch of stuff on the fly. Happy to "lend" my 4K situation.

[smacdonald-kai]

Just had one idea: in MSYS2 and thus Git, mintty is wrapped into a binary launcher (and an additional cmd launcher). Please check whether that launcher has dpi support declared by manifest, as original mintty has. See file res.mft in the mintty repository for this.

I'm not sure exactly what you mean. I have:

$ type mintty
mintty is /usr/bin/mintty

smacdonald@LAPTOP-SR3FLS49 MINGW64 ~
$ ls -alF /usr/bin/mintty
-rwxr-xr-x 1 smacdonald 197121 1256711 Feb  2 17:38 /usr/bin/mintty*

smacdonald@LAPTOP-SR3FLS49 MINGW64 ~
$ file /usr/bin/mintty
/usr/bin/mintty: PE32+ executable for MS Windows 5.02 (GUI), x86-64 (stripped to external PDB), 10 sections

I looked at https://github.com/mintty/mintty/blob/master/src/res.mft , seems reasonable. I found https://github.com/msys2/msys2-launcher but I don't know if that's the correct repository. It does not contain a res.mft file.

@smacdonald-kai, please check whether the same issue occurs if you invoke mintty directly, from the usr/bin subdirectory of the installation folder.

When starting with /usr/bin/mintty I see the same behaviour, whether or not I start it on a specific monitor, as when starting with the -p @1 option to start it on the 4K (Monitor 1). That is to say, when starting with the absolute path my original reported behaviour is not reproducible.

Edit: I forgot to mention. When starting with /usr/bin/mintty there's a small dialog that pops up asking to pick a shell: [ MSYS2 | Mingw-w64 32 bit | Minge-w64 64 bit ]. I only tried MSYS2.

[smacdonald-kai]

When starting from the Windows 11 search bar:
MSYSTEM=MINGW64

When starting from /usr/bin/mintty:
MSYSTEM=MSYS

I tried the other shell options when launching by absolute path and all three have the improved "launch directly" behaviour, not the original reported behaviour.

In fact, it looks like the original behaviour is only when starting via the Windows GUI: Search bar, Start Menu.

[dscho]

@smacdonald-kai you need to edit the manifest of the mintty.exe to find out, e.g. via https://learn.microsoft.com/en-us/dotnet/framework/tools/mage-exe-manifest-generation-and-editing-tool (I think that should work even on MSYS executables).

[dscho]

@smacdonald-kai you need to edit the manifest of the mintty.exe to find out, e.g. via https://learn.microsoft.com/en-us/dotnet/framework/tools/mage-exe-manifest-generation-and-editing-tool (I think that should work even on MSYS executables).

[dscho]

@smacdonald-kai you need to edit the manifest of the mintty.exe to find out, e.g. via https://learn.microsoft.com/en-us/dotnet/framework/tools/mage-exe-manifest-generation-and-editing-tool (I think that should work even on MSYS executables).

[smacdonald-kai]

@smacdonald-kai you need to edit the manifest of the mintty.exe to find out, e.g. via https://learn.microsoft.com/en-us/dotnet/framework/tools/mage-exe-manifest-generation-and-editing-tool (I think that should work even on MSYS executables).

I have mage/mageui but appears to only operate on .NET applications.

$ file '/c/Program Files/Git/usr/bin/mintty.exe'
/c/Program Files/Git/usr/bin/mintty.exe: PE32+ executable for MS Windows 5.02 (GUI), x86-64 (stripped to external PDB), 10 sections

mageui throws an "unrecognised" file error anyway, when opening mintty.exe.

[dscho]

I have mage/mageui but appears to only operate on .NET applications.

I feared as much. Do you have mt.exe (as part of a Visual Studio installation, for example)?