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)
0a9415cf apparently can tickle bugs in the GL stack where glGetString
returns NULL, presumably because the eglMakeCurrent() didn't manage to
actually install a dispatch table and you're hitting a stub function.
That's clearly not our bug, but if it happens we should at least not
crash. Notice this case and fail gently.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit af151895f3)
Mesa started supporting GL_OES_EGL_image on llvmpipe in 17.3, after this
commit:
commit bbdeddd5fd0b797e1e281f058338b3da4d98029d
Author: Gurchetan Singh <gurchetansingh@chromium.org>
Date: Tue Aug 1 14:49:33 2017 -0700
st/dri: add drisw image extension
That's pretty cool, but it means glamor now thinks it can initialize on
llvmpipe. This is almost certainly not what anyone wants, as glamor on
llvmpipe is pretty much uniformly slower than fb.
This fixes both Xorg and Xwayland to refuse glamor in such a setup.
Xephyr is left alone, both because glamor is not the default there and
because Xephyr+glamor+llvmpipe is one of the easier ways to get xts to
exercise glamor.
The (very small) downside of this change is that you lose DRI3 support.
This wouldn't have helped you very much (since an lp glamor blit is
slower than a pixman blit), but it would eliminate the PutImage overhead
for llvmpipe's glXSwapBuffers. A future change should add DRI3 support
for the fb-only case.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 0a9415cf79)
xdmcpSocket survives during the reset, there is no
need to create a new one.
This commit restores logic that was broken by
49c0f2413d in Xorg 1.19.
Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
(cherry picked from commit 32677ce03d)
It is currently (ab)using the screen BlockHandler callback to do
this. But this can cause problems with other extension as their
block handlers might have executed before Composite's. And the
operations Composite does might result in them wanting to change
timeouts.
Practically this caused problems for TigerVNC's VNC extension which
failed to send out updates for Composite's screen updates.
(cherry picked from commit 1bd5d0a53c)
The destination is always either on the stack or in the middle of some
struct.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 43a0f9a5db)
The mode (CoordModeOrigin or CoordModePrevious) was not taken into
account when computing the box. The result was a bad drawing of
points in some situations (on my hardware/software configuration,
calling XDrawString followed by XDrawPoints in the mode
CoordModePrevious).
Signed-off-by: Cedric Roux <sed@free.fr>
Signed-off-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit bc36594e0e)
The old code would not in fact validate the option value, though it
might complain about it in the log. It also didn't let you set some
legal values that the -maxclients command line option would.
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 7d689f049c)
Coverity complains about a use after free in here after the
freeing, I can't follow the linked list so well, but whot
says the device can only be on one list once, so break should
fix it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit ba0f5d854f)
This saves us having to make sure we clean it up.
Pointed out by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit b6c29a881e)
This is created using XNFstrdup, so it needs to be freed.
Pointed out by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit f0a5c0d1fd)
Avoids having to free the malloced object.
Pointed out by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit c7fa6a0a0d)
Pointed out by coverity.
v2: set modifies_failed to NULL at start (whot)
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 51ae6126dc)
Otherwise if the VERIFY_SHMSIZE macro fails we leak the drawables
we allocated earlier.
Noticed by coverity scan.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 3439929c51)
Xwayland's `xwl_destroy_window()` invokes `xwl_present_cleanup()`
before the common `DestroyWindow()`.
But then `DestroyWindow()` calls `present_destroy_window()` which will
possibly end up in `xwl_present_abort_vblank()` which will try to access
data that was previously freed by `xwl_present_cleanup()`:
Invalid read of size 8
at 0x434184: xwl_present_abort_vblank (xwayland-present.c:378)
by 0x53785B: present_wnmd_abort_vblank (present_wnmd.c:651)
by 0x53695A: present_free_window_vblank (present_screen.c:87)
by 0x53695A: present_destroy_window (present_screen.c:152)
by 0x42A90D: xwl_destroy_window (xwayland.c:653)
by 0x584298: compDestroyWindow (compwindow.c:613)
by 0x53CEE3: damageDestroyWindow (damage.c:1570)
by 0x4F1BB8: DbeDestroyWindow (dbe.c:1326)
by 0x46F7F6: FreeWindowResources (window.c:1031)
by 0x472847: DeleteWindow (window.c:1099)
by 0x46B54C: doFreeResource (resource.c:880)
by 0x46C706: FreeClientResources (resource.c:1146)
by 0x446ADE: CloseDownClient (dispatch.c:3473)
Address 0x182abde0 is 80 bytes inside a block of size 112 free'd
at 0x4C2FDAC: free (vg_replace_malloc.c:530)
by 0x42A937: xwl_destroy_window (xwayland.c:647)
by 0x584298: compDestroyWindow (compwindow.c:613)
by 0x53CEE3: damageDestroyWindow (damage.c:1570)
by 0x4F1BB8: DbeDestroyWindow (dbe.c:1326)
by 0x46F7F6: FreeWindowResources (window.c:1031)
by 0x472847: DeleteWindow (window.c:1099)
by 0x46B54C: doFreeResource (resource.c:880)
by 0x46C706: FreeClientResources (resource.c:1146)
by 0x446ADE: CloseDownClient (dispatch.c:3473)
by 0x446DA5: ProcKillClient (dispatch.c:3279)
by 0x4476AF: Dispatch (dispatch.c:479)
Block was alloc'd at
at 0x4C30B06: calloc (vg_replace_malloc.c:711)
by 0x433F46: xwl_present_window_get_priv (xwayland-present.c:54)
by 0x434228: xwl_present_get_crtc (xwayland-present.c:302)
by 0x539728: proc_present_query_capabilities (present_request.c:227)
by 0x4476AF: Dispatch (dispatch.c:479)
by 0x44B5B5: dix_main (main.c:276)
by 0x75F611A: (below main) (libc-start.c:308)
This is because `xwl_present_cleanup()` frees the memory but does not
remove it from the window's privates, and `xwl_present_abort_vblank()`
will still find it and hence try to access that freed memory...
Remove `xwl_present_window` from window's privates on cleanup so that no
other function can find and reuse that data once it's freed.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1616269
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 3f31f56929)
xwl_output->randr_crtc is used in the update_screen_size() function :
==5331== Invalid read of size 4
==5331== at 0x15263D: update_screen_size (xwayland-output.c:190)
==5331== by 0x152C48: xwl_output_remove (xwayland-output.c:413)
==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814)
==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651)
==5331== by 0x2A5322: WaitForSomething (WaitFor.c:208)
==5331== by 0x27574B: Dispatch (dispatch.c:421)
==5331== by 0x279945: dix_main (main.c:276)
==5331== Address 0x1aacb5f4 is 36 bytes inside a block of size 154 free'd
==5331== at 0x48369EB: free (vg_replace_malloc.c:530)
==5331== by 0x1F8AE8: RROutputDestroyResource (rroutput.c:421)
==5331== by 0x29A2AC: doFreeResource (resource.c:880)
==5331== by 0x29AE5B: FreeResource (resource.c:910)
==5331== by 0x152BE0: xwl_output_remove (xwayland-output.c:408)
==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814)
==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651)
==5331== Block was alloc'd at
==5331== at 0x48357BF: malloc (vg_replace_malloc.c:299)
==5331== by 0x1F93E0: RROutputCreate (rroutput.c:83)
==5331== by 0x152A75: xwl_output_create (xwayland-output.c:361)
==5331== by 0x14BE59: registry_global (xwayland.c:764)
==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814)
==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651)
==5331== by 0x2A5322: WaitForSomething (WaitFor.c:208)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
(cherry picked from commit 53ce2ba0a1)
Commit 99f0365b "Add a command line argument for disabling indirect GLX"
added a test to check if indirect context are enabled in
`DoCreateContext()` but `__glXDisp_CreateContextAttribsARB()` doesn't
use `DoCreateContext()` and doesn't check if indirect context is
enabled.
As a result, clients can still manage to create indirect contexts using
`glXCreateContextAttribsARB()` even if indirect contexts are disabled,
which can possibly crash Xservers such as Xwayland or Xephyr when the
context is destroyed.
To avoid the issue, check for `enableIndirectGLX` in
`__glXDisp_CreateContextAttribsARB()` as well.
Fixes: 99f0365b "Add a command line argument for disabling indirect GLX"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107508
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 75448671ab)
When a vblank has been marked as aborted, it's going to be free in the
flip_notify function when stopped. We can't notify it after it's
stopped because the pointer is invalid.
Valgrind backtrace:
==5331== Invalid read of size 8
==5331== at 0x212B4D: present_vblank_notify (present_vblank.c:34)
==5331== by 0x21439B: present_wnmd_flip_notify (present_wnmd.c:194)
==5331== by 0x21439B: present_wnmd_event_notify (present_wnmd.c:228)
==5331== by 0x156216: xwl_present_sync_callback (xwayland-present.c:282)
==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814)
==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651)
==5331== by 0x2A5322: WaitForSomething (WaitFor.c:208)
==5331== by 0x27574B: Dispatch (dispatch.c:421)
==5331== Address 0x1b44dc98 is 40 bytes inside a block of size 184 free'd
==5331== at 0x48369EB: free (vg_replace_malloc.c:530)
==5331== by 0x213B0A: present_wnmd_free_idle_vblanks (present_wnmd.c:118)
==5331== by 0x213B0A: present_wnmd_flips_stop (present_wnmd.c:161)
==5331== by 0x2143EF: present_wnmd_flip_notify (present_wnmd.c:192)
==5331== by 0x2143EF: present_wnmd_event_notify (present_wnmd.c:228)
==5331== by 0x156216: xwl_present_sync_callback (xwayland-present.c:282)
==5331== by 0x6570FCD: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x657093E: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==5331== by 0x4DDB183: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD79D8: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x4DD8EA3: wl_display_dispatch_queue_pending (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.3.0)
==5331== by 0x14BCCA: xwl_read_events (xwayland.c:814)
==5331== by 0x2AC0D0: ospoll_wait (ospoll.c:651)
==5331== by 0x2A5322: WaitForSomething (WaitFor.c:208)
==5331== Block was alloc'd at
==5331== at 0x48377D5: calloc (vg_replace_malloc.c:711)
==5331== by 0x212D9F: present_vblank_create (present_vblank.c:69)
==5331== by 0x214014: present_wnmd_pixmap (present_wnmd.c:610)
==5331== by 0x21576C: proc_present_pixmap (present_request.c:150)
==5331== by 0x27599D: Dispatch (dispatch.c:479)
==5331== by 0x279945: dix_main (main.c:276)
==5331== by 0x633AB16: (below main) (libc-start.c:310)
v2: Still notify aborted flips (Roman)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107314
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit ce271535ad)
This prevents multiple scroll events happening for wayland compositors
which send axis values other than 10. For example, libinput will
typically return 15 for each scroll wheel step, and if a wayland
compositor sends those to xwayland without normalising them, 2 scroll
wheel steps will end up as 3 xorg scroll events. By listening for the
discrete_axis event, this will now correctly send only 2 xorg scroll
events.
The wayland protocol gurantees that there will always be an axis event
following an axis_discrete event. However, it does not gurantee that
other events (including other axis_discrete+axis pairs) will not happen
in between them. So we must keep a list of outstanding axis_discrete
events.
Signed-off-by: Scott Anderson <scott@anderso.nz>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit cd285922cd)
The X will be crashed on the system with other DDX driver,
such as amdgpu.
show the log like:
randr: falling back to unsynchronized pixmap sharing
(EE)
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e)
(EE) 1: /usr/lib/xorg/Xorg (0x55cb0151a000+0x1b5ce9)
(EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1587a1d000+0x11390)
(EE)
(EE) Segmentation fault at address 0x0
(EE)
The issue is that modesetting as the master, and amdgpu as the slave.
Thus, when the master attempts to access pSlavePixPriv in ms_dirty_update(),
problems result due to the fact that it's accessing AMD's 'ppriv' using the
modesetting structure definition.
Apart from fixing crash issue, the patch fix other issue in master interface
in which driver should refer to master pixmap.
Signed-off-by: Jim Qu <Jim.Qu@amd.com>
Reviewed-by: Alex Goins <agoins@nvidia.com>
(cherry picked from commit f79e536851)
The purpose of rrCheckPixmapBounding() is to make sure that the fb is large
enough to accommodate the region scanned out by a GPU screen. Currently, however,
it will actually shrink the fb if it's larger than it needs to be.
This is a problem when combining PRIME output slaving with arbitrary transforms
with xrandr.
Although arbitrary transforms are not supposed to constrain the size of the fb
(https://lists.freedesktop.org/archives/xorg-devel/2018-January/055563.html),
xrandr will use RRSetScreenSize to resize the desktop to accommodate scaling
transforms, e.g. scaling a 1920x1080 display to 3840x2160 will result in a
desktop size of 3840x2160.
In the case of PRIME, rrCheckPixmapBounding() will be called after
RRSetScreenSize() and it will resize the fb back down to what it would be
without the scaling transform, e.g. 1920x1080. This represents divergence in
behavior between PRIME and non-PRIME outputs.
I had originally made rrCheckPixmapBounding() account for arbitrary transforms,
but realized that the fb being large enough to accommodate arbitrary transforms
is not a hard requirement enforced in the server. Instead, this change simply
makes it so that rrCheckPixmapBounding() will only resize the fb to be larger
than it already is, preventing it from stepping on prior requests to increase
the size of the fb.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit a90f33721e)
Not sure what if anything calls XSetDeviceModifierMapping() but this would've
failed all the time. check_modmap_change() returns Success but we were
treating it like a boolean. Fix this.
Reported-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 4fe02b8da3)
Instead of having every video driver loop over any pending leases to
free them during CloseScreen, do this up in the DIX layer by
terminating leases when a leased CRTC or Output is destroyed and
(just to make sure), also terminating leases in RRCloseScreen. The
latter should "never" get invoked as any lease should be associated
with a resource which was destroyed.
This is required as by the time the driver's CloseScreen function is
invoked, we've already freed all of the DIX randr structures and no
longer have any way to reference the leases
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960
Cc: Thomas Hellstrom <thellstrom@vmware.com>
(cherry picked from commit 1ef7aed3e2)
Control flow is:
PanoramiXMaybeAddDepth() allocates an array size 240 (pDepth->numVisuals)
PanoramiXMaybeAddVisual() finds up to 270 matches (pScreen->numVisuals)
and writes those into the previously allocated array.
This caused invalid reads/writes followed by eventually a double-free abort.
Reproduced with xorg-integration-tests server test
XineramaTest.ScreenCrossing/* (and a bunch of others).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 93cafb0828)
The logical size is the size of the output in the global compositor
space. The mode width/height should be scaled as in the logical
size, but shouldn't be transformed. Thus we need to rotate back
the logical size to be able to use it as the mode width/height.
This fixes issues with pointer input on transformed outputs.
Signed-Off-By: Simon Ser <contact@emersion.fr>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit ce2dde9ed0)
glamor_fds_from_pixmap() will bail out early if DRI3 is not enabled,
unfortunately Xwayland's glamor code would not set it as enabled which
would lead to blank pixmaps when using texture from pixmap.
Make sure to mark DRI3 as enabled from glamor_egl_screen_init() in
Xwayland.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107287
Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit cdec2b3c19)
The recent rewrite of modesetting driver broke the 24bpp support.
As typically found on cirrus KMS, it leads to a blank screen, spewing
the error like:
failed to add fb -22
(EE) modeset(0): failed to set mode: Invalid argument
The culript is that the wrong bpp value of the front buffer is passed
to drmModeAddFB(). Fix it by replacing with the back buffer bpp,
drmmode->kbpp.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Stefan Dirsch <sndirsch@suse.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit d625e16918)