IIUC input is still driven at 60Hz but changing this is in discussion [2].
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285 [2] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/168
https://en.wikipedia.org/wiki/Mutter_(window_manager)
Edit: I missed the part where you were asking specifically about GNOME. Removed everything unrelated to that.
Why are inputs synchronized to the frame in Wayland? What the f---? That's just... wow.
The logic isn't perfect and the implementation is flawed but I see where the decision originated.
Since the compositor is already using vsync, it's generally pointless to run graphical applications under a compositor with vsync as well, since that only adds latency. [2] Hypothetically that can result in tearing, however in practice that doesn't matter, because the scanout of the compositor is basically a copy in GPU memory, so you'd have to be rather unlucky to see tearing, let alone consistent tearing. [1]
Of course, OpenGL doesn't support triple buffering (since it has fixed definitions of exactly one GL_FRONT and exactly one GL_BACK buffer per framebuffer/output surface), and it seems like at least nVidia on Linux doesn't support it for Vulkan, either (no mailbox present mode, only FIFO).
In any case, on X11 there is a huge difference between running a 3D UI on a compositor with (A) VSync enabled, (B) running without VSync (which introduces unncessarily high GPU loads, since UIs are generally super-quick to render and if your app architecture is correct, you should be seeing thousands of frames per second), (C) running with a frame limiter (careful choice of limiting FPS to avoid common multiples of 30), (D) rendering a frame as soon as at least one event has been posted, which requires some explicit synchronization work and thought (worker threads have to post events to wake the UI, animations need a timer). (D) is what QML does and what I'm implementing currently. It works well, latency seems to be indistinguishable from B) and C), without the unnecessary power use. X11 only seems to deliver events at a rate of somewhere around 250-400 per second, so an explicit FPS limiter is unnecessary.
[1] If you are rendering to a monitor, scanout happens approx 95 % of the time, so tearing is very likely. Let's say your app's window is 1451x1400 pixels big, then its framebuffer will be about 8 MB. The "scanout" will take something like 15 µs, so at 60 Hz scanout happens about 0.1 % of the time.
[2] My angle here is primarily applications that happen to use <insert 3D API here> as their UI rendering backend. Games have slightly different considerations and should generally just run full-tilt with triple buffering.
When I scroll in MS Word, there is this insane black tearing across the white surface when I scroll, but only on the laptop monitor.
It's A WORD PROCESSOR! It's just a word processor... It's.... weeps
Or the graphics card isn't being used for some reason? E.g., if your laptop has NVidia's Optimus[1], the graphics card may be inactive while Word's running. There's usually a way to force applications to use the GPU with Optimus.
[1] https://www.nvidia.com/en-us/geforce/technologies/optimus/