Skip to content
Snippets Groups Projects
  1. Aug 19, 2024
  2. Jul 25, 2024
  3. Jul 24, 2024
  4. Jul 11, 2024
  5. Jul 09, 2024
  6. Jul 04, 2024
  7. Jul 03, 2024
  8. Jun 21, 2024
    • Michael Olbrich's avatar
      drm-backend: limit reset/restart to output of a failed commit · f843ba34
      Michael Olbrich authored
      
      When a commit fails, then only the outputs that where part of this commit should
      be reset or restarted.
      
      Otherwise an unrelated output that has another successful pending commit may be
      restarted incorrectly. Then the output is in an inconsistent state and will
      trigger an assertion:
      
      weston: ../libweston/backend-drm/state-propose.c:627: drm_output_propose_state: Assertion `!output->state_last' failed.
      
      Signed-off-by: default avatarMichael Olbrich <m.olbrich@pengutronix.de>
      f843ba34
    • Michael Olbrich's avatar
      backend-drm: handle commit failures correctly · ef175c8e
      Michael Olbrich authored
      
      Currently only the return value of the last backend that implements
      repaint_flush() is actually used. That only works because the drm backend is the
      only backend that implements repaint_flush().
      In the drm backend only the return value of the last device is used. And if a
      failure is actually detected, then all repainted outputs of all backends are
      reset. This can trigger asserts:
      weston_output_schedule_repaint_reset() (or _restart()) will change the state of
      the output but the backend that did not cause the failure will still call
      weston_output_finish_frame().
      The same thing can happen with multiple devices in the drm backend. Or outputs
      get stuck if an error is dropped.
      
      Since the drm backend is the only one that implements repaint_flush() anyways,
      move the failure handling into the backend and make it device specific.
      This way only the outputs that need it are reset.
      
      Signed-off-by: default avatarMichael Olbrich <m.olbrich@pengutronix.de>
      ef175c8e
    • Michael Olbrich's avatar
      backend-drm: skip building atomic state and logging for "empty" repaints · e8166e85
      Michael Olbrich authored
      
      With multiple backends or devices repaint_begin/repaint_flush may be called even
      if no outout of a device will be repainted. This results in an "empty" drm state
      without any output.
      The actual commit to the kernel is already skipped but the drm-backend log is
      still filled with "Beginning repaint"/"repaint-flush" messages and the scene
      graph.
      
      Use the new prepare_repaint() callback to determine if a backend needs to be
      repainted and only create the pending_state if necessary.
      Exit early in repaint_flush()/repaint_cancel() when no pending_state was created.
      
      Signed-off-by: default avatarMichael Olbrich <m.olbrich@pengutronix.de>
      e8166e85
  9. Jun 07, 2024
  10. May 10, 2024
  11. May 06, 2024
  12. Feb 21, 2024
  13. Jan 29, 2024
    • Pekka Paalanen's avatar
      backend-drm: rename eotf_list to str · f8807320
      Pekka Paalanen authored
      
      I want re-use this variable for printing the colorimetry mode list as
      well in a future patch, so a generic name is less confusing.
      
      Signed-off-by: default avatarPekka Paalanen <pekka.paalanen@collabora.com>
      f8807320
    • Pekka Paalanen's avatar
      backend-drm: store EDID data · 2c0a9c06
      Pekka Paalanen authored
      
      Store the EDID data as-is, so that we can tell when the EDID blob has
      changed. This is not too useful yet, because all the weston_head_set_*()
      API raises the device_changed flag only if the information actually
      changes. However, I want to expose the libdisplay-info di_info structure
      through weston_head, and those cannot be (as) easily compared.
      
      We need to know when the EDID blob changes, so we can call
      weston_head_set_device_changed() appropriately when updating di_info.
      
      Signed-off-by: default avatarPekka Paalanen <pekka.paalanen@collabora.com>
      2c0a9c06
  14. Jan 22, 2024
  15. Jan 12, 2024
  16. Jan 10, 2024
  17. Nov 10, 2023
    • Derek Foreman's avatar
      drm-backend: Fix cursor updates with overlapping heads · 78657c5f
      Derek Foreman authored
      
      We can't use the surface damage to determine when to upload new cursor
      images because when heads overlap the first repainted head will accumulate
      that damage as plane damage.
      
      We can't easily use plane damage either because the plane isn't really
      assigned until after an atomic test, which requires the cursor fb to be
      current.
      
      Untangle this mess a little by always testing with the first cursor fb,
      which is identical to the second in all ways, then replace with the correct
      fb in repaint.
      
      Signed-off-by: default avatarDerek Foreman <derek.foreman@collabora.com>
      78657c5f
  18. Sep 29, 2023
  19. Sep 28, 2023
  20. Jul 11, 2023
  21. Jul 04, 2023
    • Marius Vlad's avatar
      backend-drm: Use resize_output to allow changing the fb · 3044d8ed
      Marius Vlad authored and Daniel Stone's avatar Daniel Stone committed
      
      A video mode change would be needed to change the underlying renderer
      framebuffer. All other backends make uses of this so let's do it for the
      DRM-backend as well.
      
      This would also be needed for the output capture to function properly as
      we need call weston_output_update_capture_info() when a new mode set has
      set. Otherwise we'd run into mismatched dimensions for the current mode
      versus the dimensions set-up initially in weston_output_capture_source_info.
      
      Signed-off-by: default avatarmarius vlad <marius.vlad@collabora.com>
      3044d8ed
  22. Jun 27, 2023
  23. Jun 19, 2023
  24. Jun 12, 2023
  25. Jun 05, 2023
    • Leandro Ribeiro's avatar
      drm: do not pull writeback task if KMS atomic API is not supported · 32264175
      Leandro Ribeiro authored and Pekka Paalanen's avatar Pekka Paalanen committed
      
      Since 2d70bdfd "drm-backend: add support
      to output capture writeback source", the DRM-backend was broken for KMS
      devices that do not support the atomic API. This fixes that.
      
      We don't support writeback screenshots without atomic modeset support.
      So for such devices, we never update the output capture info
      (weston_output_update_capture_info()) for the writeback source.
      
      The function that we use to pull writeback tasks
      (weston_output_pull_capture_task()) asserts that the capture providers
      (renderers, DRM-backend) did not forget to update the capture info
      (size/format) if something changed. But as we've never updated the
      capture info for such devices, it is zeroed, leading to an assert hit.
      
      With this patch we only pull the capture task for KMS devices that
      support the atomic API.
      
      Signed-off-by: default avatarLeandro Ribeiro <leandro.ribeiro@collabora.com>
      32264175
    • Leandro Ribeiro's avatar
      drm: drop disable_planes being false as a condition to support writeback · 6d8e3c56
      Leandro Ribeiro authored and Pekka Paalanen's avatar Pekka Paalanen committed
      
      In 2d70bdfd "drm-backend: add support to
      output capture writeback source" we've ensured that disable_planes
      should be false in order to support writeback capture tasks.
      
      But this was wrong; disable_planes is transient (it is true when
      there's some sort of content recording happening), and we enable/disable
      that during compositor's lifetime.
      
      This is dangerous and may result in a crash. Imagine the following
      sequence:
      
              1. screen recording starts, disable_planes is set to true.
      
              2. for whatever reason the output size changes, and we end up
              not updating capture info because we think that writeback is not
              supported by the device.
      
              3. screen recording stops, disable_planes is set to false.
      
              4. user tries to take a writeback screenshot, and the
              DRM-backend will pull a writeback capture task with
              weston_output_pull_capture_task().
      
              5. this function has an assert to ensure that the DRM-backend
              did not forget to update the capture info, and we hit that
              assert.
      
      With this patch we drop disable_planes being false as a condition to
      support writeback. So now we keep the capture info up-to-date even when
      screen recording is happening, and we gracefully fail writeback tasks.
      
      Signed-off-by: default avatarLeandro Ribeiro <leandro.ribeiro@collabora.com>
      6d8e3c56
  26. Apr 19, 2023
Loading