`glXGetSyncValuesOML` bug with mesa and xwayland
glXGetSyncValuesOML
from GLX_OML_sync_control allows retrieval of the "Media Stream Counter (MSC)". This can be used to determine the refresh rate of the screen, by observing changes to this value over time.
Chromium on Linux under Mesa/AMD and XWayland observed that the above function returns values such that the refresh rate calculates as 1Hz (instead of 60Hz for example): https://crbug.com/1042393.
Tracing the issue and reading code, I found this suspicious piece of code that is likely relevant:
From xserver/hw/xwayland/xwayland-present.c:
/*
* When not flipping let Present copy with 60fps.
* When flipping wait on frame_callback, otherwise
* the surface is not visible, in this case update
* with long interval.
*/
#define TIMER_LEN_COPY 17 // ~60fps
#define TIMER_LEN_FLIP 1000 // 1fps
We haven't verified 100%, but presumably at the time the refresh rate is being calculated, "the surface is not visible", so MSC advances at 1fps.
FYI, we worked around this issue by using glXGetMscRateOML
from that extension, which returns the correct MSC rate. So this bug is not blocking Chromium on Linux.
If glXGetMscRateOML
can return the correct MSC rate, there is no reason why TIMER_LEN_FLIP should be fixed at 1fps.
[ Michel Dänzer edit: made Chromium bug URL clickable ]