Per-monitor support was added to the code 10 years ago and seems to be working.
What benefit would this addition to the "manifest" have?

Also, see function set_per_monitor_dpi_aware in winmain.c:

    HRESULT hr = pSetProcessDpiAwareness(Process_Per_Monitor_DPI_Aware);
    // E_ACCESSDENIED:
    // The DPI awareness is already set, either by calling this API previously
    // or through the application (.exe) manifest.
    if (hr != E_ACCESSDENIED && !SUCCEEDED(hr))
      pSetProcessDpiAwareness(Process_System_DPI_Aware);

This comment suggests that extending the manifest may impact mintty at runtime, so this change needs thorough testing. As I have only one monitor, I would like to ask you to do such testing and confirm everything works fine with the change.

Additional question: the API also has function SetThreadDpiAwarenessContext which is also used by mintty - how is that related?

Yet another question:
Another manifest (https://gist.github.com/emoacht/7e5a026080aeb7eb1b9316f5fe7628da) has extended values for both parameters. Does that mean anything?

Yet another question: Another manifest (https://gist.github.com/emoacht/7e5a026080aeb7eb1b9316f5fe7628da) has extended values for both parameters. Does that mean anything?

Those are fallback settings for older versions of Windows in case they don't support the newer high DPI settings

Thanks for considering one of my questions. I did not mean to discourage the change or urge you to close it.
I just wanted some explanation which is always useful for an issue or even pull request.

Also, see function set_per_monitor_dpi_aware in winmain.c:

    HRESULT hr = pSetProcessDpiAwareness(Process_Per_Monitor_DPI_Aware);
    // E_ACCESSDENIED:
    // The DPI awareness is already set, either by calling this API previously
    // or through the application (.exe) manifest.
    if (hr != E_ACCESSDENIED && !SUCCEEDED(hr))
      pSetProcessDpiAwareness(Process_System_DPI_Aware);

This comment suggests that extending the manifest may impact mintty at runtime, so this change needs thorough testing. As I have only one monitor, I would like to ask you to do such testing and confirm everything works fine with the change.

Additional question: the API also has function SetThreadDpiAwarenessContext which is also used by mintty - how is that related?

Also, according to https://learn.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process, the manifest approach is recommended

OK, but does it interact with an API handling of DPI changes?
Can you please apply the change to your own github download of mintty and test it?
Building mintty is simple: you just need packages gcc-core and make, then run make in the src subdirectory.

OK, but does it interact with an API handling of DPI changes? Can you please apply the change to your own github download of mintty and test it? Building mintty is simple: you just need packages gcc-core and make, then run make in the src subdirectory.

Funny; I don't have a second monitor to test this either! But after applying my changes, DPI scaling works (tested at 200% scaling)

Thanks so far. The most delicate question I have in mind is the test case to move a window between two monitors with different DPI setting. This should be tested by someone before committing this change which otherwise looks fine.

I've tested this in Virtualbox with 2 virtual monitors. Merging, thank you.

Released 3.8.2.