Commits on Source (4)
-
Since the introduction of "modesetting: Remove unnecessary fb addition from drmmode_xf86crtc_resize" the fb_id isn't initialited at drmmode_xf86crtc_resize. Rotate operation of XRandR uses rotate_bo. So in this case the fb_id associated to the front_bo is not initialized at drmmode_set_mode_major. So fd_id remains 0. As every call to drmmode_xf86crtc_resize allocates a new front_bo we should destroy unconditionally the old_front_bo if operation success. So we free the allocated GBM handles. This avoids crashing xserver with a OOM in the RPI4 1Gb at 4k resolution after 3 series xrandr rotations from normal to left and vice versa reported at https://github.com/raspberrypi/firmware/issues/1345 Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Reviewed-by: Keith Packard <keithp@keithp.com> Closes: xorg/xserver#1024 Fixes: 87745321 "modesetting: Remove unnecessary fb addition from drmmode_xf86crtc_resize"
73480f17 -
When running with a weston session without a pointer device (thus with the wl_seat not having a pointer) xwayland pointer warping and pointer confining should simply be ignored to avoid crashes. Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
d35f6833 -
ProcVidModeGetGamma() relies on GetGamma() to initialise values if it returns TRUE. Without this, we're sending uninitialised values to clients. Fixes: xorg/xserver#1040
6748a409 -
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: xorg/xserver#731
b0413b6e