1. 10 Sep, 2019 3 commits
  2. 09 Jan, 2019 2 commits
    • Michel Dänzer's avatar
      xwayland: Add xwl_present_unrealize_window · 46135957
      Michel Dänzer authored
      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 8c953857)
      46135957
    • Michel Dänzer's avatar
      xwayland: Replace xwl_window::present_window with ::present_flipped · 98f41563
      Michel Dänzer authored
      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 6b016d58)
      98f41563
  3. 01 Aug, 2018 6 commits
    • Olivier Fourdan's avatar
      xwayland: simplify xwl_glamor_pixmap_get_wl_buffer() · c641d10e
      Olivier Fourdan authored
      
      
      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: default avatarOlivier Fourdan <ofourdan@redhat.com>
      (cherry picked from commit 79235905)
      c641d10e
    • Olivier Fourdan's avatar
      xwayland: refactor EGL backends for wayland registry · 60020989
      Olivier Fourdan authored
      
      
      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: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Emil Velikov's avatarEmil Velikov <emil.velikov@collabora.com>
      (cherry picked from commit d7185a84)
      60020989
    • Olivier Fourdan's avatar
      xwayland: move EGL backend init to glamor · cb698ec2
      Olivier Fourdan authored
      
      
      Move EGL backends initialization to its own function in
      xwayland-glamor.c
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Emil Velikov's avatarEmil Velikov <emil.velikov@collabora.com>
      (cherry picked from commit 48f037a2)
      cb698ec2
    • Olivier Fourdan's avatar
      xwayland: do not disable glamor if EGLStream failed · 04a19291
      Olivier Fourdan authored
      
      
      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: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Emil Velikov's avatarEmil Velikov <emil.velikov@collabora.com>
      (cherry picked from commit e16a6da7)
      04a19291
    • Olivier Fourdan's avatar
      xwayland: process Wayland events after adding screen · de40a552
      Olivier Fourdan authored
      
      
      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: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Emil Velikov's avatarEmil Velikov <emil.velikov@collabora.com>
      (cherry picked from commit 44560af0)
      de40a552
    • Olivier Fourdan's avatar
      xwayland: allow "-eglstream" option · 65d46b2d
      Olivier Fourdan authored
      
      
      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: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Emil Velikov's avatarEmil Velikov <emil.velikov@collabora.com>
      (cherry picked from commit 06c31e78)
      65d46b2d
  4. 08 May, 2018 1 commit
  5. 07 May, 2018 1 commit
  6. 24 Apr, 2018 3 commits
    • Lyude Paul's avatar
      xwayland: Add glamor egl_backend for EGLStreams · 54ac0971
      Lyude Paul authored
      
      
      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: Add xwayland-config.h · 994f7810
      Lyude Paul authored
      
      
      Just a small autogenerated header that will soon contain more then just
      one macro.
      Signed-off-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>
      994f7810
    • Lyude Paul's avatar
      xwayland: Decouple GBM from glamor · 1545e2db
      Lyude Paul authored
      
      
      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
  7. 18 Apr, 2018 1 commit
    • Olivier Fourdan's avatar
      xwayland: avoid using freed xwl_window on unrealize · 8b8f9007
      Olivier Fourdan authored
      xwl_unrealize_window() would use freed xwl_window which can lead to
      various memory corruption and crashes, as reported by valgrind:
      
       Invalid read of size 8
          at 0x42C802: xwl_present_cleanup (xwayland-present.c:84)
          by 0x42BA67: xwl_unrealize_window (xwayland.c:601)
          by 0x541EE9: compUnrealizeWindow (compwindow.c:285)
          by 0x57E1FA: UnrealizeTree (window.c:2816)
          by 0x581189: UnmapWindow (window.c:2874)
          by 0x54EB26: ProcUnmapWindow (dispatch.c:879)
          by 0x554B7D: Dispatch (dispatch.c:479)
          by 0x558BE5: dix_main (main.c:276)
          by 0x7C4B1BA: (below main) (libc-start.c:308)
        Address 0xf520f60 is 96 bytes inside a block of size 184 free'd
          at 0x4C2EDAC: free (vg_replace_malloc.c:530)
          by 0x42B9FB: xwl_unrealize_window (xwayland.c:624)
          by 0x541EE9: compUnrealizeWindow (compwindow.c:285)
          by 0x57E1FA: UnrealizeTree (window.c:2816)
          by 0x581189: UnmapWindow (window.c:2874)
          by 0x54EB26: ProcUnmapWindow (dispatch.c:879)
          by 0x554B7D: Dispatch (dispatch.c:479)
          by 0x558BE5: dix_main (main.c:276)
          by 0x7C4B1BA: (below main) (libc-start.c:308)
        Block was alloc'd at
          at 0x4C2FB06: calloc (vg_replace_malloc.c:711)
          by 0x42B307: xwl_realize_window (xwayland.c:488)
          by 0x541E59: compRealizeWindow (compwindow.c:268)
          by 0x57DA40: RealizeTree (window.c:2617)
          by 0x580B28: MapWindow (window.c:2694)
          by 0x54EA2A: ProcMapWindow (dispatch.c:845)
          by 0x554B7D: Dispatch (dispatch.c:479)
          by 0x558BE5: dix_main (main.c:276)
          by 0x7C4B1BA: (below main) (libc-start.c:308)
      
      This is because UnrealizeTree() traverses the tree from top to bottom,
      which invalidates the assumption that if the Window doesn't feature an
      xwl_window on its own, it's the xwl_window of its first ancestor with
      one.
      
      This reverts commit 82df2ce3
      
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      8b8f9007
  8. 16 Apr, 2018 1 commit
  9. 13 Apr, 2018 1 commit
    • Adam Jackson's avatar
      xwayland: Don't crash on WarpPointer(dest_w = None) · bf147f67
      Adam Jackson authored
      
      
      Turns out that's legal, and xts exercises it, and we crash:
      
          Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
          dixGetPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:122
          122	    return (char *) (*privates) + key->offset;
          (gdb) bt
          #0  dixGetPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:122
          #1  dixLookupPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:166
          #2  xwl_window_of_top (window=0x0) at xwayland.c:128
          #3  xwl_cursor_warped_to (device=<optimized out>, screen=0x268b6e0, client=<optimized out>, window=0x0, sprite=0x300bb30,
              x=2400, y=1350) at xwayland.c:292
          #4  0x00000000005622ec in ProcWarpPointer (client=0x32755d0) at events.c:3618
      
      In this case, x/y are the screen-space coordinates where the pointer
      ends up, and we need to look up the (X) window there.
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      bf147f67
  10. 28 Mar, 2018 2 commits
  11. 05 Mar, 2018 1 commit
  12. 14 Feb, 2018 2 commits
    • Adam Jackson's avatar
      miinitext: Load GLX on the mi path · 67c303ff
      Adam Jackson authored
      
      
      Add a stub for Xnest so it continues to link, but otherwise we support
      GLX on every server so there's no need to make every DDX add it.
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      67c303ff
    • Adam Jackson's avatar
      glx: Use vnd layer for dispatch (v4) · d8ec33fe
      Adam Jackson authored
      
      
      The big change here is MakeCurrent and context tag tracking. We now
      delegate context tags entirely to the vnd layer, and simply store a
      pointer to the context state as the tag data. If a context is deleted
      while it's current, we allocate a fake ID for the context and move the
      context state there, so the tag data still points to a real context. As
      a result we can stop trying so hard to detach the client from contexts
      at disconnect time and just let resource destruction handle it.
      
      Since vnd handles all the MakeCurrent protocol now, our request handlers
      for it can just be return BadImplementation. We also remove a bunch of
      LEGAL_NEW_RESOURCE, because now by the time we're called vnd has already
      allocated its tracking resource on that XID.
      
      v2: Update to match v2 of the vnd import, and remove more redundant work
      like request length checks.
      
      v3: Add/remove the XID map from the vendor private thunk, not the
      backend. (Kyle Brenneman)
      
      v4: Fix deletion of ghost contexts (Kyle Brenneman)
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      d8ec33fe
  13. 06 Feb, 2018 1 commit
    • Lyude Paul's avatar
      xwayland: Don't process cursor warping without an xwl_seat · 98edb9a3
      Lyude Paul authored
      
      
      Unfortunately, on my machine Xwayland immediately crashes when I try to
      start it. gdb backtrace:
      
       #0  0x00007ffff74f0e79 in wl_proxy_marshal () from target:/lib64/libwayland-client.so.0
       #1  0x0000000000413172 in zwp_confined_pointer_v1_destroy (zwp_confined_pointer_v1=0x700000000)
           at hw/xwayland/Xwayland@exe/pointer-constraints-unstable-v1-client-protocol.h:612
       #2  0x0000000000418bc0 in xwl_seat_destroy_confined_pointer (xwl_seat=0x8ba2a0)
           at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2839
       #3  0x0000000000418c09 in xwl_seat_unconfine_pointer (xwl_seat=0x8ba2a0)
           at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2849
       #4  0x0000000000410d97 in xwl_cursor_confined_to (device=0xa5a000, screen=0x8b9d80, window=0x9bdb70)
           at /home/lyudess/Projects/xserver/hw/xwayland/xwayland.c:328
       #5  0x00000000004a8571 in ConfineCursorToWindow (pDev=0xa5a000, pWin=0x9bdb70, generateEvents=1,
           confineToScreen=0) at /home/lyudess/Projects/xserver/dix/events.c:900
       #6  0x00000000004a94b7 in ScreenRestructured (pScreen=0x8b9d80)
           at /home/lyudess/Projects/xserver/dix/events.c:1387
       #7  0x0000000000502386 in RRScreenSizeNotify (pScreen=0x8b9d80)
           at /home/lyudess/Projects/xserver/randr/rrscreen.c:160
       #8  0x000000000041a83c in update_screen_size (xwl_output=0x8e7670, width=3840, height=2160)
           at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:203
       #9  0x000000000041a9f0 in apply_output_change (xwl_output=0x8e7670)
           at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:252
       #10 0x000000000041aaeb in xdg_output_handle_done (data=0x8e7670, xdg_output=0x8e7580)
           at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:307
       #11 0x00007ffff50e9d1e in ffi_call_unix64 () at ../src/x86/unix64.S:76
       #12 0x00007ffff50e968f in ffi_call (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>,
           avalue=<optimized out>) at ../src/x86/ffi64.c:525
       #13 0x00007ffff74f3d8b in wl_closure_invoke () from target:/lib64/libwayland-client.so.0
       #14 0x00007ffff74f0928 in dispatch_event.isra () from target:/lib64/libwayland-client.so.0
       #15 0x00007ffff74f1be4 in wl_display_dispatch_queue_pending () from target:/lib64/libwayland-client.so.0
       #16 0x00007ffff74f200b in wl_display_roundtrip_queue () from target:/lib64/libwayland-client.so.0
       #17 0x0000000000418cad in InitInput (argc=12, argv=0x7fffffffd9c8)
           at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2867
       #18 0x00000000004a20e3 in dix_main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30)
           at /home/lyudess/Projects/xserver/dix/main.c:250
       #19 0x0000000000420cb2 in main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30)
          at /home/lyudess/Projects/xserver/dix/stubmain.c:34
      
      This appears to be the result of xwl_cursor_confined_to() and
      xwl_screen_get_default_seat(). While not against protocol, mutter ends
      up sending xdg_output before wl_seat. xwl_screen_get_default_seat()
      makes the naïve assumption that we always have a valid seat, we end up
      returning a pointer to the empty list itself instead of an actual seat
      and causing ourselves to segfault.
      
      So, actually return NULL in xwl_screen_get_default_seat() if the seat
      list is empty, and skip any pointer confinement processing in
      xwl_cursor_confined_to() when we don't have a seat setup yet.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      98edb9a3
  14. 25 Jan, 2018 2 commits
    • Olivier Fourdan's avatar
      xwayland: place a manual redirect on windows · fc8b7d05
      Olivier Fourdan authored
      
      
      Place a manual redirect on windows on xwl_realize_window() and remove
      it on xwl_unrealize_window() to avoid the X11 window manager removing
      its redirect before Xwayland has unrealized the window (e.g. if the X11
      window manager has terminated unexpectedly)
      
      Suggested by Daniel Stone <daniel@fooishbar.org>
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniel@fooishbar.org>
      fc8b7d05
    • Olivier Fourdan's avatar
      xwayland: remove dirty window unconditionally on unrealize · 3362422e
      Olivier Fourdan authored
      
      
      This is a rare occurrence of a crash in Xwayland for which I don't have
      the reproducing steps, just a core file.
      
      The backtrace looks as follow:
      
        #0  raise () from /usr/lib64/libc.so.6
        #1  abort () from /usr/lib64/libc.so.6
        #2  OsAbort () at utils.c:1361
        #3  AbortServer () at log.c:877
        #4  FatalError () at log.c:1015
        #5  OsSigHandler () at osinit.c:154
        #6  <signal handler called>
        #7  xwl_glamor_pixmap_get_wl_buffer () at xwayland-glamor.c:162
        #8  xwl_screen_post_damage () at xwayland.c:514
        #9  block_handler () at xwayland.c:665
        #10 BlockHandler () at dixutils.c:388
        #11 WaitForSomething () at WaitFor.c:219
        #12 Dispatch () at dispatch.c:422
        #13 dix_main () at main.c:287
      
      The crash is caused by dereferencing “xwl_pixmap->buffer” in
      xwl_glamor_pixmap_get_wl_buffer() because “xwl_pixmap” is NULL.
      
      Reason for this is because the corresponding pixmap is from the root
      window and xwayland is rootless by default.
      
      This can happen if the window was mapped, redirected, damaged and
      unredirected immediately, before the damage is processed by Xwayland.
      
      Make sure to remove the dirty window from the damage list on unrealize
      to prevent this from happening.
      
      Credit goes to Adam Jackson <ajax@nwnk.net> and Daniel Stone
      <daniel@fooishbar.org> for finding the root cause the issue.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      3362422e
  15. 24 Jan, 2018 1 commit
    • Olivier Fourdan's avatar
      xwayland: Add optional xdg-output support · da8de2a7
      Olivier Fourdan authored
      
      
      The xdg-output protocol aims at describing outputs in way which is
      more in line with the concept of an output on desktop oriented systems.
      
      For now it just features the position and logical size which describe
      the output position and size in the global compositor space.
      
      This is however much useful for Xwayland to advertise the output size
      and position to X11 clients which need this to configure their surfaces
      in the global compositor space as the compositor may apply a different
      scale from what is advertised by the output scaling property (to achieve
      fractional scaling, for example).
      
      This was added in wayland-protocols 1.10.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      da8de2a7
  16. 22 Jan, 2018 1 commit
    • Pekka Paalanen's avatar
      xwayland: reduce over-damage · f72587ec
      Pekka Paalanen authored
      
      
      If an X11 app draws a little here, some there, and a tiny bit in the
      opposite corner, using RegionExtents for the damage to be sent to the
      Wayland compositor will cause massive over-damaging.
      
      However, we cannot blindly send an arbitrary number of damage
      rectangles, because there is a risk of overflowing the Wayland
      connection. If that happens, it triggers an abort in libwayland-client.
      
      Try to be more accurate with the damage by sending up to 256 rectangles
      per window, and fall back to extents otherwise. The number is completely
      arbitrary.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      f72587ec
  17. 13 Dec, 2017 1 commit
  18. 06 Dec, 2017 1 commit
  19. 13 Sep, 2017 1 commit
    • Roman Gilg's avatar
      xwayland: Avoid repeatedly looping through window ancestor chain · 82df2ce3
      Roman Gilg authored
      
      
      Calling xwl_window_from_window means looping through the window ancestor
      chain whenever it is called on a child window or on an automatically
      redirected window.
      
      Since these properties and the potential ancestor's xwl_window are constant
      between window realization and unrealization, we can omit the looping by
      always putting the respective xwl_window in the Window's private field on
      its realization. If the Window doesn't feature an xwl_window on its own,
      it's the xwl_window of its first ancestor with one.
      Signed-off-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      82df2ce3
  20. 01 Aug, 2017 1 commit
  21. 07 Jun, 2017 3 commits
  22. 31 May, 2017 1 commit
    • Lyude Paul's avatar
      xwayland: Don't load extension list more than once · 4f29366f
      Lyude Paul authored
      
      
      When running an Xwayland server from the command line, we end up
      resetting the server every time all of the clients connected to the
      server leave. This would be fine, except that xwayland makes the mistake
      of unconditionally calling LoadExtensionList(). This causes us to setup
      the glxExtension twice in a row which means that when we lose our last
      client on the second server generation, we end up trying to call the glx
      destructors twice in a row resulting in a segfault:
      
      (EE)
      (EE) Backtrace:
      (EE) 0: Xwayland (OsSigHandler+0x3b) [0x4982f9]
      (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x70845bf]
      (EE) 2: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x32897d) [0x1196e5bd]
      (EE) 3: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x328a45) [0x1196e745]
      (EE) 4: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x32665f) [0x11969f7f]
      (EE) 5: Xwayland (__glXDRIscreenDestroy+0x30) [0x54686e]
      (EE) 6: Xwayland (glxCloseScreen+0x3f) [0x5473db]
      (EE) 7: Xwayland (glxCloseScreen+0x53) [0x5473ef]
      (EE) 8: Xwayland (dix_main+0x7b6) [0x44c8c9]
      (EE) 9: Xwayland (main+0x28) [0x61c503]
      (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x72b1401]
      (EE) 11: Xwayland (_start+0x2a) [0x4208fa]
      (EE) 12: ? (?+0x2a) [0x2a]
      (EE)
      (EE) Segmentation fault at address 0x18
      (EE)
      Fatal server error:
      (EE) Caught signal 11 (Segmentation fault). Server aborting
      (EE)
      
      Easy reproduction recipe:
      - Start an Xwayland session with the default settings
      - Open a window
      - Close that window
      - Open another window
      - Close that window
      - Total annihilation occurs
      Signed-off-by: Lyude Paul's avatarLyude <lyude@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      4f29366f
  23. 28 Apr, 2017 1 commit
  24. 26 Apr, 2017 1 commit
  25. 23 Feb, 2017 1 commit
    • Pekka Paalanen's avatar
      xwayland: use _XWAYLAND_ALLOW_COMMITS property · 9f4d308c
      Pekka Paalanen authored
      The X11 window manager (XWM) of a Wayland compositor can use the
      _XWAYLAND_ALLOW_COMMITS property to control when Xwayland sends
      wl_surface.commit requests. If the property is not set, the behaviour
      remains what it was.
      
      XWM uses the property to inhibit commits until the window is ready to be
      shown. This gives XWM time to set up the window decorations and internal
      state before Xwayland does the first commit. XWM can use this to ensure
      the first commit carries fully drawn decorations and the window
      management state is correct when the window becomes visible.
      
      Setting the property to zero inhibits further commits, and setting it to
      non-zero allows commits. Deleting the property allows commits.
      
      When the property is changed from zero to non-zero, there will be a
      commit on next block_handler() call provided that some damage has been
      recorded.
      
      Without this patch (i.e. with the old behaviour) Xwayland can and will
      commit the surface very soon as the application window has been realized
      and drawn into.  This races with XWM and may cause visible glitches.
      
      v3:
      - introduced a simple setter for xwl_window::allow_commits
      - split xwl_window_property_allow_commits() out of
        xwl_property_callback()
      - check MakeAtom(_XWAYLAND_ALLOW_COMMITS)
      
      v2:
      - use PropertyStateCallback instead of XACE, based on the patch
        "xwayland: Track per-window support for netwm frame sync" by
        Adam Jackson
      - check property type is XA_CARDINAL
      - drop a useless memcpy()
      
      Weston Bug: https://phabricator.freedesktop.org/T7622
      
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      9f4d308c