e1f16fb1ac
When a present request is received, Xwayland will check if there is an existing request targeting the same window and msc and scrap the older request if so. Alas, this does not interact well the older fence-based or newer syncobj-based synchronization features of the Present extension. Since execution of a request may be delayed for an unknown length of time while waiting for a fence to be signaled, the target msc computed upon receiving a request may not match the actual msc at which the request is executed. Therefore, we cannot determine in advance whether a more recently received request will make an older request redundant. This change removes the code to scrap pending present requests. We must also ensure requests are executed in the correct order even if their fences are signaled out of order. To achieve this, whenever execution of a request needs to wait for a fence, execution of any later-received requests will be blocked until the earlier request is ready. The blocked requests will be added to a list tracked in the xwl_present_window struct. Once the earlier request's fence is signaled, any blocked requests will be re-executed. Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967> |
||
|---|---|---|
| .gitlab-ci | ||
| Xext | ||
| Xi | ||
| composite | ||
| config | ||
| damageext | ||
| dbe | ||
| dix | ||
| doc | ||
| dri3 | ||
| exa | ||
| fb | ||
| glamor | ||
| glx | ||
| hw | ||
| include | ||
| m4 | ||
| 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: