Skip to content
Snippets Groups Projects
  1. Apr 24, 2018
    • Adam Jackson's avatar
      xserver 1.20 RC5 · c6ab2102
      Adam Jackson authored
      
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • Daniel Stone's avatar
      dri3: Don't call vfuncs on old DRI3 screens · c593d843
      Daniel Stone authored and Adam Jackson's avatar Adam Jackson committed
      
      Only call the get_supported_modifiers vfunc if the DRI3 screen struct is
      sufficiently new.
      
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      c593d843
    • 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: default 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 and Adam Jackson's avatar Adam Jackson committed
      
      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: default 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 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: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      1545e2db
    • Adam Jackson's avatar
      vfb: Fix man page in re depth · d2d664df
      Adam Jackson authored
      
      32 is not a valid depth, and the default is now 24 not 8.
      
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: default avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      d2d664df
    • Adam Jackson's avatar
      glx: Require depth > 12 for GLX visuals · 79a71375
      Adam Jackson authored
      
      fb is happy to do TrueColor to 8bpp drawables, but mesa is not. Depth 12
      is the biggest pseudocolor anyone ever really did, and 15 is the least
      truecolor.
      
      Without this Xvfb at depth 8 would "have" GLX, but no vendors
      would actually back any of the screens. libGL will attempt to call
      GLXQueryServerString to figure out the GLX version, and vnd will throw
      an error because there's no vendor to dispatch that to, and then clients
      crash.
      
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      79a71375
    • Adam Jackson's avatar
    • Adam Jackson's avatar
      dix: Allow an extension to disable itself · fc25bceb
      Adam Jackson authored
      
      GLX registers an extension before we know if there are any screens that
      can actually do it. It's inconvenient to shrink the extension list, so
      instead allow the extension to simply zero out its base opcode to
      indicate that it needed to panic and disable itself.
      
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      fc25bceb
    • Adam Jackson's avatar
      73a1cb9c
    • Adam Jackson's avatar
      animcur: Fix crash when removing a master device · 9d5af632
      Adam Jackson authored
      Reproducer:
      
      $ Xvfb -ac -noreset :1 &
      $ DISPLAY=:1 xinput create-master touch1
      $ DISPLAY=:1 xinput remove-master "touch1 pointer"
      
      Bugzilla: https://bugs.freedesktop.org/105761
      
      
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      9d5af632
  2. Apr 23, 2018
    • Thomas Klausner's avatar
      sdksyms: Cope with __pid_t and __uint32_t · 82759039
      Thomas Klausner authored and Adam Jackson's avatar Adam Jackson committed
      
      Kludge sdksyms.c generator to not fail on GetClientPid.
      It returns pid_t which on NetBSD is #define pid_t __pid_t
      This slightly alters the GCC preprocessor output which this fragile
      code could not deal with when using GCC 5+
      
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      82759039
    • Mario Kleiner's avatar
      modesetting: Only use modifiers on kms drivers which do support them. · e29d7832
      Mario Kleiner authored and Adam Jackson's avatar Adam Jackson committed
      
      Use the DRM_CAP_ADDFB2_MODIFIERS query to make sure the kms
      driver supports modifiers in the addfb2 ioctl, and fall back
      to addfb ioctl without modifiers if modifiers are unsupported.
      
      E.g., as of Linux 4.17, nouveau-kms so far does not suppport
      modifiers and gets angry if drmModeAddFB2WithModifiers() is
      called (-> failure to set a video mode -> blank screen), but
      Mesa's nvc0+ gallium driver causes gbm_bo_get_modifier() to
      return a valid modifier by translating the default tiling of
      bo's created via gbm_bo_create() into a modifier other than
      DRM_FORMAT_MOD_INVALID (see Mesa's nvc0_miptree_get_modifier()).
      
      Testing for != DRM_FORMAT_MOD_INVALID is apparently not
      sufficient for safe use of drmModeAddFB2WithModifiers.
      
      Bonus: Handle potential failure of populate_format_modifiers().
      
      The required DRM_CAP is defined since libdrm v2.4.65, and we
      require v2.4.89+ for the server, so we can use it unconditionally.
      
      Tested on intel-kms, radeon-kms, nouveau-kms. Fixes failure on
      NVidia Pascal.
      
      Fixes: 2f807c23 ("modesetting: Add support for multi-plane pixmaps when page-flipping")
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Daniel Stone <daniels@collabora.com>
      Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
      Reviewed-by: default avatarLouis-Francis Ratté-Boulianne <lfrb@collabora.com>
      e29d7832
  3. Apr 19, 2018
  4. Apr 18, 2018
    • Olivier Fourdan's avatar
      xwayland: avoid using freed xwl_window on unrealize · 8b8f9007
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed
      
      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
  5. Apr 17, 2018
  6. Apr 16, 2018
  7. Apr 13, 2018
    • 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: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      bf147f67
  8. Apr 12, 2018
  9. Apr 10, 2018
Loading