SDL_WINDOW_HIGH_PIXEL_DENSITY is ignored on Linux when using Wayland

[JustinWayland]

This has been a bug affecting SDL since SDL2, but it wasn't caught because SDL2 defaulted to X11, where this was implemented correctly. With the default now being Wayland on Linux, this has officially become a problem, especially since Arch Linux recently swapped out SDL2 with sdl2-compat, which resulted in fun times when I tried to use Woof! at 1917x1080 on a 2560x1600 display at 150% scaling.

[Kontrabant]

What exactly is the issue here? X11 doesn’t support high-DPI scaled desktops, while Wayland does, and using that property requires handling a back buffer with a different size from the logical window dimensions, same as on Mac.

[JustinWayland]

OK, maybe I'm explaining this wrong.

I'm using Woof! to demonstrate this bug, as it was the program I found the bug on when Arch switched out SDL2 for sdl2-compat.

Woof! is set to 1080p in both of these screenshots.
The first was taken with the desktop scaling set to 100%.

The second was taken with the desktop scaling set to 150%.

I thought that if you used SDL_WINDOW_HIGH_PIXEL_DENSITY, as SDL2-compat ends up doing when translating SDL_WINDOW_ALLOW_HIGHDPI, those two should be close to the same size, but if you download both of these images, you will pretty quickly see that they have very different resolutions.

[JustinWayland]

See also #12079.

Note in particular that setting SDL_VIDEO_WAYLAND_SCALE_TO_DISPLAY=1 fixes the issue. I can confirm this also fixes what happens with Woof! as well under sdl2-compat.

From the documentation for that hint:

When this hint is set, Wayland windows that are not flagged as being DPI-aware will be output with scaling designed to force 1:1 pixel mapping.

I would also like to note that in Woof!'s source code here, the SDL2 equivalent of SDL_WINDOW_HIGH_PIXEL_DENSITY, which is called SDL_WINDOW_ALLOW_HIGHDPI, is passed into the CreateWindow call.

This is also only an issue under Wayland, as setting SDL_VIDEO_DRIVER=x11 also fixes the issue.

Hopefully this is enough that someone can triangulate the bug.

[JustinWayland]

OK, I apologize. I actually read up on high DPI. It seems that this is intentional. I might be being unreasonable.

sdl2-compat's approach seems reasonable.

Sorry for the annoyed tone of voice I had earlier.

Leaving this issue open for others to comment on, but close at the maintainer's discretion.

EDIT: That being said, this seems really inconvenient for gamedev, where you are expecting to get actual physical pixels back.

[slouken]

Okay, let me see if I understand this correctly:

• The application is asking for a high DPI window
• The application is getting a high DPI window, which by definition has the real pixel size, as distinct from the desktop coordinate system
• You're surprised that you're getting more pixels

Is that right? If that's the case, then I think this is working as intended.

[Reonu]

Hello, I'm not 100% sure if this is the right issue to ask, but we're having an issue where our SDL2 game looks sharp and pixel-perfect via xWayland on a Wayland session set to 125% scaling, but when running it in native Wayland mode, the game is now blurry. DPI scaling works correctly on Windows too. We're wondering if we're missing a hint or something to make sure the window is DPI aware on Linux with native Wayland. Could you point me in the right direction?