[rcore] `GetMousePosition()` does not show the correct position if the window spans multiple monitors, in Wayland

[lsck0]

Please, before submitting a new issue verify and check:

• [X] I tested it on latest raylib version from master branch
• [x] I checked there is no similar issue already reported
• [x] I checked the documentation on the wiki
• [x] My code has no errors or misuse of raylib

Issue description

When the window is on multiple monitors, the X component of GetMousePosition() is not updated for the region visible on the monitor that does not contain the top left corner. The Y component is updated as expected.

Environment

OS: Arch Linux x86_64
Kernel: 6.14.4-arch1-1
WM: Hyprland
CPU: AMD Ryzen 5 5600X (12) @ 4.654GHz
GPU: AMD ATI Radeon RX 7700 XT / 7800 XT

INFO: GL: Supported extensions count: 239
INFO: GL: OpenGL device information:
INFO:     > Vendor:   AMD
INFO:     > Renderer: AMD Radeon RX 7800 XT (radeonsi, navi32, LLVM 19.1.7, DRM 3.61, 6.14.4-arch1-1)
INFO:     > Version:  4.6 (Core Profile) Mesa 25.0.4-arch1.1
INFO:     > GLSL:     4.60

Issue Screenshot

https://github.com/user-attachments/assets/626451e4-9536-4e12-8ec4-be75fa67b18d

Code Example

// gcc main.c -o main -lraylib
#include <raylib.h>

int main(void) {
  InitWindow(400, 400, "GetMousePosition() Bug Example");
  SetTargetFPS(60);

  while (!WindowShouldClose()) {
    if (IsKeyPressed(KEY_Q)) break;

    Vector2 mouse_position = GetMousePosition();
    TraceLog(LOG_INFO, "Mouse Position: (%f, %f)", mouse_position.x, mouse_position.y);

    BeginDrawing();
    ClearBackground(RAYWHITE);
    DrawCircle(mouse_position.x, mouse_position.y, 10, RED);
    EndDrawing();
  }

  CloseWindow();
  return 0;
}

[raysan5]

@lsck0 this seems to be a very specific use case and probably related to windowing system...

[lsck0]

I did some more testing on this. I tried 3 different window managers, and all showed different but incorrect results in this case. However, when building raylib with -DUSE_EXTERNAL_GLFW=ON, the raylib window is not displayed through Xwayland, but as a native Wayland window, which completely fixed this issue (and disabled things like SetWindowPosition). Other Xwayland windows show similar problems in this edge case. So not a raylib bug.

[maiconpintoabreu]

Hi @lsck0, tested on my laptop and it is working, the only thing that I can see different from my test is the Hyprland/Gnome.

Environment

OS: Arch Linux x86_64
Kernel: 6.15.7-arch1-1
WM: Gnome
CPU: Intel® Core™ i7-8565U × 8
GPU: UHD Graphics 620

INFO: GL: Supported extensions count: 231
INFO: GL: OpenGL device information:
INFO:     > Vendor:   Intel
INFO:     > Renderer: Mesa Intel(R) UHD Graphics 620 (WHL GT2)
INFO:     > Version:  4.6 (Core Profile) Mesa 25.1.6-arch1.1
INFO:     > GLSL:     4.60

INFO: PLATFORM: DESKTOP (GLFW - Wayland): Initialized successfully

Test running core_input_mouse example

https://github.com/user-attachments/assets/5f8fc1e5-4d87-4ddb-9dfb-84c131b25b12

[lsck0]

Hey @maiconpintoabreu, thank you for doing some more testing on this. This behaviour is essentially a symptom of the transition from X11 to Wayland. When running an X11 window on X11 or a Wayland window on Wayland, everything works as expected. When you run an X11 window on Wayland, however, it uses the xwayland compatibility layer, which provides an X11 instance running as a Wayland client, and that's what's causing the problems. See https://gitlab.freedesktop.org/xorg/xserver/-/issues/1620. This describes the exact issue here: a xwayland window doesn't properly work when spanning monitors. Even up until a year or two ago (not sure on the exact time) for example, you couldn't even drag-and-drop files between native and xwayland windows. What makes this worse from a dev perspective is that you can't obviously tell which window is native or xwayland and always have to keep this in the back of your mind when any windowing goes wrong. You can check with "xeyes" which window is X11; the eyes move when you mouse over it. In your case, you're running a native Wayland window (INFO: PLATFORM: DESKTOP (GLFW - Wayland)) on Wayland (Gnome/Hyprland), which works perfectly fine. I think we can close this Issue as "Not Planned".

[raysan5]

@lsck0 I'm afraid this issue could be out of scope of raylib and related to underlying platform libraries and OS libraries...

[awesomekosm]

There is something else going on with GetMousePosition between web and desktop. When a window is resized horizontally (lets say browser debug is open on the right) The mouse.x position is different

Initial size: INFO: screen width:1596 screen height:1077 INFO: x:251.001648 y:1048.007568

Resized INFO: screen width:1274 screen height:1077 INFO: x:311.836853 y:1048.007568

I kind of can scale this by using new width of the screen dividing by original width of the screen and multiplying the x mouse cord. Still, I think it's a bug, the x position is the same when on desktop.

This is the same case for GetTouch and GetMouse, though for some reason(I guess reuse of Vector2 that's a float) those are ints instead of floats.