1. 31 Mar, 2021 1 commit
    • Simon Ser's avatar
      linux-dmabuf: clarify what mixed valid/INVALID modifiers mean · 3683a5eb
      Simon Ser authored
      This commit makes it clear that compositors can send valid modifiers and
      DRM_FORMAT_MOD_INVALID for a given format. This means that the compositor
      supports both implicit and explicit modifiers. See the warning further
      down:
      
      > Warning: It should be an error if the format/modifier pair was not
      > advertised with the modifier event. This is not enforced yet because
      > some implementations always accept DRM_FORMAT_MOD_INVALID. Also
      > version 2 of this protocol does not have the modifier event.
      
      Xwayland already requires compositors to send DRM_FORMAT_MOD_INVALID
      for importing buffers with an implicit modifier [1].
      
      In a future protocol version, it would be nice to make it a protocol
      error (or at least a soft failure) to use any format/modifier pair that
      wasn't advertised. A use-case for this is Vulkan compositors: the Vulkan
      DMA-BUF extensions require an explicit modifier and cannot import
      buffers which have an implicit modifier.
      
      [1]: https://gitla...
      3683a5eb
  2. 16 Feb, 2021 1 commit
    • Pekka Paalanen's avatar
      linux-dmabuf: no buffer errors on device disappearance · f899eff0
      Pekka Paalanen authored
      This was prompted by the discussion from
      https://lists.freedesktop.org/archives/dri-devel/2020-May/266611.html
      
      
      which is not the final wording.
      
      When a DRM device is hot-unplugged, particularly if it is the Wayland
      compositor's compositing GPU, EGL may start returning errors from trying to use
      the client's dmabuf. Or, if the client is rendering on another GPU which gets
      hot-unplugged, the dmabuf the compositor already has may start failing.
      
      Hot-unplug is an abrupt global action, and there is no way a client or a
      compositor could ensure they clean up before things start failing. It is not
      the client's fault, so the client should not get disconnected if already
      existing wl_buffer objects start failing. This patch add the wording to the
      protocol to this effect.
      
      The intention is that the compositor replaces the failed buffers with some
      placeholder content. There is no way this could be glitch-free. In its own pace
      the client should discover the DRM device is gone, clean up, and perhaps use
      something else. How exactly that should happen depends on the rendering API the
      client is using.
      
      This is a tiny step towards making DRM device hot-unplug not crash
      applications that wish to handle the unplug gracefully.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.com>
      f899eff0
  3. 05 Jan, 2021 1 commit
  4. 02 May, 2019 1 commit
  5. 20 May, 2017 1 commit
  6. 19 May, 2017 2 commits
  7. 27 Jan, 2017 1 commit
  8. 21 Nov, 2016 2 commits
  9. 13 Apr, 2016 1 commit
  10. 09 Nov, 2015 2 commits
  11. 21 Oct, 2015 1 commit