1. 15 Jan, 2021 1 commit
  2. 10 Jan, 2021 1 commit
  3. 15 Dec, 2020 1 commit
  4. 26 Nov, 2020 1 commit
    • Chris Wilson's avatar
      sna: Defer fbGetWindowPixmap() for sna_composite · 9236c582
      Chris Wilson authored
      Mike Lothian ran into a surprising situation where compScreenUpdate was
      calling CompositePicture without a pixmap attached to the destination
      Window, and so we found ourselves chasing a NULL PixmapPtr.
        #1  to_sna_from_pixmap (pixmap=0x0) at sna.h:521
        #2  sna_composite (op=<optimized out>, src=0x55b3346c1420, mask=0x0,
            dst=0x55b3346c1d50, src_x=<optimized out>, src_y=<optimized out>, mask_x=0,
            mask_y=0, dst_x=0, dst_y=0, width=3840, height=2160) at sna_composite.c:652
        #3  0x000055b33202c208 in damageComposite (op=<optimized out>,
            pSrc=0x55b3346c1420, pMask=0x0, pDst=0x55b3346c1d50, xSrc=<optimized out>,
            ySrc=<optimized out>, xMask=0, yMask=0, xDst=0, yDst=0, width=3840,
            height=2160) at damage.c:513
        #4  0x000055b33201820c in CompositePicture (op=<optimized out>,
            op@entry=1 '\001', pSrc=pSrc@entry=0x55b3346c1420, pMask=pMask@entry=0x0,
            pDst=pDst@entry=0x55b3346c1d50, xSrc=xSrc@entry=0, ySrc=ySrc@entry=0,
            xMask=0, yMask=0, xDst=0, yDst=0, width=3840, height=2160) at picture.c:1547
        #5  0x000055b331fc85d3 in compWindowUpdateAutomatic (
            pWin=pWin@entry=0x55b3343a6bc0) at compwindow.c:705
        #6  0x000055b331fca029 in compPaintWindowToParent (pWin=pWin@entry=0x55b3343a6bc0)
            at compwindow.c:729
        #7  0x000055b331fc9fbb in compPaintChildrenToWindow (pWin=0x55b333e77b50)
            at compwindow.c:744
        #8  0x000055b331fca59f in compScreenUpdate (pClient=<optimized out>,
            closure=<optimized out>) at compalloc.c:57
        #9  0x000055b331f3abf4 in ProcessWorkQueue () at dixutils.c:536
        #10 0x000055b3320aaa51 in WaitForSomething (are_ready=<optimized out>)
            at WaitFor.c:192
        #11 0x000055b331f361a9 in Dispatch () at dispatch.c:421
        #12 0x000055b331f39cec in dix_main (argc=13, argv=0x7ffcf273f538,
            envp=<optimized out>) at main.c:276
        #13 0x000055b331f247de in main (argc=<optimized out>, argv=<optimized out>,
            envp=<optimized out>) at stubmain.c:34
      Fortuitously, that drawable was also fully clipped so that it took an
      early exit and so we can hide the segfault by delaying querying the
      pixmap until after the clip check.
      The ongoing mystery is how we ended up in that state in the first place.
      Closes: #204
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
  5. 16 Nov, 2020 2 commits
  6. 20 Aug, 2020 1 commit
  7. 15 May, 2020 1 commit
  8. 11 May, 2020 1 commit
  9. 06 May, 2020 1 commit
    • Chris Wilson's avatar
      sna/dri2: Prevent copying stale buffers · e781d43d
      Chris Wilson authored
      The back buffer of window/pixmap is invalidated by DRI2ScheduleSwap, and
      is not available until the client calls DRI2GetBuffers. If they try to
      use their old handles, they will only get stale data. Similarly if they
      ask us to DRI2CopyRegion before the GetBuffers has reallocated a new
      back buffer, that back buffer is stale. Since the back buffer is
      out-of-date [likely containing data from a couple of swaps ago], we
      should ignore the copy to avoid glitching [by hopefully having a less
      noticeable glitch!] It's not entirely clear what the client intended at
      this point...
      Closes: #195
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
  10. 21 Apr, 2020 2 commits
  11. 17 Apr, 2020 3 commits
  12. 15 Apr, 2020 1 commit
    • Chris Wilson's avatar
      sna/dri2: Interpret DRI2ATTACH_FORMAT as depth not bpp · f2a54e25
      Chris Wilson authored
      In mesa i915/i965 pass the bpp to use when creating the surface, but the
      gallium state tracker passed the depth. As it happens that
      BitsPerPixel(format) will do the right thing for both, use that.
      | DRI2ATTACH_FORMAT { attachment: CARD32
      |		      format:     CARD32 }
      |  The DRI2ATTACH_FORMAT describes an attachment and the associated
      |  format.  'attachment' describes the attachment point for the buffer,
      |  'format' describes an opaque, device-dependent format for the buffer.
      Should we need to use an explicit format (heavens forbid as nobody likes
      DRI2) then that will have to start in the range above 256 (or higher).
      For now the convention is defined by the mixture of i965/iris, and that
      is to assume it is essentially a depth.
      Reported-by: Lionel Landwerlin's avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      References: mesa/mesa!4569
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
  13. 10 Mar, 2020 1 commit
  14. 09 Dec, 2019 2 commits
  15. 27 Nov, 2019 1 commit
  16. 17 Nov, 2019 1 commit
  17. 15 Nov, 2019 1 commit
  18. 02 Nov, 2019 1 commit
  19. 07 Oct, 2019 1 commit
  20. 27 Sep, 2019 1 commit
  21. 19 Sep, 2019 15 commits