GLX_EXT_swap_control_tear implementation might be wrong...?
This came up in the SDL bug tracker, but I'll paste the relevant details here:
The GLX_EXT_swap_control_tear spec uses some ambiguous language here (emphasis mine)...
The application can also determine whether a particular drawable allows late unsynchronized swaps to occur by calling glXQueryDrawable with the attribute GLX_LATE_SWAPS_TEAR_EXT. If late swaps are enabled, will be set to 1; otherwise, it will be set to 0.
Mesa (as of the version shipped in Ubuntu 23.04, at least) appears to interpret the bolded text to mean "if the Drawable is capable of having a negative swap interval set" and seems to always return 1 if you have a modern Mesa with the extension available.
Nvidia's current drivers appear to interpret it to mean "if the app has currently set a negative swap interval for this Drawable" and returns 1 or 0 based on that.
glXQueryDrawable returns values as unsigned ints...in Mesa's case, for GLX_SWAP_INTERVAL_EXT, it'll return a -1 cast to an unsigned int for adaptive vsync. Nvidia will return a 1 and presumably expect you to check GLX_LATE_SWAPS_TEAR_EXT.
One of these implementations is clearly incorrect, but I don't know which.
Is there some way to decide if Mesa is right or wrong here, or maybe get Nvidia and Mesa devs in the same room to discuss it?