Thank a lot for you for your fast answer ![]()
GLFW has Wayland support as per the second line of the readme.
Yes, I read that, sorry if my question seemed naive. I use XWayland (GLFW not compiled with Wayland support) since 6 months or so, but it is frustrating not to be able to use Wayland backend. And I am super happy with GLFW excepted for the problems I listed above ![]()
- I’m not sure what the behaviour for Wayland is with content scaling but it’s likely that pixels map 1:1 to screen coordinates, so you may want to use
GLFW_SCALE_TO_MONITOR
I tried GLFW_SCALE_TO_MONITOR. Using it or not if I ask a window of 256x256 pixels I get a window of 192x192 pixels (with scaling 1.5 on, same kind of errors if scaling is 2).
If I ask window decorations, I still get the same window size but with decorations that are twice this size. It seems, this behaviour happens as soon as scaling is not 1x1.

In fact I am willing to avoid using scaling at all, I would like to provide exact pixel sizes. But GLFW does use some scaling information somewhere, and I don’t know how to specify the size of my window without GLFW applying some scaling on the values I give. Furthermore I cannot get the correct scale values from glfwGetMonitorScale() to do the maths myself.
- I’m unsure what the behaviour of glfwGetMonitorContentScale should be on Wayland. The integer scaling may be correct.
I won’t argue on this, this could be a design decision. But this prevent users to have their screen in such configurations.
In any case if my screen is at 1.5 scale, with XWayland glfwGetScreenScale() gives me 1x1 and with Wayland I get 2x2.
- You cannot draw into the window decorated area, but you can potentially set the window title text and window icon. Note that on Wayland the remarks in the documentation state that the icon cannot be changed. One way around this is to not use a decorated window and then draw your own window decorations.
I am willing to draw my own decoration if needed… but in that case, as I cannot change the window position, it becomes unusable. No user of my application will want to be stuck with a window that can’t be moved by dragging its title bar, and I would have to simulate this behaviour.
- You cannot set a windows position on Wayland, see remarks in the glfwSetWindowPos documentation.
Yes I discovered that after posting, sorry. Therefore this forces us to use decorated windows with the size problem listed above. With all due respect, I cannot imagine that the white large blank borders are here to stay ?