Commit Graph

251 Commits

Author SHA1 Message Date
Hans de Goede
642c1f83b9 glamor/xwayland: Define EGL_NO_X11
Define EGL_NO_X11 everywhere were we also define MESA_EGL_NO_X11_HEADERS,
EGL_NO_X11 is the MESA_EGL_NO_X11_HEADERS equivalent for the egl headers
shipped with libglvnd.

This fixes the xserver not building with the libglvnd-1.2.0 headers:

In file included from /usr/include/EGL/eglplatform.h:128,
                 from /usr/include/epoxy/egl_generated.h:11,
                 from /usr/include/epoxy/egl.h:46,
                 from glamor_priv.h:43,
                 from glamor_composite_glyphs.c:25:
/usr/include/X11/Xlib.h:222:2: error: conflicting types for 'GC'
  222 | *GC;
      |  ^~
In file included from glamor.h:34,
                 from glamor_priv.h:32,
                 from glamor_composite_glyphs.c:25:
../include/gcstruct.h:282:3: note: previous declaration of 'GC' was here
  282 | } GC;
      |   ^~

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 741bd73429)
2019-11-05 08:12:03 -08:00
Carlos Garnacho
63346c7439 xwayland: Handle the case of windows being realized before redirection
If Xwayland gets to realize a window meant for composition before the
compositor redirected windows (i.e. redirect mode is not RedirectDrawManual
yet), the window would stay "invisible" as we wouldn't create a
wl_surface/wl_shell_surface for it at any later point.

This scenario may happen if the wayland compositor sets up a X11 socket
upfront, but waits to raise Xwayland until there are X11 clients. In this
case the first data on the socket is the client's, the compositor can hardly
beat that in order to redirect subwindows before the client realizes a
Window.

In order to jump across this hurdle, allow the late creation of a matching
(shell) surface for the WindowPtr on SetWindowPixmapProc, so it is ensured
to be created after the compositor set up redirection.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 78cc8b6f96)
2019-09-10 14:51:00 +02:00
Carlos Garnacho
12db645c7f xwayland: Refactor surface creation into a separate function
This is just called from xwl_window_realize() ATM, but will be useful in
future commits.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
(cherry picked from commit c2e8ae9640)
2019-09-10 14:50:57 +02:00
Carlos Garnacho
e0af09061f xwayland: Separate DamagePtr into separate window data
This will be dissociated in future commits to handle the cases
where windows are being realized before there is a compositor
handling redirection.

In that case, we still want the DamagePtr to be registered upfront
on RealizeWindowProc before a corresponding xwl_window might be
created. Most notably, it cannot be lazily created on
SetWindowPixmapProc as damage accounting gets broken.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
(cherry picked from commit 4e50440ae2)
2019-09-10 14:50:52 +02:00
Olivier Fourdan
dfd51be3ca xwayland: Do not free a NULL GBM bo
Both `gbm_bo_create()` and `gbm_bo_create_with_modifiers()` can fail and
return `NULL`.

If that occurs, `xwl_glamor_gbm_create_pixmap()` will not create a
pixmap for the (NULL) GBM bo, but would still try to free the bo which
leads to a crash in mesa:

  [...]
  #7  <signal handler called>
  #8  in gbm_bo_destroy (bo=0x0) at ../src/gbm/main/gbm.c:439
  #9  in xwl_glamor_gbm_create_pixmap () at xwayland-glamor-gbm.c:245
  #10 in ProcCreatePixmap () at dispatch.c:1440
  #11 in Dispatch () at dispatch.c:478
  #12 in dix_main () at main.c:276

To avoid the crash, only free the GBM bo if not `NULL`.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Bugzilla: https://bugzilla.redhat.com/1729925
(cherry picked from commit d9ec525059)
2019-07-26 19:44:03 +00:00
Adam Jackson
df7ee10d98 xwayland: Expand the RANDR screen size limits
There's not really a good way to query this from the wayland server, so
just set the maximum to the X11 protocol limits. While we're at it,
lower the minimum screen size to something implausibly small too, just
in case.

