disp/gl: Toggling fullscreen unexpectedly moves to another monitor

[mpiatka]

If no monitor is explicitly specified as a parameter, the expected behavior is that toggling fullscreen uses the same monitor the window was already on (other sw displays behave this way).

GLFW instead picks a "primary" monitor and always uses that one. This is even worse on Wayland, since there is no concept of primary/secondary monitors, so the monitor picked is unpredictable.

Unfortunately, there currently doesn't seem to be a way to fix this as GLFW doesn't provide any way to query which monitor to use (glfwGetWindowMonitor works only when the window is already fullscreen).

[MartinPulec]

You're right, I've already tried to improve the situation.

It is actually possible to specify a monitor as a first argument to a different value than the primary (or user specified) when calling glfwSetWindowMonitor(). I've implemented it in a way that window position (I believe it is top left corner) is queried when entering fullscreen. If the corner is inside some workspace, its GLFWmonitor is selected. If not, primary display is used (the it actually works for me with GNOME mutter, don't know other compositors - it would need tweeking if nullptr is returned by glfwGetPrimaryMonitor(), otherwise no fullscreen will happen).

What doesn't work:

1. it doesn't actually work on Wayland, however - it is because glfwGetWindowPos() doesn't return position (error 0x0001000C: " The platform does not provide the window position"). So that this approach doesn't work here - don't know if it can be done differently but at least a hint is displayed to use X11 via XWayland... It is possible that the protocol will be defined and implemented in future.
2. [with platform=x11 as indicated by point 1.] if the window's left-top corner is moved outside the visible area, it also doesn't choose appropriate workspace now - there could be some heuristics to match; simply clamping value to 0 doesn't work with gnome shell because top edge has y offset 29 px because of panel; I've added it, anyway, because it works at least for left edge and will work if there is no top panel. Adding further heuristics may be possible but it is question whether to add more complexity because this edge case that doesn't hurt much (and if eventually the native Wayland backend will work, then it may unneeded - native Wayland desktop has the top-most offset 0 px, not those 29 px)
3. it is also worth considering whether if user explicitly requests a monitor with :fs=<val> it shouldn't have a precedence. My point-of-view is that the explicit setting is for init only; if really required, no need to press 'f' and if pressed anyway, it may want actually to change it.

Also, I've encountered a bit troublesome bug on Windows, that leaving fullscreen leaved the window content aligned to pixel 0,0, keeping the title-bar outside the user control so that the window could not have been possible to move, see here (don't know whether there is something like Alt+drag as in Linux). This might have been fixed, however - when leaving fullscreen, the original geometry is restored, which I assume that is also more intuitive (as proposed in the linked StackOverflow issue). I assume that it is partly a bug of GLFW, however - there was GLFW_DONT_CARE in use before so I'd expect that GLFW chooses some more reasonable value than position=0,0; from the issue we are not alone having this problem....

The stuff will certainly need to be re-tested on other OSes and with different compositors in Linux.

[mpiatka]

I've dug around to see how exactly SDL3 handles this and this is what I found out:

• SDL enumerates all displays along with their positions and sizes (wayland provides this info)
• SDL then listens for surface_enter event (wl_surface_listener) which tells it when the window enters a display
• SDL then updates the window position to the top left corner of the display it's in
• On enter fullscreen it determines the correct monitor by this approximate position

GLFW currently does not set the approximate window position in its surface_enter handler, but since we're building glfw ourselves in the CI, perhaps I could write a patch so that it does. What do you think?