e9ffff31e4
We currently skip setting the window pixmap on any window not using its parent's pixmap. That does not work correctly in the presence of reparenting. Consider the following scenario: 1. window A is created as child of B 2. present starts flipping and sets the whole window tree to use pixmap X 3. window C is created (uses the screen pixmap by default) 4. window A is reparented to C 5. present stops flipping and attempts to set the whole window tree back to the screen pixmap, except the walk terminates at window C since it's using an unexpected pixmap, and window A is left with the stale pixmap X 6. pixmap X is destroyed 7. the X server segfaults on a rendering operation on window A due the stale pixmap I managed to hit this with mpv (doing present flips) and crack-attack (keeps alternating between a menu window and an actual game window): 1. start both applications 2. start a game in crack-attack 3. fullscreen mpv 4. end the game in crack attack 5. unfullscreen mpv 6. the crack-attack menu window has appeared, but might be corrupted and doing stuff on it segfaults the X server I suppose the other option might be to make new windows automatically inherit their parent's pixmap instead of using the screen pixmap. But I've not looked into how that would affect eg. composite. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> |
||
|---|---|---|
| .gitlab-ci | ||
| composite | ||
| config | ||
| damageext | ||
| dbe | ||
| dix | ||
| doc | ||
| dri3 | ||
| exa | ||
| fb | ||
| glamor | ||
| glx | ||
| hw | ||
| include | ||
| man | ||
| mi | ||
| miext | ||
| os | ||
| present | ||
| pseudoramiX | ||
| randr | ||
| record | ||
| render | ||
| test | ||
| Xext | ||
| xfixes | ||
| Xi | ||
| xkb | ||
| .appveyor.yml | ||
| .dir-locals.el | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| .travis.yml | ||
| COPYING | ||
| meson.build | ||
| meson_options.txt | ||
| README.md | ||
| 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: