X.Org Server Patches Look To Cleanup VRR Handling, Make It Xinerama-Aware

Open-source developer Enrico Weigelt has in recent months taken to near single-handedly maintain and further enhance the aging X.Org Server codebase. The latest area that Weigelt has been working to improve is around the X.Org Server's Variable Refresh Rate (VRR) support.

A merge request has been opened for the X.Org Server to provide generic Xinerama-capable VRR infrastructure. With Xinerama support should improve VRR support for multi-monitor systems that support Variable Refresh Rate capabilities. Enrico explained in that merge request:

"We don't have a standard protocol for enabling VRR yet, but some time ago an ad-hoc had been made in the amdgpu driver (later also copied to modsetting), which works by client setting the _VARIABLE_REFRESH window property.

The way it's currently done - driver is highjacking the X_ChangeProperty and X_DeleteProperty request handlers - is pretty fragile, and is also a violation of layers: drivers never should be twisted with core protocol details. (And in the future, this should be done by some suitable extension).

Another problem is Xinerama: when it's enabled, this only works on the first screen - the others won't ever see this signal, no matter on which one(s) the Window is physically placed (for the wire protocol, all windows are on screen 0, unless the client explicitly creates them on another one)

This commit adds a generic Screen proc for telling the DDX, whether the VRR mode shall be changed (for now, it's only DISABLED and ENABLED). Drivers can hook into here in order to receive this signal, w/o having to highjack any core request handlers. Catching the property change is now entirely done in the DIX.

The (non-standard) status quo of (ab)using window properties is kept, but it's now also easy to add a new signaling mechanism, in case a standard is agreed on.

Yet a quite naive implementation (eg. not acting on moving windows between screens), but enough to fix the most pressing problems supporting extra screens in general, as well as stopping the highjacking of core request handlers by drivers."

Enrico also started a mailing list discussion on the X.Org development list around cleaning up VRR and making it Xinerama aware:

"Therefore I've gone the following path:

* add the notion of VRR mode (for now just disabled/enabled) and a new (optional) Screen proc for sending VRR mode changes to the DDX/driver
* catch the property changes directly in DIX, moving this away from the drivers
* if Xinerama is active, push the signal down to the slave screens
* update in-tree modsetting driver to support the new API

It's not entirely perfect yet, eg. not yet catching whether a window is moved from one screen to another and automatically switch it around on the old/new screens. Leaving this for later exercise."

So thanks to the work of Enrico Weigelt, there still is some feature work happening on the X.Org Server with the prospects of better VRR support going upstream soon.