If the compositor isn't synchronizing rendering it'll work fine. Options there are GPU level vsync or no sync. I think these are the "workarounds for this problem but none of them can remove all problems at the same time." being referred to though at this point I forget the downside of GPU level vsync (tearing is the obvious downside of no sync).

I don't remember if GPU level sync with compositor sync off solves VRR with a compositor on X11 though or if it did but with side effects. Been a while since I've messed with it.

X11 has about 9 billion configurations, some of which have v-sync, some of which don't, and some of which depend on something like how broken your drivers are. I don't normally use any of this fancy compositing stuff let alone anything from gnome, but on a lab machine I have Ubuntu 20 (gnome / X11), and from moving the window around you can clearly see vsync is off.

I've heard two conflicting explanations for this

a) Both screens are receiving a 144Hz signal and your 60Hz screen just happens to accept this and drop the extra frames

b) It works as long as it can actually hit 144Hz. As soon as anything drops it will drop to 60 instead of whatever is appropriate for a 144Hz screen. (This comes from the article on how mutter finally split the frame clock on Wayland)

> a) Both screens are receiving a 144Hz signal and your 60Hz screen just happens to accept this and drop the extra frames

No shot. All 60Hz monitors created before the 120Hz+ era cannot handle a signal above 75Hz. The exception being the few that can go up to 85Hz. They cannot just drop every second frame at 120Hz; that would require timing faster than what they're capable of.

I think the entire desktop is running at the highest refresh rate, which is not only wasteful but can cause glitches when the lower refresh rates don't cleanly divide the highest.

myth.