The functions xwl_glamor_dmabuf_import_sync_file and xwl_glamor_dmabuf_export_sync_file are used to ensure proper synchronization between clients using PresentPixmapSynced and compositors that do not support the wp_linux_drm_syncobj_v1 protocol when presenting by flipping. The acquire point's fence will be imported as the DMA-BUF's implicit fence before handing it off to the compositor, and then, after the DMA-BUF has been released, its new implicit fence will be exported and become the release point's fence which the client is expected to wait for before re-using the buffer. Both functions currently set the flags arguments of their respective ioctls to DMA_BUF_SYNC_READ. When importing a sync file, this means that any subsequent implicitly synchronized reads from the buffer will not wait for the fence, and when exporting a sync file it means that the returned fence may be signaled before preceeding reads from the buffer have completed. While this is correct for xwl_glamor_dmabuf_export_sync_file since the compositor will never write to the buffer, it is incorrect for xwl_glamor_dmabuf_import_sync_file. To avoid corruption, we need any reads from the buffer by the compositor to wait on the acquire point's fence. As a fix, instead of setting the DMA_BUF_SYNC_READ flag in xwl_glamor_dmabuf_import_sync_file, we set the DMA_BUF_SYNC_WRITE flag. This *does* provide the necessary guarantees. Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1509> |
||
---|---|---|
.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: