1. 18 Aug, 2020 1 commit
  2. 05 Jul, 2020 1 commit
  3. 20 Dec, 2019 1 commit
  4. 07 Nov, 2019 1 commit
    • Dor Askayo's avatar
      xwayland: clear pixmaps after creation in rootless mode · 0e9a0c20
      Dor Askayo authored
      
      
      When a pixmap is created with a backing FBO, the FBO should be cleared
      to avoid rendering uninitialized memory. This could happen when the
      pixmap is rendered without being filled in its entirety.
      
      One example is when a top-level window without a background is
      resized. The pixmap would be reallocated to prepare for more pixels,
      but uninitialized memory would be rendered in the resize offset until
      the client sends a frame that fills these additional pixels.
      
      Another example is when a new top-level window is created without a
      background. Uninitialized memory would be rendered after the pixmap is
      allocated and before the client sends its first frame.
      
      This issue is only apparent in OpenGL implementations that don't zero
      the VRAM of allocated buffers by default, such as RadeonSI.
      Signed-off-by: Dor Askayo's avatarDor Askayo <dor.askayo@gmail.com>
      Closes: #636
      
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      0e9a0c20
  5. 14 Oct, 2019 1 commit
  6. 11 Oct, 2019 1 commit
  7. 28 May, 2019 1 commit
  8. 17 Apr, 2019 4 commits
  9. 11 Mar, 2019 1 commit
  10. 11 Sep, 2018 1 commit
  11. 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
      glamor_egl_fd*_from_pixmap() function.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
      Fixes: c8c276c9 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
      186a21c4
  12. 28 May, 2018 1 commit
  13. 23 May, 2018 1 commit
  14. 16 May, 2018 1 commit
    • Lukas F. Hartmann's avatar
      glamor_init: clamp GLSL to 120 if platform doesn't have instanced arrays · 7437b6db
      Lukas F. Hartmann authored
      
      
      Hi,
      
      I upgraded Xwayland and the assorted libraries from git masters today,
      and noticed that glamor wouldn't work anymore on i.MX6/etnaviv. The
      error was:
      
      No provider of glVertexAttribDivisor found.  Requires one of:
          Desktop OpenGL 3.3
          OpenGL ES 3.0
          GL extension "GL_ANGLE_instanced_arrays"
          GL extension "GL_ARB_instanced_arrays"
          GL extension "GL_EXT_instanced_arrays"
          GL extension "GL_NV_instanced_arrays"
      
      The problem is that etnaviv offers GLSL 140 on GL 2.1 and glamor
      rendering assumes that glVertexAttribDivisor() is always available on
      GLSL>=130, which is not the case here. Forcing GLSL 120 makes glamor
      work fine again on this platform. After chatting with ajax in
      #xorg-devel, the following solution was proposed.
      
      This is my first time of submitting a patch, so please excuse me and
      advise if I'm doing it wrong ;)
      
      Cheers
      Lukas (mntmn)
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      7437b6db
  15. 08 May, 2018 1 commit
  16. 06 Mar, 2018 1 commit
  17. 05 Mar, 2018 2 commits
  18. 27 Feb, 2018 1 commit
  19. 15 Nov, 2017 1 commit
  20. 07 Nov, 2017 2 commits
  21. 30 Oct, 2017 2 commits
  22. 14 Oct, 2017 1 commit
  23. 03 Jun, 2017 2 commits
  24. 15 Mar, 2017 1 commit
    • Olivier Fourdan's avatar
      glamor: Check for NULL pixmap in glamor_get_pixmap_texture() · f40ff18c
      Olivier Fourdan authored
      glamor_create_pixmap() would return a NullPixmap if the given size is
      larger than the maximum size of a pixmap.
      
      But glamor_get_pixmap_texture() won't check if the given pixmap is
      non-null, leading to a segfault if glamor_create_pixmap() failed.
      
      This can be reproduced by passing Xephyr a very large screen width,
      e.g.:
      
       $ Xephyr -glamor -screen 32768x1024 :10
      
       (EE)
       (EE) Backtrace:
       (EE) 0: Xephyr (OsSigHandler+0x29)
       (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
       (EE) 2: Xephyr (glamor_get_pixmap_texture+0x30)
       (EE) 3: Xephyr (ephyr_glamor_create_screen_resources+0xc6)
       (EE) 4: Xephyr (ephyrCreateResources+0x98)
       (EE) 5: Xephyr (dix_main+0x275)
       (EE) 6: /lib64/libc.so.6 (__libc_start_main+0xf1)
       (EE) 7: Xephyr (_start+0x2a)
       (EE) 8: ? (?+0x2a) [0x2a]
       (EE)
       (EE) Segmentation fault at address 0x0
       (EE)
       Fatal server error:
       (EE) Caught signal 11 (Segmentation fault). Server aborting
       (EE)
       Aborted (core dumped)
      
      Bugzilla: https://bugzilla.redhat.com/1431633
      
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      f40ff18c
  25. 30 Nov, 2016 1 commit
    • Olivier Fourdan's avatar
      glamor: restore vfunc handlers on init failure · f43207c1
      Olivier Fourdan authored
      In glamor_init(), if the minimum requirements are not met, glamor may
      fail after setting up its own CloseScreen() and DestroyPixmap()
      routines, leading to a crash when either of the two routines is called
      if glamor failed to complete its initialization, e.g:
      
        (EE) Backtrace:
        (EE) 0:  Xwayland (OsSigHandler+0x29)
        (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
        (EE) 2: Xwayland (glamor_sync_close+0x2a)
        (EE) 3: Xwayland (glamor_close_screen+0x52)
        (EE) 4: Xwayland (CursorCloseScreen+0x88)
        (EE) 5: Xwayland (AnimCurCloseScreen+0xa4)
        (EE) 6: Xwayland (present_close_screen+0x42)
        (EE) 7: Xwayland (dix_main+0x4f9)
        (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf1)
        (EE) 9:  Xwayland (_start+0x2a)
      
      Restore the previous CloseScreen() and DestroyPixmap() vfunc handlers in
      case of failure when checking for the minimum requirements, so that if
      any of the requirement is not met we don't leave the CloseScreen() and
      DestroyPixmap() from glamor handlers in place.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1390018
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      f43207c1
  26. 29 Sep, 2016 1 commit
  27. 28 Sep, 2016 1 commit
  28. 25 Sep, 2016 1 commit
  29. 13 Sep, 2016 1 commit
  30. 18 Jul, 2016 2 commits
    • Keith Packard's avatar
      Remove readmask from screen block/wakeup handler · fb080211
      Keith Packard authored
      
      
      With no users of the interface needing the readmask anymore, we can
      remove it from the argument passed to these functions.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      fb080211
    • Emma Anholt's avatar
      glamor: Remove the FBO cache. · 950ffb8d
      Emma Anholt authored
      
      
      It is a modest performance improvement (2.7% on Intel), with the
      significant downside that it keeps extra pixmap contents laying around
      for 1000 BlockHandlers without the ability for the system to purge
      them when under memory pressure, and tiled renderers don't know that
      we could avoid reading their current contents when beginning to render
      again.  We could use the FB invalidate functions, but they aren't
      always available, aren't hooked up well in Mesa, and would eat into
      the performance gains of having the cache.
      
      [ajax: rebased to master]
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      950ffb8d
  31. 20 Jun, 2016 1 commit
    • Keith Packard's avatar
      dix: Call screen block/wakeup handlers closest to blocking [v3] · fb1edccf
      Keith Packard authored
      
      
      The screen block and wakeup handlers are the only ones which provide a
      well known ordering between the wrapping layers; placing these as
      close as possible to the server blocking provides a way for the driver
      to control the flow of execution correctly.
      
      Switch the shadow code to run in the screen block handler so that it
      now occurrs just before the server goes to sleep.
      
      Switch glamor to call down to the driver after it has executed its own
      block handler piece, in case the driver needs to perform additional
      flushing work after glamor has called glFlush.
      
      These changes ensure that the following modules update the screen in
      the correct order:
      
      animated cursors        (uses RegisterBlockAndWakeupHandlers dynamically)
      composite               (dynamic wrapping)
      misprite                (dynamic wrapping)
      shadow                  (static wrapping)
      glamor                  (static wrapping)
      driver                  (static wrapping)
      
      It looks like there's still a bit of confusion between composite and
      misprite; if composite updates after misprite, then it's possible
      you'd exit the block handler chain with the cursor left hidden. To fix
      that, misprite should be wrapping during ScreenInit time and not
      unwrapping. And composite might as well join in that fun, just to make
      things consistent.
      
      [v2] Unwrap BlockHandler in shadowCloseScreen (ajax)
      [v3] ephyr: Use screen block handler for flushing changes
      
      ephyr needs to make sure it calls glXSwapBuffers after glamor finishes
      its rendering. As the screen block handler is now called last, we have
      to use that instead of a registered block/wakeup handler to make sure
      the GL rendering is done before we copy it to the front buffer.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      fb1edccf
  32. 26 May, 2016 1 commit
    • Keith Packard's avatar
      glamor: Preserve GL_RED bits in R channel when destination is GL_RED [v2] · 181a4bd0
      Keith Packard authored
      A1 and A8 pixmaps are usually stored in the Red channel to conform
      with more recent GL versions. When using these pixmaps as mask values,
      that works great. When using these pixmaps as source values, then the
      value we want depends on what the destination looks like.
      
      For RGBA or RGB destinations, then we want to use the Red channel
      for A values and leave RGB all set to zero.
      
      For A destinations, then we want to leave the R values in the Red
      channel so that they end up in the Red channel of the output.
      
      This patch adds a helper function, glamor_bind_texture, which performs
      the glBindTexture call along with setting the swizzle parameter
      correctly for the Red channel. The swizzle parameter for the Alpha
      channel doesn't depend on the destination as it's safe to leave it
      always swizzled from the Red channel.
      
      This fixes incorrect rendering in firefox for this page:
      
      	https://gfycat.com/HoarseCheapAmericankestrel
      
      while not breaking rendering for this page:
      
      	https://feedly.com
      
      v2: Add change accidentally left in patch for missing
          glDisable(GL_COLOR_LOGIC_OP).
          Found by Emil Velikov <emil.l.velikov@gmail.com>
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63397
      
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Tested-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      181a4bd0