If the server resets, most client workqueues are cleaned up as the
clients are killed.
The one exception is the server's client, which is exempt from
the killing spree.
If that client has a queued work procedure active, it won't get
cleared on reset.
This commit ensures it gets cleared too.
(cherry picked from commit 8738ce85df)
Fixes: xorg/xserver#670
We don't set the PIGLIT_DIR and XTS_DIR environment variables for make
distcheck for now, otherwise it complains about files left behind by
piglit.
(cherry picked from commit 432fad04e7)
Instead of testing window->redirectDraw.
With Xwayland, the toplevel window is always redirected, so this would
unnecessarily preclude flipping there in some cases, e.g. with wlroots
based Wayland compositors or with fullscreen X11 windows in weston.
Fixes issue #631.
(Cherry picked from commit a093a88531)
Otherwise there's normally no need to run it. It will also run when a
new branch is created, which ensures that the docker image always exists
(e.g. in a newly forked repository).
Inspired by https://gitlab.freedesktop.org/mesa/mesa/merge_requests/143
(Cherry picked from commit 8694395fcf)
Although piglit could now handle non-ASCII characters in the
environment, meson was still failing without this (even though it's
using Python 3).
Reviewed-by: Eric Anholt <eric@anholt.net>
(Cherry picked from commit bc6998b728)
The latter use Python 2 and break with any non-ASCII characters in the
environment, the former uses Python 3 and works fine in that case.
Reviewed-by: Eric Anholt <eric@anholt.net>
(Cherry picked from commit 4aaaf69229)
This removes the dependency on an externally generated docker image, and
should make it easier to update the docker image or make other changes
related to it.
This is based on Debian testing, because I'm most familiar with Debian.
But it should be easy to base it on another distro.
v2:
* Use kaniko instead of docker-in-docker for image generation, so it can
also work in unprivileged runners.
* Drop piglit.conf & tetexec.cfg overrides, just make sure the files in
the image work.
(Cherry picked from commit f56d8e2282)
Fold build-travis-deps.sh into .gitlab-ci.yml.
Preparation for the next change, which would break the Travis Linux
build.
Reviewed-by: Eric Anholt <eric@anholt.net>
(Cherry picked from commit ed44f9cd6a)
No idea which cult's cargo I was looking at there. Cuts about a minute
off the build time.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(Cherry picked from commit a41ccaa085)
The input thread checks the barriers for pointer positioning, swapping the
list out from underneath is considered impolite.
Reported-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 678d64aa2e)
GetTimeInMillis is called first, which sets clockid to
CLOCK_MONOTONIC_COARSE, which is typically much lower resolution than
the callers of GetTimeInMicros want.
Prior to a779fda224, GetTimeInMillis and
GetTimeInMicros did not share a clockid.
Restore the clockid split to fix the granularity of GetTimeInMicros.
Signed-off-by: Peter Harris <pharris@opentext.com>
(cherry picked from commit 937a5b78a2)
A user of Adélie Linux reported that modesetting wasn't working properly on
their Intel i7-9700K-integrated UHD 630 GPU. Xorg.0.log showed:
[ 131.902] (EE) modeset(0): [DRI2] No driver mapping found for PCI device 0x8086 / 0x3e98
[ 131.902] (EE) modeset(0): Failed to initialize the DRI2 extension.
Indeed, that PCI ID is missing from i965_pci_ids. Adding it fixed the issue
and allowed the system to work with i965_dri under modesetting.
(cherry picked from commit d3a26bbf61)
'disp' was already allocated by LookupVendorPrivDispatch above,
clobbering it will do no good.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 709c656297)
Both because extension names are inconsistently capitalized on the wire,
and because the table we're walking spells it COMPOSITE not Composite.
The latter is certainly also a bug, but there's no reason for us to be
that strict.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit bf991a5f98)
Neither opening a screen nor querying its modifiers confers the right to
attach the buffer for any particular pixmap. GetAttr seems more correct.
Fixes: xorg/xserver#550
(cherry picked from commit 086c2e3de5)
If the driver calls xf86HandleColormaps, CMapChangeGamma updates the HW
gamma LUT of all CRTCs via xf86RandR12LoadPalette. However,
xf86RandR12ChangeGamma was then clobbering the gamma LUT of the RandR
1.2 compatibility output's CRTC with the gamma curves computed from the
screen's global gamma values.
Fix this by bailing if xf86RandR12LoadPalette is installed.
Fixes: 02ff0a5d7e "xf86RandR12: Fix XF86VidModeSetGamma triggering a
BadImplementation error"
(cherry picked from commit 30044b2253)
Broken since 69d8ea4a49 because our fake screen
didn't have a root window and writing the XKB rules prop would happily
segfault. Fix this by setting up the required bits.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Michel Dänzer michel.daenzer@amd.com
(cherry picked from commit fde27b9b48)
Noticed when porting this logic to xf86-video-nouveau, and valgrind
complained about conditional jump based on uninitialized data.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
(cherry picked from commit 48b1af2718)
Believe it or not, somehow we've never done this in legacy mode! We
currently simply change the DPMS property on the CRTC's output's
respective DRM connector, but this means that we're just setting the
CRTC as inactive-not disabled. From the perspective of the kernel, this
means that any shared resources used by the CRTC are still in use.
This can cause problems for drivers that are not yet fully atomic,
despite using the atomic helpers internally. For instance: if CRTC-1 and
CRTC-2 are still enabled and use shared resources within the kernel (an
MST topology, for example), and then userspace tries to go enable CRTC-3
on the same topology this might suddenly fail if CRTC-3 needs the shared
resources CRTC-1 and CRTC-2 are using. While I don't know of any
situations in the mainline kernel that actually trigger this, future
plans for reworking the atomic check of MST drivers are absolutely
going to make this into a real issue (they already are in my WIP
branches for the kernel).
So: actually do the right thing here and disable CRTCs when they're not
going to be used anymore, even in legacy mode.
Signed-off-by: Lyude Paul <lyude@redhat.com>
(cherry picked from commit 7a44e8d400)
Xwayland creates and destroys the CRTC along with the Wayland outputs,
so there is possibly a case where the number of CRTC drops to 0.
However, `xwl_present_get_crtc()` always return `crtcs[0]` which is
invalid when `numCrtcs` is 0.
That leads to crash if a client queries the Present capabilities when
there is no CRTC, the backtrace looks like:
#0 raise() from libc.so
#1 abort() from libc.so
#2 OsAbort() at utils.c:1350
#3 AbortServer() at log.c:879
#4 FatalError() at log.c:1017
#5 OsSigHandler() at osinit.c:156
#6 OsSigHandler() at osinit.c:110
#7 <signal handler called>
#8 main_arena() from libc.so
#9 proc_present_query_capabilities() at present_request.c:236
#10 Dispatch() at dispatch.c:478
#11 dix_main() at main.c:276
To avoid returning an invalid pointer (`crtcs[0]`) in that case, simply
check for `numCrtcs` being 0 and return `NULL` in that case.
Thanks to Michel Dänzer <michel.daenzer@amd.com> for pointing this as a
possible cause of the crash.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Bugzilla: https://bugzilla.redhat.com/1609181
(cherry picked from commit e8295c5020)
The buffer release queue has two kinds of entries:
* Pending async flips.
* Completed flips waiting for their buffer to be released by the Wayland
compositor.
xwl_present_timer_callback neither completes async flips nor releases
buffers, so the timer isn't needed for the buffer release queue.
(cherry picked from commit e6cd1c9bde)
Fixes issue #12. Presumably the problem was that Present operations on
unmapped windows were executed immediately instead of only when reaching
the target MSC.
(cherry picked from commit f541615342)
When a window is unrealized, a pending frame callback may never be
called, which could result in repeatedly freezing until the frame timer
fires after a second.
Fixes these symptoms when switching from fullscreen to windowed mode in
sauerbraten.
(cherry picked from commit 8c9538573c)
There's no need to keep track of the window which last performed a
Present flip. This fixes crashes due to the assertion in
xwl_present_flips_stop failing. Fixes issue #10.
The damage generated by a flip only needs to be ignored once, then
xwl_window::present_flipped can be cleared. This may fix freezing in
the (hypothetical) scenario where Present flips are performed on a
window, followed by other drawing requests using the window as the
destination, but nothing triggering xwl_present_flips_stop. The damage
from the latter drawing requests would continue being ignored.
(cherry picked from commit 6b016d58d2)
Completing them from xwl_present_sync_callback had at least two issues:
* It was before the MSC was incremented in xwl_present_frame_callback,
so the MSC value in the completion event could be lower than the
target specified by the client. This could cause hangs with the Mesa
Vulkan drivers.
* It allowed clients to run at a frame-rate higher than the Wayland
compositor's frame-rate, wasting energy on generating frames which
were never displayed. This isn't expected to happen unless the client
specified PresentOptionAsync (in which case flips are still completed
from xwl_present_sync_callback, allowing higher frame-rates).
v2:
* Make xwl_present_has_events return true when there's a pending
"synchronous" flip, so those complete after at most ~1 second even if
the Wayland server doesn't send a frame event.
Bugzilla: https://bugs.freedesktop.org/106713
(cherry picked from commit ace551d8a2)
Apart from simplifying the code, this should also prevent a condition
(which might only be possible with the following fix) reported in
https://gitlab.freedesktop.org/wayland/weston/issues/115#note_52467:
1. xwl_present_timer_callback indirectly calls xwl_present_reset_timer
-> xwl_present_free_timer
2. xwl_present_timer_callback then returns a non-0 value, so DoTimer
calls TimerSet with the old xwl_present_window->frame_timer pointer
which was freed in step 1 => use after free
Calling xwl_present_reset_timer explicitly passes NULL to TimerSet if
step 1 freed xwl_present_window->frame_timer, and it will allocate a new
one.
(cherry picked from commit 5e8b9a3a56)
The function `xwl_glamor_gbm_create_pixmap()` first creates a buffer
objects and then creates the xwl_pixmap from it.
However, `xwl_glamor_gbm_create_pixmap_for_bo()` is not called if the
buffer object creation fails, and `xwl_glamor_gbm_create_pixmap()`
simply returns `glamor_create_pixmap()`.
The problem with this is that if `xwl_glamor_gbm_create_pixmap_for_bo()`
is not called then neither is `xwl_pixmap_set_private()` and further
calls to `xwl_pixmap_get()` will return NULL and cause a NULL pointer
dereference if the return value is not checked:
#0 xwl_glamor_gbm_get_wl_buffer_for_pixmap ()
at hw/xwayland/xwayland-glamor-gbm.c:248
#1 xwl_window_post_damage () at hw/xwayland/xwayland.c:697
#2 xwl_display_post_damage () at hw/xwayland/xwayland.c:759
#3 block_handler () at hw/xwayland/xwayland.c:890
#4 BlockHandler () at dix/dixutils.c:388
#5 WaitForSomething () at os/WaitFor.c:201
#6 Dispatch () at dix/dispatch.c:421
#7 dix_main () at dix/main.c:276
#8 __libc_start_main () at ../csu/libc-start.c:308
#9 _start ()
(gdb) print xwl_pixmap
$1 = (struct xwl_pixmap *) 0x0
Make sure we check for `xwl_pixmap_get()` returned value where relevant
and fail gracefully if this is the case.
See also: https://gitlab.gnome.org/GNOME/mutter/issues/340
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Marco Trevisan <mail@3v1n0.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 036794bebc)
Xwayland will add and remove CRTCs as Wayland outputs are added or
removed.
If there is a pending flip when this occurs, the
`xwl_present_sync_callback()` will be triggered after the Xwayland
output's RRCtrcPtr has been destroyed, hence causing a crash in Xwayland
while trying to use freed memory:
#1 abort ()
#2 OsAbort () at utils.c:1350
#3 AbortServer () at log.c:877
#4 FatalError () at log.c:1015
#5 OsSigHandler () at osinit.c:156
#6 <signal handler called>
#7 dixGetPrivate () at ../include/privates.h:122
#8 dixLookupPrivate () at ../include/privates.h:166
#9 present_screen_priv () at present_priv.h:198
#10 present_wnmd_flip () at present_wnmd.c:358
#11 present_wnmd_execute () at present_wnmd.c:466
#12 present_wnmd_re_execute () at present_wnmd.c:80
#13 xwl_present_sync_callback () at xwayland-present.c:287
#14 ffi_call_unix64 () from /lib64/libffi.so.6
#15 ffi_call () from /lib64/libffi.so.6
#16 wl_closure_invoke () at src/connection.c:1006
#17 dispatch_event () at src/wayland-client.c:1427
#18 dispatch_queue () at src/wayland-client.c:1573
#19 wl_display_dispatch_queue_pending () at src/wayland-client.c:1815
#20 wl_display_dispatch_pending () at src/wayland-client.c:1878
#21 xwl_read_events () at xwayland.c:814
#22 ospoll_wait () at ospoll.c:651
#23 WaitForSomething () at WaitFor.c:208
#24 Dispatch () at ../include/list.h:220
#25 dix_main () at main.c:276
To avoid the issue, get the `ScreenPtr` from the window instead of the
CRTC that might have been just freed, `xwl_present_flip()` has no use
for the CRTC anyway.
Bugzilla: https://bugs.freedesktop.org/108249
Suggested-by: Michel Daenzer <michel.daenzer@amd.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Daenzer <michel.daenzer@amd.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit b768b7d6ce)
xwl_present_window->sync_callback was leaked.
The event memory was leaked if the corresponding buffer had already been
released.
(cherry picked from commit cb0de153bf)
CVE-2018-14665 also made it possible to exploit this to access
memory. With -logfile forbidden when running with elevated privileges
this is no longer an issue.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 248d164eae)
Could cause privilege elevation and/or arbitrary files overwrite, when
the X server is running with elevated privileges (ie when Xorg is
installed with the setuid bit set and started by a non-root user).
CVE-2018-14665
Issue reported by Narendra Shinde and Red Hat.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 50c0cf885a)
Misplaced parenthesis caused us to compare the sizeof, not the readlink return
value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit bd5fe7593f)
Ray Strode
Adam Jackson
Michel Dänzer
Michel Daenzer
Peter Hutterer
Peter Harris
A. Wilcox
Maya Rashish
Alan Coopersmith
Ilia Mirkin
Lionel Landwerlin
Lyude Paul
Olivier Fourdan
Matthieu Herrb