Fixes: xorg/xserver#850
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit d0850241c6)
2019-07-26 19:44:03 +00:00
Olivier Fourdan
44c693f45d xwayland: Update screen pixmap on output resize
Running Xwayland non-rootless and resizing the output would lead to a
crash while trying to update the larger areas of the root window.

Make sure we resize the backing pixmap according to the new output size
to avoid the crash.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/834
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit ce9455b5ee)
2019-07-26 19:44:03 +00:00
Carlos Garnacho
c86222d4bd xwayland: Reset scheduled frames after hiding tablet cursor
Hiding the tablet tool cursor results in it being hidden forever after.
This is due to the stale frame callback that will neither be disposed
or replaced. This can be reproduced in krita (X11) as the pointer
cursor is hidden while over the canvas.

Clearing the frame callback ensures the correct behavior in future
xwl_tablet_tool_set_cursor() calls (i.e. a new cursor surface being
displayed, and a new frame callback created), and is 1:1
with xwl_seat_set_cursor() for pointers.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
(cherry picked from commit dea4a74621)
2019-06-06 11:48:13 +02:00
Olivier Fourdan
34ad57e570 xwayland: Check status in GBM pixmap creation
The current code in `xwl_glamor_gbm_create_pixmap_for_bo()` may fail in
several cases that are not checked for:

 - `eglCreateImageKHR()` may have failed to create the image,
 - `glEGLImageTargetTexture2DOES()` may fail and set an error,
 - `glamor_set_pixmap_texture()` may fail for very large pixmaps
    because the corresponding FBO could not be created.

Trying to upload content to a pixmap with no texture will crash Mesa,
glamor and Xwayland, e.g.:

  XXX fail to create fbo.
  (EE)
  (EE) Backtrace:
  (EE) 0: Xwayland (OsSigHandler+0x29)
  (EE) 1: libpthread.so.0 (funlockfile+0x50)
  (EE) 2: libc.so.6 (__memmove_avx_unaligned_erms+0x215)
  (EE) 3: dri/i965_dri.so (_mesa_format_convert+0xab3)
  (EE) 4: dri/i965_dri.so (_mesa_texstore+0x205)
  (EE) 5: dri/i965_dri.so (store_texsubimage+0x28c)
  (EE) 6: dri/i965_dri.so (intel_upload_tex+0x13b)
  (EE) 7: dri/i965_dri.so (texture_sub_image+0x134)
  (EE) 8: dri/i965_dri.so (texsubimage_err+0x150)
  (EE) 9: dri/i965_dri.so (_mesa_TexSubImage2D+0x48)
  (EE) 10: Xwayland (glamor_upload_boxes+0x246)
  (EE) 11: Xwayland (glamor_copy+0x4d1)
  (EE) 12: Xwayland (miCopyRegion+0x96)
  (EE) 13: Xwayland (miDoCopy+0x43c)
  (EE) 14: Xwayland (glamor_copy_area+0x24)
  (EE) 15: Xwayland (damageCopyArea+0xba)
  (EE) 16: Xwayland (compCopyWindow+0x31c)
  (EE) 17: Xwayland (damageCopyWindow+0xd3)
  (EE) 18: Xwayland (miResizeWindow+0x7b7)
  (EE) 19: Xwayland (compResizeWindow+0x3a)
  (EE) 20: Xwayland (ConfigureWindow+0xa96)
  (EE) 21: Xwayland (ProcConfigureWindow+0x7d)
  (EE) 22: Xwayland (Dispatch+0x320)
  (EE) 23: Xwayland (dix_main+0x366)
  (EE) 24: libc.so.6 (__libc_start_main+0xf3)
  (EE) 25: Xwayland (_start+0x2e)
  (EE)
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE)

Check for the possible cases of failure above and fallback to the
regular glamor pixmap creation when an error is detected.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/661
(cherry picked from commit fc6380a11b)
2019-06-05 15:12:31 +02:00
Olivier Fourdan
6711b5c6fd xwayland: Avoid a crash on pointer enter with a grab
On pointer enter notification, Xwayland checks for an existing pointer
warp with a `NULL` sprite.

In turn, `xwl_pointer_warp_emulator_maybe_lock()` checks for an existing
grab and the destination window using `XYToWindow()` which does not
check for the actual sprite not being `NULL`.

So, in some cases, when the pointer enters the surface and there is an
existing X11 grab which is not an ownerEvents grab, Xwayland would crash
trying to dereference the `NULL` sprite pointer:

  #0  __GI_raise ()
  #1  __GI_abort () at abort.c:79
  #2  OsAbort () at utils.c:1351
  #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  XYToWindow (pSprite=0x0, x=0, y=0) at events.c:2880
  #9  xwl_pointer_warp_emulator_maybe_lock () at xwayland-input.c:2673
  #10 pointer_handle_enter () at xwayland-input.c:434

Avoid the crash by simply checking for the sprite being not `NULL` in
`xwl_pointer_warp_emulator_maybe_lock()`

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Bugzilla: https://bugzilla.redhat.com/1708119
(cherry picked from commit 0a07446318)
2019-06-05 15:12:31 +02:00
Peter Hutterer
d0c7483b3e xwayland: fix a realloc OOM error case
Found by coverity

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(Cherry picked from commit 7c25439f0d)
2019-04-05 12:39:00 +02:00
Olivier Fourdan
bb74db6b38 xwayland: search for a render node to use
wl_drm's protocol "device" event provides the path to the DRM device,
which may not be a render node, thus causing Xwayland to fall back to
DRM authentication which may fail if the user has switched to another
VT while Xwayland is starting.

Search for a render node corresponding to the given DRM device and try
to use it instead, as render nodes do not need DRM authentication and
Xwayland can make use of them if it can find one.

Closes: https://bugs.freedesktop.org/108038
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(Cherry picked from commit 361894497c)
2019-04-05 12:33:28 +02:00
Michel Dänzer
5781563371 xwayland/present: Destroy sync_callback in xwl_present_cleanup
xwl_present_cleanup frees the struct xwl_present_window memory,
so if there's a pending callback, we have to destroy it to prevent
use-after-free in xwl_present_sync_callback.

Should fix issue #645.

Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(Cherry picked from commit 2e18eec6f0)
2019-03-25 12:45:52 +01:00
Olivier Fourdan
a352f97954 xwayland: handle case without any crtc
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)
2019-01-09 15:26:33 +01:00
Michel Dänzer
210cd52906 xwayland: Don't take buffer release queue into account for frame timer
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)
2019-01-09 15:26:33 +01:00
Michel Dänzer
7c28b0e34e xwayland: Don't need xwl_window anymore in xwl_present_queue_vblank
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)
2019-01-09 15:26:33 +01:00
Michel Dänzer
4613595709 xwayland: Add xwl_present_unrealize_window
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)
2019-01-09 15:26:33 +01:00
Michel Dänzer
98f41563e6 xwayland: Replace xwl_window::present_window with ::present_flipped
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)
2019-01-09 15:26:33 +01:00
Michel Dänzer
f393801dbb xwayland: Complete "synchronous" Present flips from xwl_present_msc_bump
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)
2019-01-09 15:26:33 +01:00
Michel Dänzer
e646e3054a xwayland: Rename xwl_present_events_notify to xwl_present_msc_bump
And consolidate more code from xwl_present_timer_callback and
xwl_present_frame_callback in it.

