834a467af9
Request-handlers as registered in the requestVector array, always get passed the clientPtr for the client which sent the request. But the implementation of many request-handlers typically consists of a generic handler calling implementation specific callbacks and / or various helpers often multiple levels deep and in many cases the clientPtr does not get passed to the callbacks / helpers. This means that in some places where we would like to have access to the current-client, we cannot easily access it and fixing this would require a lot of work and often would involve ABI breakage. This commit adds a GetCurrentClient helper which can be used as a shortcut to get access to the clienPtr for the currently being processed request without needing a lot of refactoring and ABI breakage. Note using this new GetCurrentClient helper is only safe for code which only runs from the main thread, this new variable MUST NOT be used by code which runs from signal handlers or from the input-thread. The specific use-case which resulted in the creation of this patch is adding support for emulation of randr / vidmode resolution changes to Xwayland. This emulation will not actually change the monitor resolution instead it will scale any window with a size which exactly matches the requested resolution to fill the entire monitor. The main use-case for this is games which are hard-coded to render at a specific resolution and have sofar relied on randr / vidmode to change the monitor resolution when going fullscreen. To make this emulation as robust as possible (e.g. avoid accidentally scaling windows from other apps) we want to make the emulated resolution a per client state. But e.g. the RRSetCrtc function does not take a client pointer; and is a (used) part of the Xorg server ABI (note the problem is not just limited to RRSetCrtc). Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> |
||
|---|---|---|
| .gitlab-ci | ||
| composite | ||
| config | ||
| damageext | ||
| dbe | ||
| dix | ||
| doc | ||
| dri3 | ||
| exa | ||
| fb | ||
| glamor | ||
| glx | ||
| hw | ||
| include | ||
| m4 | ||
| man | ||
| mi | ||
| miext | ||
| os | ||
| present | ||
| pseudoramiX | ||
| randr | ||
| record | ||
| render | ||
| test | ||
| Xext | ||
| xfixes | ||
| Xi | ||
| xkb | ||
| .appveyor.yml | ||
| .dir-locals.el | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .travis.yml | ||
| autogen.sh | ||
| configure.ac | ||
| COPYING | ||
| devbook.am | ||
| docbook.am | ||
| Makefile.am | ||
| manpages.am | ||
| meson_options.txt | ||
| meson.build | ||
| 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 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: