Yeah, so this needs more work. Results on macOS:

So the pointer appears in the bottom-right corner, which makes it turn into the resize pointer shape.

I've done some debugging:

SDL bug perhaps?

Confirmed working OK here on Linux w/ a slightly raised DPI, using both output opengl and texture.

Edit: I was using X11 which @GranMinigun mentioned:

kcgen, no point in testing DPI-related stuff in X11 session. No such concept there.

Posting results from Wayland.

@GranMinigun: You have to switch to Wayland session, yes, as DPI scaling concept exists only there.

PR is working great on XWayland with DPI scaling:

Using SDL_VIDEODRIVER=wayland, the released cursor appears in the original place it was captured (so perhaps, mouse warp doesn't work there):

This is perfect fine; if that's how Wayland does things, then it's probably true for anything that captures the mouse for exclusive control as well.

Using SDL_VIDEODRIVER=wayland, the released cursor appears in the original place it was captured (so perhaps, mouse warp doesn't work there):

Really strange - works for me. SDL2 v2.26.5, Plasma 5.27.5, KDE frameworks 5.106.0, Wayland 1.22.0

Using SDL_VIDEODRIVER=wayland, the released cursor appears in the original place it was captured (so perhaps, mouse warp doesn't work there):

Really strange - works for me. SDL2 v2.26.5, Plasma 5.27.5, KDE frameworks 5.106.0, Wayland 1.22.0

Looks like I'm behind everywhere: SDL2 2.26.3, Plasma 5.27.4, KDE frameworks 5.104.0, and Wayland 1.21.0.

These packages are still improving, and I guess there have been mouse position-related improvements made after the versions I'm running.

So long as the code on our side has the correct meaning, then we'll just let the user-space catch up eventually.

@kcgen Sorry, I was wrong - indeed, it gets released at the place where it was captured. I must have misspelled something during my previous test.

@kcgen Sorry, I was wrong - indeed, it gets released at the place where it was captured. I must have misspelled something during my previous test.

Oh, interesting! Maybe this is going to be the intended behavior of SDL 2.x on Wayland (or it'll change in 3.x; looks like other Wayland mouse position tickets are now scheduled to be addressed in the 3.x timeframe like: libsdl-org/SDL#1836)

So ifdef this out for Apple and possibly raise an SDL bug report?

So ifdef this out for Apple and possibly raise an SDL bug report?

yup - @FeralChild64's got the change isolated to WIN32 now.

I was checking in SDL2's repo and noticed this one with a possible solution, libsdl-org/SDL#7245, however that's for SDL3 :-)!

The 2.28 release (already in RC1) is their final release for the 2.x series, so I suspect we've missed the boat. Given it's a one-liner, not a big deal to carry until we can migrate to SDL3.

(But maybe it's worth reporting anyway; I don't feel like it though.. given they are migrating to SDL3 and have punted many DPI issues into 3.x already).

So ifdef this out for Apple and possibly raise an SDL bug report?

yup - @FeralChild64's got the change isolated to WIN32 now.

I was checking in SDL2's repo and noticed this one with a possible solution, libsdl-org/SDL#7245, however that's for SDL3 :-)!

The 2.28 release (already in RC1) is their final release for the 2.x series, so I suspect we've missed the boat. Given it's a one-liner, not a big deal to carry until we can migrate to SDL3.

(But maybe it's worth reporting anyway; I don't feel like it though.. given they are migrating to SDL3 and have punted many DPI issues into 3.x already).

So we're planning to migrate SDL3 soon?

So we're planning to migrate SDL3 soon?

Not us.. (we still have to merge @GranMinigun 's branch post 0.81, then wait for things to stabilize in SDL 3, which might be some years).

But SDL devs are migrating! They've finalized the 2.x feature set and 2.28 will be their last release in the 2.x series.

Also, they have punted very old 2.x DPI-related issues (ones that have been open since 2016) into the 3.x series.. never to be fixed in 2.x.

It's a bit line someone reporting an issue against Staging 0.79. we won't be releasing 0.79.2.. likewise, I don't think we can expect fresh 2.x bugs to be fixed. Instead, we'll just wait for 3.x, which reworks DPI handling from the ground up.

Nice quick fix @FeralChild64.

For what it's worth, there's going to be an SDL2 -> SDL3 compatibility layer (similar to what they did for SDL1 -> SDL2 except this time it's going to available from day 1) so we're not necessarily "stuck" with any SDL bugs. When SDL 3 releases, we should just be able to link to the compat library and benefit from bug fixes (or have end users link dynamically, I believe it even works with the same binary).

@kcgen, bugs are meant to be reported, and SDL 2.28 will be supported for some time and will receive patch releases (2.28.x). Whether that specific behaviour will be addressed in SDL 2 or 3 is up to them, of course, but unless there's an open bug report already, we ought to let them know about inconsistency in behaviour between different platforms. We all want SDL to be better, don't we?

@kcgen, bugs are meant to be reported, and SDL 2.28 will be supported for some time and will receive patch releases (2.28.x). Whether that specific behaviour will be addressed in SDL 2 or 3 is up to them, of course, but unless there's an open bug report already, we ought to let them know about inconsistency in behaviour between different platforms. We all want SDL to be better, don't we?

I agree, this should be reported... by someone else than me as I'm busy with other stuff :ducks:

Yup, I agree too.

( but I also won't be opening it because I'm not well versed in this area, and there's too much going on here to break out a side project and make a stand alone repro case, check if latest SDL 2.28 rc1 on a Win VM is affected, etc).

I'm also not about to (t)ask anyone to do it: but if it gets done, great and thank you 👏 !

Fine, I'll do it myself.

@GranMinigun Thank you. It would be hard for me to provide support for the SDL team, as I’m a Linux-only user.

@GranMinigun , your ticket and repro code were so good, slouken was able to fix it immediately. 🤯 🥇