Re: [PATCH] sdl2: fix HighDPI display scaling

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--3866299591-1858572498-1785529727=:2229
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Fri, 31 Jul 2026, Oliver C wrote:
> I added a scale option for sdl that works the same as gtk.
> I said linear filtering in my last response, but I meant point
> filtering. I played around with point filtering,
> but it looks pretty bad with non-integer scaling (e.g. 150% scaling to
> match my setup). It does however
> look quite nice with an integer scale, so maybe this could be
> configurable as well?

I don't know what other ui backends do but if this makes it more 
consistent with at least gtk it sounds good and a scale options is useful 
in itself even without hiDPI. The ui maintainers should do a final review 
though.

> What's the process for amending a patch? Do I reply with the
> additional patches, reply with the whole patch, or create a new
> thread?

You should post a new thread if you revise a patch with v2 for the first 
revision after initial submission without version and increasing for later 
revisions but adding a scale option should be in a different patch so this 
makes it a series with two patches. Series should be submitted as replies 
to a cover letter with new thread for v2 and so on for revised series as 
well. This should be explained in 
https://www.qemu.org/docs/master/devel/submitting-a-patch.html

Thanks for improving QEMU.

Regards,
BALATON Zoltan

> Thanks,
> Oliver
>
> On Fri, Jul 31, 2026 at 1:32 PM Oliver C <[email protected]> wrote:
>>
>>> Does this mean that on hiDPI displays now a 640x480 guest screen
>>> (like BIOS or legacy guest) shows a tiny unusable window?
>>
>> This is correct, but:
>>
>>> ...the issue that other ui backends should do the same so just changing
>>> one backend may lead to inconsistency.
>>
>> the gtk backend exhibits the same behavior as the sdl backend with my changes,
>> i.e. it creates a 640x480 guest screen in physical pixels (my machine has a
>> 4k monitor with 150% scaling), just like the new changes. So these changes
>> in fact make it more consistent. Although, I just noticed that gtk has
>> a 'scale' option,
>> which scales the window size, and stretches the surface to it. I
>> suppose this can
>> be added to sdl. I think it would also be a good idea to enable linear filtering
>> when stretching the surface, so it doesn't look as blurry.
>>
>>> Despite the patch is just two lines maybe it's not a trivial change.
>>
>> Gotcha, sorry this is my first time sending a patch through mailing
>> list, so thanks for bearing with me.
>>
>> Oliver
>>
>> On Fri, Jul 31, 2026 at 7:05 AM BALATON Zoltan <[email protected]> wrote:
>>>
>>> On Thu, 30 Jul 2026, Oliver Clarke wrote:
>>>> This makes sdl2 windows work well with dpi scaling. It fixes the issue
>>>> of the display surface being stretched to fit the dpi corrected window
>>>> (which created a blurry result).
>>>>
>>>> Note, this does not do any scaling, it just tells the os to not scale
>>>> the window. Before, when the console requested size 640x480, the logical
>>>> size of the window was 640x480, and the physical size was scaled by the
>>>> dpi scaling. Now, both the logical and physical size will be 640x480.
>>>> This is unlike most dpi aware programs which usually do have the scaled
>>>> physical size, then also make the render target that scaled size as
>>>> well. This doesn't make as much sense for QEMU, since the guest is
>>>> responsible for modesetting, and they should get the exact physical
>>>> pixels they request (if i modeset to 3840x2160, I wouldn't want this to
>>>> be scaled in any way).
>>>
>>> Despite the patch is just two lines maybe it's not a trivial change. Does
>>> this mean that on hiDPI displays now a 640x480 guest screen (like BIOS or
>>> legacy guest) shows a tiny unusable window? In that case maybe this needs
>>> to be switchable with a property or turn off scaling of 4k and higher
>>> resolutions but then we get to the issue that other ui backends should do
>>> the same so just changing one backend may lead to inconsistency. Did you
>>> check how is this handled in other ui backends?
>>>
>>> Regards,
>>> BALATON Zoltan
>>>
>>>> Signed-off-by: Oliver Clarke <[email protected]>
>>>> ---
>>>> ui/sdl2.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/ui/sdl2.c b/ui/sdl2.c
>>>> index 1c97d23a47..1910477db4 100644
>>>> --- a/ui/sdl2.c
>>>> +++ b/ui/sdl2.c
>>>> @@ -102,7 +102,7 @@ void sdl2_window_create(struct sdl2_console *scon)
>>>>         flags |= SDL_WINDOW_OPENGL;
>>>>     }
>>>> #endif
>>>> -
>>>> +    flags |= SDL_WINDOW_ALLOW_HIGHDPI;
>>>>     scon->real_window = SDL_CreateWindow("", SDL_WINDOWPOS_UNDEFINED,
>>>>                                          SDL_WINDOWPOS_UNDEFINED,
>>>>                                          surface_width(scon->surface),
>>>> @@ -907,6 +907,7 @@ static void sdl2_display_init(DisplayState *ds, DisplayOptions *o)
>>>>     char *dir;
>>>>
>>>>     assert(o->type == DISPLAY_TYPE_SDL);
>>>> +    SDL_SetHint(SDL_HINT_WINDOWS_DPI_AWARENESS, "permonitorv2");
>>>>
>>>>     if (SDL_GetHintBoolean("QEMU_ENABLE_SDL_LOGGING", SDL_FALSE)) {
>>>>         SDL_LogSetAllPriority(SDL_LOG_PRIORITY_VERBOSE);
>>>>
>
>
--3866299591-1858572498-1785529727=:2229--