574fe59ef0
Due to a switched order of parameters in the xorg_list_add() call inside ProcRRCreateLease(), adding a new lease for RandR output leasing does not actually add the new RRLeasePtr lease record to the list of existing leases for a X-Screen, but instead replaces the existing list with a new list that has the new lease as the only element, and probably leaks a bit of memory. Therefore the server "forgets" all active leases for a screen, except for the last added lease. If multiple leases are created in a session, then destruction of all leases but the last one will fail in many cases, e.g., during server shutdown in RRCloseScreen(), or resource destruction, e.g., in RRCrtcDestroyResource(). Most importantly, it fails if a client simply close(fd)'es the DRM master descriptor to release a lease, quits, gets killed or crashes. In this case the kernel will destroy the lease and shut down the display output, then send a lease event via udev to the ddx, which e.g., in the modesetting-ddx will trigger a call to drmmode_validate_leases(). That function is supposed to detect the released lease and tell the server to terminate the lease on the server side as well, via xf86CrtcLeaseTerminated(), but this doesn't happen for all the leases the server has forgotten. The end result is a dead video output, as the server won't reinitialize the crtc's corresponding to the terminated but forgotten lease. This bug was observed when using the amdvlk AMD OSS Vulkan driver and trying to lease multiple VKDisplay's, and also under Mesa radv, as both Mesa Vulkan/WSI/Display and amdvlk terminate leases by simply close()ing the lease fd, not by sending explicit RandR protocol requests to free leases. Leasing worked, but ending a session with multiple active leases ended in a lot of unpleasant darkness. Fixing the wrong argument order to xorg_list_add() fixes the problem. Tested on single-X-Screen and dual-X-Screen setups, with one, two or three active leases. Please merge this for the upcoming server 21.1 branch. Merging into server 1.20 would also make a lot of sense. Fixes: |
||
|---|---|---|
| .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 | ||
| .travis.yml | ||
| COPYING | ||
| Makefile.am | ||
| README.md | ||
| autogen.sh | ||
| configure.ac | ||
| devbook.am | ||
| docbook.am | ||
| fix-miregion | ||
| fix-miregion-private | ||
| fix-patch-whitespace | ||
| fix-region | ||
| manpages.am | ||
| 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 master 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: