Re: [PATCH] sdl2: fix HighDPI display scaling

> 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 chang=
es,
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 filt=
ering
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=E2=80=AFAM 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 logica=
l
> > 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 |=3D SDL_WINDOW_OPENGL;
> >     }
> > #endif
> > -
> > +    flags |=3D SDL_WINDOW_ALLOW_HIGHDPI;
> >     scon->real_window =3D SDL_CreateWindow("", SDL_WINDOWPOS_UNDEFINED,
> >                                          SDL_WINDOWPOS_UNDEFINED,
> >                                          surface_width(scon->surface),
> > @@ -907,6 +907,7 @@ static void sdl2_display_init(DisplayState *ds, Dis=
playOptions *o)
> >     char *dir;
> >
> >     assert(o->type =3D=3D 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);
> >