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 qou 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. Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> |
||
---|---|---|
.gitlab-ci | ||
Xext | ||
Xi | ||
composite | ||
config | ||
damageext | ||
dbe | ||
dix | ||
doc | ||
dri3 | ||
exa | ||
fb | ||
glamor | ||
glx | ||
hw | ||
include | ||
man | ||
mi | ||
miext | ||
os | ||
present | ||
pseudoramiX | ||
randr | ||
record | ||
render | ||
test | ||
xfixes | ||
xkb | ||
.appveyor.yml | ||
.dir-locals.el | ||
.gitignore | ||
.gitlab-ci.yml | ||
.mailmap | ||
.travis.yml | ||
COPYING | ||
README.md | ||
meson.build | ||
meson_options.txt | ||
xorg-server.m4 | ||
xorg-server.pc.in | ||
xserver.ent.in |
X Server
The X server accepts requests from client applications to create windows, which are (normally rectangular) "virtual screens" that the client program can draw into.
Windows are then composed on the actual screen by the X server (or by a separate composite manager) as directed by the window manager, which usually communicates with the user via graphical controls such as buttons and draggable titlebars and borders.
For a comprehensive overview of X Server and X Window System, consult the following article: https://en.wikipedia.org/wiki/X_server
All questions regarding this software should be directed at the Xorg mailing list:
https://lists.freedesktop.org/mailman/listinfo/xorg
The primary development code repository can be found at:
https://gitlab.freedesktop.org/xorg/xserver
For patch submission instructions, see:
https://www.x.org/wiki/Development/Documentation/SubmittingPatches
As with other projects hosted on freedesktop.org, X.Org follows its Code of Conduct, based on the Contributor Covenant. Please conduct yourself in a respectful and civilized manner when using the above mailing lists, bug trackers, etc: