Broken scaling of vkdt on wayland / high dpi / KDE

[vilim]

Since the move to the Nuklear GUI framework, the scaling of the interface is off (the screen is set to 200% scaling, but the interface looks in part at 400%, while still being blurry)

The build is vkdt-rawler-glfw3.4-0.8.99-106-gb47c911d-x86_64.AppImage KDE Plasma 6.0.5 on Wayland

[hanatos]

heya, thanks for reporting. this is going to be hard for me to reproduce, because nvidia on wayland does not even run vulkaninfo.

are you sure vkdt is running with wayland on your system? can you start it from a shell with vkdt -d all to see which extensions glfw actually loads?

i never understood the logic of this 200% scaling thing. vkdt scales its own gui in proportion to window height, this 2x scaling seems very legacy to me. i suppose this is a matter of carefully replacing glfwGetWindowSize by glfwGetFramebufferSize, context: https://stackoverflow.com/questions/44719635/what-is-the-difference-between-glfwgetwindowsize-and-glfwgetframebuffersize

[hanatos]

.. just for adventurous people who have laptops with mixed intel + nvidia, running this in foot/weston seems to work and at least start something vulkan:

XDG_SESSION_TYPE=wayland VK_DRIVER_FILES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json vkdt

of course only using the intel GPU. while slightly painful, i think i don't see any more scaling/dpi issues on a 4k laptop with intel/wayland. let me know if that fixed it for you too.

[vilim]

I unfortunately have only nVidia on this computer, no intel. This is what vkdt -d all returns

[gui] vkdt 0.8.99-106-gb47c911d (c) 2020--2024 johannes hanika
[gui] glfwGetVersionString() : 3.4.0 Wayland X11 GLX Null EGL OSMesa monotonic
[gui] monitor [0] DP-4 at 0 0
[gui] vk extension required by GLFW:
[gui]   VK_KHR_surface
[gui]   VK_KHR_wayland_surface
[gui] no joysticks found
[gui] no display profile file display.DP-4, using sRGB!

The 200% refers to the scaling settings of the window manager and are per-monitor, AFAIK it comes originally from Apple's method of implementing high DPI support which involved doubling the resolution of the displays and then introducing logical pixels which correspond to 4 device pixels. Will have a look at the GLFW code

[hanatos]

is the scaling still off for you after https://github.com/hanatos/vkdt/commit/f8abd5a9c6ef70d3209d2035804f8d6bd3983e40 ?

[hanatos]

i encountered something similar on a macintosh computer when trying this out. 22b2a46f fixed it there, i wonder if the issue here was the same?

[vilim]

I tried the new appimage now (0.9), the interface is sharp but very large, and the mouse is mapped at 2x the distance.

[hanatos]

works here with weston / intel. do you know what is your content scale factor? probably some user setting in some kde dialog?

[vilim]

Standard 200%, no fractional scaling, KDE 6.1

vkdt prints

[gui] vkdt 0.9.99-1-g84e48df8 (c) 2020--2024 johannes hanika
[gui] glfwGetVersionString() : 3.4.0 Wayland X11 GLX Null EGL OSMesa monotonic shared
[gui] monitor [0] DP-4 at 0 0
[gui] vk extension required by GLFW:
[gui]   VK_KHR_surface
[gui]   VK_KHR_wayland_surface
[gui] no joysticks found
[gui] no display profile file display.DP-4, using sRGB!
[ERR] module o-bc1 main connector input has uninited size!
[ERR] module display main connector input has uninited size!
...

[hanatos]

okay thanks.. i suppose i will have to find a machine where i can install wayland/kde to see what's going on. there seem to be quite a few possible combinations of scaling and scaling of input event coordinates.. tested the same scaling factor on a 4k display and here it worked.

[vilim]

Can you give me a pointer where to look in the code? I can compile vkdt, so am happy to try things out myself. Another hint might be is that when vkdt starts, the window is twice big as the screen

[hanatos]

great! okay so here is the deal: glfw knows window size and framebuffer size. for legacy reasons, the window size and framebuffer size may differ by some factor, this content scale factor. what i've seen on macos is that the window size is like half of the framebuffer size and the content scale factors are (2,2) (x and y).

this stuff is inited for a glfw window around here: https://github.com/hanatos/vkdt/blob/master/src/gui/gui.c#L54

which is where i would start digging by printing out the results of glfwGetFramebufferSize glfwGetWindowSize and glfwGetWindowContentScaleFactor. see https://www.glfw.org/docs/latest/window_guide.html for context.

on x11 window and framebuffer are all the same, as it happens to be on my wayland too, regardless of content scale factor, which is 200% on my wayland too.

to make things worse/more interesting, on macos window is half framebuffer size but mouse events are reported on window scale and vkdt expects them on framebuffer/highres scale. this is why you'll find a lot of #ifdef __APPLE__ such as this occasion https://github.com/hanatos/vkdt/blob/master/src/gui/main.c#L160 to scale the mouse coordinates appropriately.

[vilim]

Thanks for 0ee0cb3, now hovering and clicking works at the expected location. However, sliders (for e.g. adjusting exposure) are extremely sensitive and almost impossible to use, the bar accelerates immediately in the direction of movement.

[hanatos]

progress. i can confirm your findings (using some wacky weston --scale=2 that happens to not crash on me today).

[hanatos]

https://gitlab.gnome.org/GNOME/mutter/-/issues/3696 for the record i think this is the same issue. probably have to code some crazy stuff around it.

edit: it seems wayland can't do it by design: https://github.com/glfw/glfw/blob/master/src/wl_window.c#L2676

[vilim]

The latest commit indeed fixes the issue for me, thank you! The only remaining thing is the oversized window at program start, but it's quite minor

[hanatos]

unfortunately the scaling logic is still broken. on hyprland, this crazy dance is not required, so i'm assuming something in the KDE stack might have been too old to work correctly (something fractional scaling?).

i just pushed a commit that removes the input coordinate scaling on wayland so i can work on hyprland. is this working on KDE now too?