(cherry picked from commit 2bfc46d414)
2019-01-09 15:26:33 +01:00
Michel Dänzer
47aed554b7 xwayland: Use xwl_present_reset_timer in xwl_present_timer_callback
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)
2019-01-09 15:26:33 +01:00
Olivier Fourdan
cf8e064ec0 xwayland: do not crash if gbm_bo_create() fails
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)
2019-01-09 15:26:33 +01:00
Michel Dänzer
64f5e6ec2d xwayland: Plug leaks in xwl_present_sync_callback
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)
2019-01-09 15:26:33 +01:00
Adam Jackson
4795c069a5 glamor/egl: Avoid crashing on broken configurations
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)
2018-10-12 11:35:07 -04:00
Adam Jackson
1e3c5d614e glamor_egl: Don't initialize on llvmpipe
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)
2018-10-12 11:35:00 -04:00
Olivier Fourdan
c26a47b4f2 xwayland: Use double for xwl_tablet_tool
So we do not lose subpixel precision in Xwayland.

Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/libinput/libinput/issues/138
(cherry picked from commit 734b2d6907)
2018-10-04 17:27:08 +02:00
Olivier Fourdan
cffac815b9 xwayland: Remove xwl_present_window from privates on cleanup
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)
2018-10-04 17:25:24 +02:00
Lionel Landwerlin
8dd7173eeb xwayland: fix access to invalid pointer
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)
2018-10-04 17:25:19 +02:00
Scott Anderson
48300a7775 xwayland: use wayland axis_discrete event
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)
2018-10-04 17:24:50 +02:00
emersion
cbf1ca2dba xwayland: rotate logical size for RRMode
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)
2018-08-02 10:04:10 -04:00
Olivier Fourdan
18a52a8e16 xwayland: Enable DRI3 for glamor
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)
2018-08-02 10:04:10 -04:00
Lyude Paul
91ec6245d6 glamor: Unbreak glamor_fd_from_pixmap()
When support for allocating GBM BOs with modifiers was added,
glamor_fd_from_pixmap() was changed so that it would return an error if
it got a bo with modifiers set from glamor_fds_from_pixmap(). The
problem is that on systems that support BOs with modifiers,
glamor_fds_from_pixmap() will always return BOs with modifiers.

This means that glamor_fd_from_pixmap() was broken entirely, which broke
a number of other things including glamor_shareable_fd_from_pixmap(),
which meant that modesetting using multiple GPUs with the modesetting
DDX was also broken. Easy reproducer:

- Find a laptop with DRI prime that has outputs connected to the
  dedicated GPU and integrated GPU
- Try to enable one display on each using the modesetting DDX
- Fail

Since there isn't a way to ask for no modifiers from
glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap()
function used by both glamor_fds_from_pixmap() and
glamor_fd_from_pixmap() that calls down to the appropriate
glamor_egl_fd*_from_pixmap() function.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
(cherry picked from commit 186a21c4ba)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
180ab06d45 xwayland: mandatory EGL backend API
The API init_wl_registry() and has_wl_interfaces() are marked as being
optional, but both GBM And EGLStream backends implement them so there is
point in keeping those optional.

Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 92daeb31fa)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
c641d10ef0 xwayland: simplify xwl_glamor_pixmap_get_wl_buffer()
When retrieving the Wayland buffer from a pixmap, if the buffer already
exists, the GBM backend will return that existing buffer.

However, as seen with the Present issues, if the call had previously
passed a wrong size, that buffer will remain at the wrong size for as
long as the buffer exists, which is error prone.

Considering that the width/height passed to get_wl_buffer() is always the
actual pixmap  drawable size, and considering that the EGLStream backend
makes no use of the size either, there is really no point in passing the
width/height around.

Simplify the xwl_glamor_pixmap_get_wl_buffer() and EGL backends API by
removing the pixmap size, and use the drawable size instead.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 792359057b)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
79ebd7f689 xwayland: EGL_IMG_context_priority required by EGLStream
xwl_glamor_eglstream_init_egl() uses "EGL_IMG_context_priority"
extension, make sure it's actually available before using it.

Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit bdadaa25f5)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
81969ab773 xwayland: check for EGLStream backend explicitly
Now that we have separate backends for EGLStream and GBM, we can
explicitly check for the EGLStream backend to disable present support
in that case.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 5d843f6947)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
60020989b9 xwayland: refactor EGL backends for wayland registry
To be able to check for availability of the Wayland interfaces required
to run a given EGL backend (either GBM or EGLStream for now), we need
to have each backend structures and vfuncs in place before we enter the
Wayland registry dance.

That basically means that we should init all backends at first, connect
to the Wayland compositor and query the available interfaces and then
decide which backend is available and should be used (or none if either
the Wayland interfaces or the EGL extensions are not available).

For this purpose, hold an egl_backend struct for each backend we are to
consider prior to connect to the Wayland display so that, when we get to
query the Wayland interfaces, everything is in place for each backend to
handle the various Wayland interfaces.

Eventually, when we need to chose which EGL backend to use for glamor,
the available Wayland interfaces and EGL extensions available are all
known to Xwayland.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit d7185a84b6)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
cb698ec2ba xwayland: move EGL backend init to glamor
Move EGL backends initialization to its own function in
xwayland-glamor.c

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 48f037a27c)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
8ffee3a6bd xwayland: Add Wayland interfaces check
Introduces a new egl_backend function to let the EGL backend check for
the presence of the required Wayland interfaces.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit f2fcb4877e)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
aad1525180 xwayland: move egl_backend to its own struct
EGL backend availability requires both EGL extensions and Wayland
interfaces to be present, so we will need to consider multiple backends
during initialization.

As a preliminary work, move the egl_backend to its own struct so that we
can have more than one backend at any given time.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit b74b0f18b8)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
831f7194b7 xwayland: skip drm authentication with render node
If using a render node, we can skip DRM authentication.

Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit de004eefc6)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
60eda2af0a xwayland: GBM should fail w/out "GL_OES_EGL_image"
Surely, we should fail to init GBM backend if "GL_OES_EGL_image" is
missing.

This seems to have been lost with commit 1545e2dba ("xwayland: Decouple
GBM from glamor").

Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit b823b43dca)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
f8e96b22bf xwayland: swap "name" and "id" in init_wl_registry()
Both xwl_glamor_init_wl_registry() and the Wayland global registry
handler use the interface id/name in that order, using name/id in the
egl_backend vfunc makes things confusing and error prone.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 78ce4aa979)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
443e3348bb xwayland: move glamor specific routines
Functions such as:

  xwl_glamor_egl_supports_device_probing()
  xwl_glamor_egl_get_devices()
  xwl_glamor_egl_device_has_egl_extensions()

Are of no use outside of EGLStream support, move them to the relevant
source file.

Similarly, the other glamor functions such as:

  xwl_glamor_init()
  xwl_screen_set_drm_interface()
  xwl_screen_set_dmabuf_interface()
  xwl_glamor_pixmap_get_wl_buffer()
  xwl_glamor_init_wl_registry()
  xwl_glamor_post_damage()
  xwl_glamor_allow_commits()
  xwl_glamor_egl_make_current()

Are useless without glamor support enabled, move those within a
a "#ifdef XWL_HAS_GLAMOR" in xwayland.h

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit f6b2109c1b)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
dea40be935 xwayland: make xwl_output_get_xdg_output() static
Make xwl_output_get_xdg_output() private, it doesn't need to be
available elsewhere.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit d31a7be15e)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
04a19291c9 xwayland: do not disable glamor if EGLStream failed
EGLStream requires glamor, but the opposite is not true. So if someone
passes "-eglstream" with a GPU which does not support EGLStream, we
could maybe still try GBM and be lucky.

That allows Wayland compositors to pass "-eglstream" regardless of the
actual hardware, if they want to enable EGLStream on GPU which support
it.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit e16a6da79d)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
de40a55235 xwayland: process Wayland events after adding screen
When we're done adding a new screen, we need to process any pending
Wayland events again.

Hence we don't end up processing xdg_output events unexpectedly when
glamor is disabled. Be that because "-shm" was passed or "-eglstream"
has failed.

Failing to do that could lead to a crash at startup:

    Xwayland: dixGetPrivateAddr: Assertion `key->initialized' failed.
    (EE)
    (EE) Backtrace:
    (EE) 0: Xwayland (OsSigHandler)
    (EE) 1: libpthread.so.0 (funlockfile)
    (EE) 2: libc.so.6 (gsignal)
    (EE) 3: libc.so.6 (abort)
    (EE) 4: libc.so.6 (?+0x0)
    (EE) 5: libc.so.6 (__assert_fail)
    (EE) 6: Xwayland (dixGetPrivateAddr)
    (EE) 7: Xwayland (_fbGetWindowPixmap)
    (EE) 8: Xwayland (getDrawableDamageRef)
    (EE) 9: Xwayland (damageRegionProcessPending)
    (EE) 10: Xwayland (damagePolyFillRect)
    (EE) 11: Xwayland (miPaintWindow)
    (EE) 12: Xwayland (miWindowExposures)
    (EE) 13: Xwayland (miHandleValidateExposures)
    (EE) 14: Xwayland (SetRootClip)
    (EE) 15: Xwayland (update_screen_size)
    (EE) 16: Xwayland (apply_output_change)
    (EE) 17: libffi.so.6 (ffi_call_unix64)
    (EE) 18: libffi.so.6 (ffi_call)
    (EE) 19: libwayland-client.so.0 (wl_log_set_handler_client)
    (EE) 20: libwayland-client.so.0 (_init)
    (EE) 21: libwayland-client.so.0 (wl_display_dispatch_queue_pending)
    (EE) 22: libwayland-client.so.0 (wl_display_roundtrip_queue)
    (EE) 23: Xwayland (InitInput)
    (EE) 24: Xwayland (dix_main)
    (EE) 25: libc.so.6 (__libc_start_main)
    (EE) 26: Xwayland (_start)
    (EE)
    (EE)
    Fatal server error:
    (EE) Caught signal 6 (Aborted). Server aborting
    (EE)
    Aborted (core dumped)

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 44560af028)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
2d31a40db5 xwayland: "EGL_EXT_device_base" required for EGLStream
eglQueryDevicesEXT() would abort if the required extensions are not
available, meaning that enabling “-eglstream” on a non-EGLStream
capable hardware would lead to an abort().

Check that "EGL_EXT_device_base" extension is available and bail out
early if not, so we don't abort() later in eglQueryDevicesEXT().

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit dbde3fec32)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
65d46b2dfd xwayland: allow "-eglstream" option
The command line option "-eglstream" used to enable EGLStream support
for NVidia GPU was made available only when Xwayland was built with
EGLStream support enabled.

Wayland compositors who spawn Xwayland have no easy way to tell whether
or not Xwayland was built with EGLStream support enabled, and adding
"-eglstream" command line option to Xwayland when it wasn't built with
EGLStream support would prevent Xwayland from starting (“Unrecognized
option” error).

Make sure we support the command line option "-eglstream" regardless of
EGLStream support in Xwayland. Obviously, if Xwayland was built without
EGLStream support, this has no effect.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 06c31e782e)
2018-08-01 11:01:37 -04:00
Olivier Fourdan
2e66ed066e xwayland: use pixmap size on present flip
If the pixmap size does not match the present box size, flickering
occurs.

This can happen when the client changes its size (e.g. switching to
fullscreen), and since the buffer is kept as long as the pixmap is
valid, once the buffer is created, it remains at the wrong (old) size
and causes continuous flickering.

Use the actual pixmap's drawable size instead of the present box to
create the buffer so that it's sized appropriately.

Bugzilla: https://bugs.freedesktop.org/106841
Fixes: 0fb2cca193 "xwayland: Preliminary support for Present's new
                     window flip mode"
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
(cherry picked from commit 1993f147d0)
2018-06-19 09:52:40 -04:00