Skip to content
GitLab
  1. 06 Nov, 2019 1 commit
  3. 05 Nov, 2019 1 commit
  5. 04 Nov, 2019 1 commit
    • Hans de Goede's avatar
      glamor/xwayland: Define EGL_NO_X11 · 741bd734
      Hans de Goede authored 
      

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: default avatarHans de Goede <hdegoede@redhat.com>
      741bd734
  7. 23 Sep, 2019 2 commits
  9. 23 Jul, 2019 1 commit
    • Olivier Fourdan's avatar
      xwayland: Do not free a NULL GBM bo · d9ec5250
      Olivier Fourdan authored 
      

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's avatarOlivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
Bugzilla: https://bugzilla.redhat.com/1729925
      d9ec5250
  11. 28 May, 2019 2 commits
    • Olivier Fourdan's avatar
      xwayland: check `glamor_set_pixmap_texture()` status · 48f4ab75
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed 
      

With `glamor_set_pixmap_texture()` returning its status, remove the hack
and use the return value.

Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      48f4ab75
    • Olivier Fourdan's avatar
      xwayland: Check status in GBM pixmap creation · fc6380a1
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed 
      

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's avatarOlivier Fourdan <ofourdan@redhat.com>
Closes: xorg/xserver#661
      fc6380a1
  13. 25 Oct, 2018 1 commit
    • Olivier Fourdan's avatar
      xwayland: do not crash if `gbm_bo_create()` fails · 036794be
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed 
      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's avatarOlivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Marco Trevisan's avatarMarco Trevisan <mail@3v1n0.net>
Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      036794be
  15. 05 Oct, 2018 1 commit
  17. 01 Oct, 2018 1 commit
    • Olivier Fourdan's avatar
      xwayland: search for a render node to use · 36189449
      Olivier Fourdan authored 
      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's avatarOlivier Fourdan <ofourdan@redhat.com>
      36189449
  19. 28 Sep, 2018 1 commit
    • Adam Jackson's avatar
      glamor_egl: Don't initialize on llvmpipe · 0a9415cf
      Adam Jackson authored and Adam Jackson's avatar Adam Jackson committed 
      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 sup...
      0a9415cf
  21. 27 Jun, 2018 1 commit
    • Lyude Paul's avatar
      glamor: Unbreak glamor_fd_from_pixmap() · 186a21c4
      Lyude Paul authored 
      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
g...
      186a21c4
  23. 21 Jun, 2018 6 commits
  25. 08 Jun, 2018 1 commit
  27. 08 May, 2018 1 commit
  29. 24 Apr, 2018 2 commits
    • Lyude Paul's avatar
      xwayland: Add glamor egl_backend for EGLStreams · 54ac0971
      Lyude Paul authored and Adam Jackson's avatar Adam Jackson committed 
      

This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.

EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.

This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps.  no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:

- egl_backend.allow_commits for holding off displaying any EGLStream
  backed pixmaps until the point where it's stream is completely
  initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
  surface producer before Xwayland actually damages and commits the
  wl_surface to the screen.

The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.

Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).

While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.

Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
Acked-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      54ac0971
    • Lyude Paul's avatar
      xwayland: Decouple GBM from glamor · 1545e2db
      Lyude Paul authored and Adam Jackson's avatar Adam Jackson committed 
      

This takes all of the gbm related code in wayland-glamor.c and moves it
into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
Additionally, we add the egl_backend struct into xwl_screen in order to
provide hooks for alternative EGL backends such as nvidia's EGLStreams.

Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
Reviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      1545e2db
  31. 10 Apr, 2018 5 commits
  33. 28 Mar, 2018 1 commit
  35. 09 Mar, 2018 1 commit
  37. 05 Mar, 2018 4 commits
  39. 07 Nov, 2017 1 commit
  41. 13 Sep, 2017 1 commit
  43. 03 Jun, 2017 1 commit
  45. 09 Mar, 2017 1 commit
  47. 06 Mar, 2017 1 commit
  49. 05 Oct, 2016 1 commit