1. 03 Jan, 2020 5 commits
    • Roman Gilg's avatar
      xwayland: Check emulation on client toplevel resize · 02d78631
      Roman Gilg authored
      
      
      When a reparented window is resized directly check the emulation instead of
      doing this only when the window manager parent window is resized, what might
      never happen.
      
      For that to work we need to make sure that we compare the current size of the
      client toplevel when looking for an emulated mode.
      Signed-off-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      02d78631
    • Roman Gilg's avatar
      xwayland: Recurse on finding the none-wm owner · 829d56b7
      Roman Gilg authored
      
      
      An X11 window manager might add a chain of parent windows when reparenting to a
      decoration window.
      
      That is for example the case for KWin, which reparents client windows to one
      decoration and another wrapper parent window.
      
      Account for that by a recursion into the tree. For now assume as before that
      all X11 window managers reparent with one child only for these parent windows.
      Signed-off-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      829d56b7
    • Roman Gilg's avatar
      xwayland: Reuse viewport instead of recreating · 11c16733
      Roman Gilg authored
      
      
      When a viewport is already created we can reuse this object instead of
      destroying it and getting a new one for updating the source rectangle and
      destination size.
      Signed-off-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      11c16733
    • Roman Gilg's avatar
      xwayland: Having no viewport return on disable · fd6d41b8
      Roman Gilg authored
      
      
      We can check if there is a viewport in the disable function and otherwise
      return early.
      
      Simplifies the code.
      Signed-off-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      fd6d41b8
    • Aaron Plattner's avatar
      modesetting: Check whether RandR was initialized before calling rrGetScrPriv · 4226c6d0
      Aaron Plattner authored
      Calling rrGetScrPriv when RandR isn't initialized causes an assertion
      failure that aborts the server:
      
       Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed.
      
       Thread 1 "Xorg" received signal SIGABRT, Aborted.
       0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6
       (gdb) bt
       #0  0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6
       #1  0x00007ffff7892897 in abort () from /usr/lib/libc.so.6
       #2  0x00007ffff7892767 in __assert_fail_base.cold () from /usr/lib/libc.so.6
       #3  0x00007ffff78a1526 in __assert_fail () from /usr/lib/libc.so.6
       #4  0x00007ffff7fb57c1 in dixGetPrivateAddr (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:121
       #5  0x00007ffff7fb5822 in dixGetPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:136
       #6  0x00007ffff7fb586a in dixLookupPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:166
       #7  0x00007ffff7fb8445 in CreateScreenResources (pScreen=0x555555ab1790) at ../hw/xfree86/drivers/modesetting/driver.c:1335
       #8  0x000055555576c5e4 in xf86CrtcCreateScreenResources (screen=0x555555ab1790) at ../hw/xfree86/modes/xf86Crtc.c:744
       #9  0x00005555555d8bb6 in dix_main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/main.c:214
       #10 0x00005555557a4f0b in main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/stubmain.c:34
      
      This can happen, for example, if the server is configured with Xinerama
      and there is more than one X screen:
      
       Section "ServerLayout"
         Identifier "crash"
         Screen 0 "modesetting"
         Screen 1 "dummy" RightOf "modesetting"
         Option "Xinerama"
       EndSection
      
       Section "Device"
         Identifier "modesetting"
         Driver "modesetting"
       EndSection
      
       Section "Screen"
         Identifier "modesetting"
         Device "modesetting"
       EndSection
      
       Section "Device"
         Identifier "dummy"
         Driver "dummy"
       EndSection
      
       Section "Screen"
         Identifier "dummy"
         Device "dummy"
       EndSection
      
      The problem does not reproduce if there is only one X screen because of
      this code in xf86RandR12Init:
      
       #ifdef PANORAMIX
           /* XXX disable RandR when using Xinerama */
           if (!noPanoramiXExtension) {
               if (xf86NumScreens == 1)
                   noPanoramiXExtension = TRUE;
               else
                   return TRUE;
           }
       #endif
      
      Fix the problem by checking dixPrivateKeyRegistered(rrPrivKey) before
      calling rrGetScrPriv. This is similar to what the xf86-video-amdgpu
      driver does:
      https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/blob/fd66f5c0bea2b7c22a47bfd5eb1f22d32d166d9c/src/amdgpu_kms.c#L388
      
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      4226c6d0
  2. 23 Dec, 2019 3 commits
  3. 20 Dec, 2019 16 commits
  4. 19 Dec, 2019 1 commit
    • Michel Dänzer's avatar
      xwayland: Create duplicate TrueColor GLXFBConfigs for Composite · 846e81ec
      Michel Dänzer authored and Michel Dänzer's avatar Michel Dänzer committed
      Similar to what is done in Xorg. Not doing this prevented apps from
      using GLX with a Composite visual, e.g. Firefox WebRender or Chromium.
      
      v2:
      * Fix inverted direct_color test, fixes Chromium as well.
      * Drop Composite extension guards, since other Xwayland code calls
        compRedirectWindow/compUnredirectWindow unconditionally anyway.
      
      Closes: xorg/xserver#921
      Fixes: 84692415 "xwayland: Add EGL-backed GLX provider"
      Reviewed-by: Adam Jackson <ajax@redhat.com> # v1
      846e81ec
  5. 17 Dec, 2019 3 commits
  6. 13 Dec, 2019 3 commits
  7. 12 Dec, 2019 1 commit
    • dslater38's avatar
      XWin: Fix infinite loop in GetShift() · 71c3a971
      dslater38 authored and Peter Hutterer's avatar Peter Hutterer committed
      GetShift(int mask) can be called with mask==0, causing
      it to go into an infinite loop.
      
      Note: GetShift(mask) will return 0 for a mask of
      both 0 and -1. The assumption is that if mask == 0,
      then the corresponding bits for which we're calculating
      the shift, are also 0.
      71c3a971
  8. 11 Dec, 2019 1 commit
  9. 03 Dec, 2019 1 commit
  10. 28 Nov, 2019 3 commits
    • Olivier Fourdan's avatar
      xwayland: Use multiple window buffers · cd999f08
      Olivier Fourdan authored
      Xwayland takes care of not attaching a new buffer if a frame callback is
      pending.
      
      Yet, the existing buffer (which was previously attached) may still be
      updated from the X11 side, causing unexpected visual glitches to the
      buffer.
      
      Add multiple buffering to the xwl_window and alternate between buffers,
      to leave the Wayland buffer untouched between frame callbacks and avoid
      stuttering or tearing issues.
      
      Closes: xorg/xserver#835
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      cd999f08
    • Olivier Fourdan's avatar
      xwayland: Add multiple window buffering support · 1c6f875f
      Olivier Fourdan authored
      
      
      Add a mechanism to create, recycle and destroy window buffers when
      needed.
      
      Typically, this adds a new `xwl_window_buffer` structure which
      represents a buffer for a given Xwayland window.
      
      Each Xwayland window has two different pools of buffers:
      
       - The available buffers pool:
         Those are buffers which where created previously and that have either
         not been submitted to the compositor or submitted and released.
      
       - The unavailable buffers pool:
         Those are typically the buffers which are being used by the
         compositor, awaiting a release.
      
      Initially, an Xwayland window starts with both pools empty. As soon as a
      new buffer is needed, it's either created (if there is none available)
      or picked from the pool of available buffers.
      
      Once submitted to the compositor, the buffer is moved to the pool of
      unavailable buffers. When the corresponding `wl_buffer` is released by
      the compositor, it is moved back to pool of available buffers again to
      be reused when needed.
      
      To avoid keeping too many buffers around doing nothing, a garbage
      collection of older, unused buffers also takes care of disposing the
      buffers being unused for some time.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      1c6f875f
    • Olivier Fourdan's avatar
      xwayland: Add buffer release callback · 77658741
      Olivier Fourdan authored
      
      
      The API `wl_buffer_add_listener` is misleading in the sense that there
      can be only one `wl_buffer` release callback, and trying to add a new
      listener when once is already in place will lead to a protocol error.
      
      The Xwayland EGL backends may need to set up their own `wl_buffer`
      release listener, meaning that there is no way to our own `wl_buffer`
      release callback.
      
      To avoid the problem, add our own callback API to be notified when the
      `wl_buffer` associated with an `xwl_pixmap` is released, triggered from
      the different `xwl_pixmap` implementations.
      
      Also update the Present code to use the new buffer release callback API.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      77658741
  11. 26 Nov, 2019 2 commits
  12. 25 Nov, 2019 1 commit