b0413b6e99
The way Xwayland works (like all Wayland clients), it first queries the Wayland registry, set up all relevant protocols and then initializes its own structures. That means Xwayland will get the Wayland outputs from the Wayland compositor, compute the physical size of the combined outputs and set the corresponding Xwayland screen properties accordingly. Then it creates the X11 screen using fbScreenInit() but does so by using a default DPI value of 96. That value is used to set the physical size of the X11 screen, hence overriding the value computed from the actual physical size provided by the Wayland compositor. As a result, the DPI computed by tools such as xdpyinfo will always be 96 regardless of the actual screen size and resolution. However, if the Wayland outputs get reconfigured, or new outputs added, or existing outputs removed, Xwayland will recompute and update the physical size of the screen, leading to an unexpected change of DPI. To avoid that discrepancy, use a fixed size DPI (defaults to 96, and can be set using the standard command lime option "-dpi") and compute a physical screen size to match that DPI setting. Note that only affects legacy core protocols, X11 clients can still get the actual physical output size as reported by the Wayland compositor using the RandR protocol, which also allows for the size to be 0 if the size is unknown or meaningless. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Simon Ser <contact@emersion.fr> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/731 |
||
|---|---|---|
| .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: