With autoconf, hashtable support is built along with Xres support.
Yet, glvnd also use it, so when disabling Xres from configure, the
build will fail at link time because hashtable functions are not
available.
Untie the build of hashtable from Xres support, just like meson build
does.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1091
(cherry picked from commit 899cebb76a)
One general assumption in Xwayland is that the xwl_window remains the
same for all the child windows of the toplevel window.
When mapping a new X11 window, ensure_surface_for_window() checks for an
existing xwl_window by using xwl_window_get() which will just check for
the registered xwl_window for the window.
That means that a client mapping a child window of an existing window
with a xwl_window will get another different xwl_window.
If an X11 client issues a Present request on the parent window, hence
placed underneath its child window of the same size, the Wayland
compositor may not send the frame callback event for the parent's
Wayland surface which is reckoned to be not visible, obscured behind
the other Wayland surface for the child X11 window.
That bug affects some games running in wine which may get 1 fps because
the repaint occurs only on timeout with a long interval (as with, e.g.
https://bugs.winehq.org/show_bug.cgi?id=47066)
Fix ensure_surface_for_window() by using xwl_window_from_window() which
will walk the window tree, so that a child window won't get another
xwl_window than its parent.
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1099
See-also: https://bugs.winehq.org/show_bug.cgi?id=47066
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 606ba7fc51)
When running non-rootless, Xwayland requires that the Wayland compositor
supports the wl_shell protocol.
Check for wl_shell protocol support at startup and exit cleanly if
missing rather than segfaulting later in ensure_surface_for_window()
while trying to use wl_shell_get_shell_surface().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
(cherry picked from commit ffd02d9b26)
When making a pixmap exportable, glamor will currently create a temporary
exported pixmap backed by a GBM bo, with the devKind updated to the stride of
the bo. However, when the backing of the exported pixmap is swapped into the
original, the devKind of the original is not updated.
Some GBM bos may get implicitly padded, in which case the devKind of the pixmap
will not match the stride of the backing bo. For example, an 800x600 pixmap will
have a devKind of 3200, but the bo's stride will be 3328. This can cause
corruption with PRIME, when the sink uses the wrong stride to display the shared
pixmap.
This commit changes glamor_make_pixmap_exportable() to update the devKind of the
original pixmap after it swaps exported pixmap's backing into it, keeping
everything consistent.
Fixes issue #1018.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 7a7e55c5c1)
The address retrieved in "pip.start_ip" is not necessarily the same
address as unw_get_proc_name finds as nearest symbol and returns in "off".
Therefore using "pip.start_ip + off" is not reliable, at least
visible in the binaries from the Debian repository.
Bug-Debian: https://bugs.debian.org/971088
Signed-off-by: Bernhard Übelacker <bernhardu@mailbox.org>
(cherry picked from commit c15dd0ba48)
It always takes one update cycle for the copy to become visible on the
host windowing system, so waiting for the target MSC resulted in 1 cycle
delay.
We re-use the idle list for copies which were executed but need their
completion event sent.
Fixes black seams when resizing the "Builder" sub-window of
GDK_BACKEND=x11 gtk4-demo
on Xwayland (see
https://gitlab.gnome.org/GNOME/mutter/-/issues/1290#note_873557).
Unfortunately, this cannot completely fix the seams with apps which
queue up multiple frames in advance, since there's always at least one
queued frame corresponding to the old window size. But it should at
least help a little in that case as well.
v2:
* Bug fix: Don't update exec_msc in present_wnmd_check_flip_window.
(Roman Gilg)
* Use exec_msc = target_msc - 1 instead of exec_msc--, and add a
comment, for clarity.
v3:
* Drop exec_msc = target_msc again in present_wnmd_execute.
* present_execute_copy should never set vblank->queued in
present_wnmd_execute now, so replace that branch with an assertion.
(Roman Gilg)
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit 1cccb486d4)
[Since present_wnmd_event_notify hasn't been split up on the 1.20
branch, it needs to check vblank->flip. Doing the same in
present_wnmd_free_idle_vblanks to be safe, though I'm not sure it's
actually possible to hit non-flips there.]
Allowing it to be called from more functions than before. No functional
change.
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit d14ea667fe)
For tracking the MSC when the present can be executed separately from
the target MSC.
Allows removing the requeue field instead, plus more later.
v2:
* Rename wait_msc → exec_msc (Roman Gilg)
* Use exec_msc = target_msc instead of exec_msc++, for clarity.
* Bug fix: Set exec_msc = target_msc also if present_flip returned
false in present_execute.
v3:
* Set exec_msc = target_msc also if present_wnmd_flip returned
false in present_wnmd_execute, for consistency.
v4:
* Specifically check for exec_msc == crtc_msc + 1 in
present_execute_wait/copy, to avoid re-introducing
https://bugs.freedesktop.org/show_bug.cgi?id=94596 .
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit b0b3159abd)
Preparation for different handling between SCMD & WNMD. No functional
change intended.
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit 4c92dea952)
The EGLStream backend keeps a queue of pending streams for each Xwayland
window.
However, when this pending queue is freed, the corresponding private
data may not be cleared (typically if the pixmap for this window has
changed before the compositor finished attaching the consumer for the
window's pixmap's original eglstream), leading to a use-after-free and a
crash when trying to use that data as the window pixmap.
Make sure to clear the private data when the pending stream is freed.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1055
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Karol Szuster <karolsz9898@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit a5f439dcd2)
Major/minor numbers are a.. major (ha) source of pain in FreeBSD porting.
In this case, Xwayland was thinking that /dev/dri/card0 is already a render node,
because the st_rdev on FreeBSD was passing the Linux-style check,
and because of the assumption, acceleration would fail because
various ioctls like AMDGPU_INFO would be denied on the non-render node.
Switch to libdrm's function that already works correctly on all platforms.
Signed-off-by: Greg V <greg@unrelenting.technology>
Reviewed-by: Emmanuel Vadot <manu@FreeBSD.org>
(cherry picked from commit 239ebdc9e4)
Currently, when a X11 client (usually the X11 window manager from a
Wayland compositor) changes the value of the X11 property
`_XWAYLAND_ALLOW_COMMITS` from `false` to `true`, all pending frame
callbacks on the window are discarded so that the commit occurs
immediately.
Weston uses that mechanism to prevent the content of the window from
showing before it's ready when mapping the window initially, but
discarding the pending frame callbacks has no effect on the initial
mapping of the X11 window since at that point there cannot be any frame
callback on a surface which hasn't been committed yet anyway.
However, discarding pending frame callbacks can be problematic if we
were to use the same `_XWAYLAND_ALLOW_COMMITS` mechanism to prevent
damages to be posted before the X11 toplevel is updated completely
(including the window decorations from the X11 window manager).
Remove the portion of code discarding the pending frame callback,
Xwayland should always wait for a pending frame callback if there's one
before posting new damages.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/333
(cherry picked from commit 66da95a172)
present_wnmd_toplvl_pixmap_window returns a window with the same window
pixmap, so the check could never fail.
Reviewed-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit b6b1161fd7)
We can only flip if the window pixmap matches that of the toplevel
window. Doing so regardless could cause the toplevel window pixmap to
get destroyed while it was still referenced by the window, resulting in
use-after-free and likely a crash.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1033
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit 4c25356d6c)
Noticed this was missing while working on the following fix.
v2:
* Dropped present_wnmd_can_window_flip hunk (that function is never
called, will be cleaned up in a follow-up MR).
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> # v1
Reviewed-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit 7ac303c7b1)
(Using GLSL 1.30 or newer)
The width/height members of xRectangle are unsigned, but they were
being interpreted as signed when converting to floating point for the
vertex shader, producing incorrect drawing for values > 32767.
v2:
* Use separate GL_UNSIGNED_SHORT vertex attribute for width/height.
(Eric Anholt)
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 032af35657)
Extending the decade old f0124ed93, to increase the number of input
devices from 40 to 256. 40 translates at most 9 MD, while 256 will allow
63 MD. It is an arbitrary number, but people are hitting the current
limit under reasonable conditions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64793
Signed-off-by: Arthur Williams <taaparthur@gmail.com>
(cherry picked from commit fe439596b9)
CVE-2020-14362 ZDI-CAN-11574
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
(cherry picked from commit 24acad216aa0fc2ac451c67b2b86db057a032050)
CVE-2020-14361 ZDI-CAN 11573
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
(cherry picked from commit 90304b3c2018a6b8f4a79de86364d2af15cb9ad8)
CVE-2020-14346 / ZDI-CAN-11429
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
(cherry picked from commit 1e3392b07923987c6c9d09cf75b24f397b59bd5e)
CVE-2020-14345 / ZDI 11428
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
(cherry picked from commit 11f22a3bf694d7061d552c99898d843bcdaf0cf1)
On a DT-base PCI platform, the sysfs path of vga device is like this:
/sys/devices/platform/bus@10000000/1a000000.pci/pci0000:00/0000:00:11.0/0000:04:00.0.
Then the ID_PATH from udev is platform-1a000000.pci-pci-0000:04:00.0 and
the BusID will be pci-0000:04:00.0, which causes Xorg start fail. This
is because config_udev_odev_setup_attribs() use strstr() to search the
first "pci-" in ID_PATH. To fix this, we implement a strrstr() function
and use it to search the last "pci-" in ID_PATH, which can get a correct
BusID.
(backported from commit 9fbd3e43dd)
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Suppose you're in a Hyper-V guest and are trying to use PCI passthrough.
The ID_PATH that udev will construct for that looks something like
"acpi-VMBUS:00-pci-b8c8:00:00.0", and obviously looking for "pci-" in
the first four characters of that is going to not work.
Instead, strstr. I suppose it's possible you could have _multiple_ PCI
buses in the path, in which case you'd want strrstr, if that were a
thing.
(backported from commit 9acff30943)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Huacai Chen <chenhc@lemote.com>
At the point where xf86BusProbe runs we haven't yet taken our own VT,
which means we can't perform drm "master" operations on the device. This
is tragic, because we need master to fish the bus id string out of the
kernel, which we can only do after drmSetInterfaceVersion, which for
some reason stores that string on the device not the file handle and
thus needs master access.
Fortunately we know the format of the busid string, and it happens to
almost be the same as the ID_PATH variable from udev. Use that instead
and stop calling drmSetInterfaceVersion.
(backported from commit 0816e8fca6)
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Avoid leaking un-initalized memory to clients by zeroing the
whole pixmap on initial allocation.
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit a6b2cbe91793ae4967cd21a7103d889248029553)
EDID1.4 replaced GTF Bit with Continuous or Non-Continuous Frequency Display.
Check the "Display Range Limits Descriptor" for GTF support.
If panel doesn't support GTF, then add gtf modes.
Otherwise X will only show the modes in "Detailed Timing Descriptor".
V2: Coding style changes.
V3: Coding style changes, remove unused variate.
V4: remove unused variate.
BugLink: https://gitlab.freedesktop.org/drm/intel/issues/313
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 6a79a737e2)
For Pixmap flips to have well defined outcomes the window must be contained by
the valid region if such region was specified.
The valid region is inserted as an argument to the check in window mode.
Setting this argument is missing in screen mode as well but we ignore it for now
and only add it to window mode.
It seems there are none or only very few clients actually making use of valid
regions at the moment. For simplicity we therefore just check if a valid region
was set by the client and in this case do never flip, independently of the
window being contained by the region or not.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit 591916ea9e)
This couldn't have worked correctly for non-0 x1/y1.
Noticed by inspection.
Reviewed-by: Simon Ser <contact@emersion.fr>
(cherry picked from commits 9141196d31)
(cherry picked fixup from commit 85a6fd11c7)
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
(cherry picked from commit b0413b6e99)
Previously, linux-dmabuf was used unconditionally if the buffer had a
modifier. However creating a linux-dmabuf buffer with a format/modifier
which hasn't been advertised will fail.
Change xwl_glamor_gbm_get_wl_buffer_for_pixmap to use linux-dmabuf when
the format/modifier has been advertised only.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1035
Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit c0e13cbf5a)
During a VT-Switch a raw pointer to the shared cursor object
is saved which is then freed (in case of low refcount) by a call to
xf86CursorSetCursor with argument pCurs = NullCursor.
This leads to a dangling pointer which can follow in a use after free.
This fix ensures that there is a shared handle saved for the VT-Switch cycle.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 7ae221ad57)
Mostly http->https conversions, but also replaces gitweb.fd.o
with gitlab.fd.o, and xquartz.macosforge.org with xquartz.org.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit a5151f58cf)
Xwayland is just a Wayland client, no X11 screensaver should be
expected to work reliably on Xwayland when running rootless because
Xwayland cannot grab the input devices so it has no way to actually
lock the screen managed by the Wayland compositor.
Turn off the screensaver on Xwayland when running rootless by setting
the screensaver timeout and interval and their default values to zero
and disable the MIT-SCREEN-SAVER extension.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1051
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5c20e4b834)
In the log of the commit below, I claimed this wasn't necessary on the
1.20 branch, but this turned out to be wrong: It meant that
event->buffer could already be destroyed in xwl_present_free_event,
resulting in use-after-free and likely a crash.
Fixes: 22c0808ac8 "xwayland: Free all remaining events in
xwl_present_cleanup"
RRHasScanoutPixmap() is called from xf86CheckHWCursor(), regardless of whether
or not RandR has been initialized.
As mentioned in commit 4226c6d, it's possible that RandR has not been
initialized if the server is configured with Xinerama and there is more than one
X screen. Calling rrGetScrPriv when RandR isn't initialized causes an assertion
failure that aborts the server:
Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion
key->initialized' failed.
Just as in commit 4226c6d, fix the problem by checking
dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 8eeff5d788)
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: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1024
Fixes: 8774532121 "modesetting: Remove unnecessary fb addition from
drmmode_xf86crtc_resize"
(cherry picked from commit 73480f172a)
When a slave device causes the master virtual pointer device to change
device types, the device's private data pointer
(device->public.devicePrivate) is also changed to match the type of the
slave device. This can be a problem though, as tablet pad devices will
set the device's private data pointer to their own xwl_tablet_pad
struct. This can cause us to dereference the pointer as the wrong type,
and result in a segfault:
Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at src/wayland-client.c:792
792 va_start(ap, opcode);
(gdb) bt
0 wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at
src/wayland-client.c:792
1 0x00005610b27b6c55 in wl_pointer_set_cursor (hotspot_y=0,
hotspot_x=0, surface=0x0, serial=<optimized out>, wl_pointer=<optimized
out>) at /usr/include/wayland-client-protocol.h:4610
2 xwl_seat_set_cursor (xwl_seat=xwl_seat@entry=0x5610b46d5d10) at
xwayland-cursor.c:137
3 0x00005610b27b6ecd in xwl_set_cursor (device=<optimized out>,
screen=<optimized out>, cursor=<optimized out>, x=<optimized out>,
y=<optimized out>) at xwayland-cursor.c:249
4 0x00005610b2800b46 in miPointerUpdateSprite (pDev=0x5610b4501a30) at
mipointer.c:468
5 miPointerUpdateSprite (pDev=0x5610b4501a30) at mipointer.c:410
6 0x00005610b2800e56 in miPointerDisplayCursor (pCursor=0x5610b4b35740,
pScreen=0x5610b3d54410, pDev=0x5610b4501a30) at mipointer.c:206
7 miPointerDisplayCursor (pDev=0x5610b4501a30, pScreen=0x5610b3d54410,
pCursor=0x5610b4b35740) at mipointer.c:194
8 0x00005610b27ed62b in CursorDisplayCursor (pDev=<optimized out>,
pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at cursor.c:168
9 0x00005610b28773ee in AnimCurDisplayCursor (pDev=0x5610b4501a30,
pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at animcur.c:197
10 0x00005610b28eb4ca in ChangeToCursor (pDev=0x5610b4501a30,
cursor=0x5610b4b35740) at events.c:938
11 0x00005610b28ec99f in WindowHasNewCursor
(pWin=pWin@entry=0x5610b4b2e0c0) at events.c:3362
12 0x00005610b291102d in ChangeWindowAttributes (pWin=0x5610b4b2e0c0,
vmask=<optimized out>, vlist=vlist@entry=0x5610b4c41dcc,
client=client@entry=0x5610b4b2c900) at window.c:1561
13 0x00005610b28db8e3 in ProcChangeWindowAttributes (client=0x5610b4b2c900)
at dispatch.c:746
14 0x00005610b28e1e5b in Dispatch () at dispatch.c:497
15 0x00005610b28e5f34 in dix_main (argc=16, argv=0x7ffc7a601b68,
envp=<optimized out>) at main.c:276
16 0x00007f8828cde042 in __libc_start_main (main=0x5610b27ae930 <main>,
argc=16, argv=0x7ffc7a601b68, init=<optimized out>, fini=<optimized
out>, rtld_fini=<optimized out>, stack_end=0x7ffc7a601b58) at
../csu/libc-start.c:308
17 0x00005610b27ae96e in _start () at cursor.c:1064
Simple reproducer in gnome-shell: open up an Xwayland window, press some
tablet buttons, lock and unlock the screen. Repeat if it doesn't crash
the first time.
So, let's fix this by registering our own device-specific private key
for storing a backpointer to xwl_tablet_pad, so that all input devices
have their private data pointers set to their respective xwl_seat.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Lyude Paul <lyude@redhat.com>
(cherry picked from commit ba0e789b91)
ProcVidModeGetGamma() relies on GetGamma() to initialise values if it
returns TRUE. Without this, we're sending uninitialised values to
clients.
Fixes: xorg/xserver#1040
(cherry picked from commit 6748a40941)
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>
(cherry picked from commit d35f68336b)
Xwayland uses the device private to point to the `xwl_seat`.
Device may be removed at any time, including on suspend.
On resume, if the DIX code ends up calling a function that requires the
`xwl_seat` such as `xwl_set_cursor()` we may end up pointing at random
data.
Make sure the clear the device private data on removal so that we don't
try to use it and crash later.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
https://gitlab.freedesktop.org/xorg/xserver/issues/709
(cherry picked from commit 4195e80356)
At the end of xwl_present_cleanup, these events aren't reachable
anymore, so if we don't free them first, they're leaked.
(cherry picked from commit 64565ea344fef0171497952ef75f019cb420fe3b)
v2:
* Simpler backport, no need to keep a reference to the pixmap on the
1.20 branch.
Minor cleanup, and will make the next change simpler. No functional
change intended.
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 1beffba699)
When present_wnmd_clear_window_flip is done, present_destroy_window
frees struct present_window_priv, and the events in the flip queue
become unreachable. So if we don't free them first, they're leaked.
Also drop the call to present_wnmd_set_abort_flip, which just sets a
flag in struct present_window_priv and thus can't have any observable
effect after present_destroy_window.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1042
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 1bdedc8dbb)
Olivier Fourdan
Alex Goins
Bernhard Übelacker
Michel Dänzer
Greg V
Arthur Williams
Matt Turner
Matthieu Herrb
Huacai Chen
Adam Jackson
Aaron Ma
Roman Gilg
Alan Coopersmith
Simon Ser
Martin Weber
Jose Maria Casanova Crespo
Lyude Paul
SimonP
Sjoerd Simons