1. 04 May, 2021 1 commit
  2. 01 May, 2021 1 commit
  3. 29 Apr, 2021 2 commits
  4. 28 Apr, 2021 1 commit
  5. 20 Apr, 2021 3 commits
  6. 19 Apr, 2021 1 commit
  7. 16 Apr, 2021 1 commit
    • Xaver Hugl's avatar
      platforms/drm: Introduce DrmPipeline · 5a22deda
      Xaver Hugl authored
      DrmPipeline is what now contains all the drm bits related to
      modesetting and presentation, instead of that being in DrmOutput.
      This gives a lot more freedom for managing drm resources and
      enables far better usage of the atomic API with guaranteed
      immutability for failed tests.
      5a22deda
  8. 01 Apr, 2021 4 commits
  9. 30 Mar, 2021 1 commit
  10. 23 Mar, 2021 2 commits
    • Xaver Hugl's avatar
      eb7703cd
    • Vlad Zahorodnii's avatar
      Refactor session code · ade861d6
      Vlad Zahorodnii authored
      At the moment, the session code is far from being extensible. If we
      decide to add support for libseatd, it will be a challenging task with
      the current design of session management code. The goal of this
      refactoring is to fix that.
      
      Another motivation behind this change is to prepare session related code
      for upstreaming to kwayland-server where it belongs.
      ade861d6
  11. 22 Mar, 2021 1 commit
    • Xaver Hugl's avatar
      Refactor DRM presentation · a8055e45
      Xaver Hugl authored
      Presentation doesn't have to go through DrmBackend and by moving
      DrmGpu::deleteBufferAfterPageflip into DrmBuffer some code can be
      simplified
      a8055e45
  12. 09 Mar, 2021 1 commit
    • Vlad Zahorodnii's avatar
      platforms/drm: Fix potential stack corruption · b3e70318
      Vlad Zahorodnii authored
      If the file descriptor of the DRM device is greater than FD_SETSIZE, the
      stack will be corrupted. However, it is highly unlikely that we ever hit
      this case because DRM devices are opened at startup of kwin, so the file
      descriptors should small.
      
      In order to prevent the potential stack corruption, this change replaces
      the usage of select() with poll().
      
      Unlike select(), the api of poll() is much more sensible. Back 20 or so
      years ago the main argument against poll() was that it's not implemented
      by all platforms. But, nowadays, it's supported on all major platforms.
      b3e70318
  13. 25 Feb, 2021 1 commit
  14. 23 Feb, 2021 1 commit
  15. 22 Feb, 2021 1 commit
  16. 19 Feb, 2021 2 commits
    • Vlad Zahorodnii's avatar
      platforms/drm: Refactor event dispatching code · e179fb69
      Vlad Zahorodnii authored
      There are a couple of reasons not to use the lambda:
      
      * It is unnecessary. The DrmGpu has the DRM file descriptor
      * If a crash occurs somewhere in the lambda, the backtrace will be hard
        to read
      * Instead of processing events in the destructor of the DrmBackend
        class, we should keep dispatching events without involving
        QCoreApplication::processEvents() until all page flips are completed.
      e179fb69
    • Xaver Hugl's avatar
      Properly clean up DrmGpu · 79ccfadd
      Xaver Hugl authored
      CCBUG: 433145
      79ccfadd
  17. 18 Feb, 2021 1 commit
  18. 15 Feb, 2021 1 commit
  19. 10 Feb, 2021 1 commit
    • Vlad Zahorodnii's avatar
      Move source code to src/ directory · 93e0265e
      Vlad Zahorodnii authored
      Once in a while, we receive complaints from other fellow KDE developers
      about the file organization of kwin. This change addresses some of those
      complaints by moving all of source code in a separate directory, src/,
      thus making the project structure more traditional. Things such as tests
      are kept in their own toplevel directories.
      
      This change may wreak havoc on merge requests that add new files to kwin,
      but if a patch modifies an already existing file, git should be smart
      enough to figure out that the file has been relocated.
      
      We may potentially split the src/ directory further to make navigating
      the source code easier, but hopefully this is good enough already.
      93e0265e
  20. 06 Feb, 2021 1 commit
  21. 26 Jan, 2021 1 commit
  22. 06 Jan, 2021 1 commit
    • Vlad Zahorodnii's avatar
      Introduce RenderLoop · b8a70e62
      Vlad Zahorodnii authored
      At the moment, our frame scheduling infrastructure is still heavily
      based on Xinerama-style rendering. Specifically, we assume that painting
      is driven by a single timer, etc.
      
      This change introduces a new type - RenderLoop. Its main purpose is to
      drive compositing on a specific output, or in case of X11, on the
      overlay window.
      
      With RenderLoop, compositing is synchronized to vblank events. It
      exposes the last and the next estimated presentation timestamp. The
      expected presentation timestamp can be used by effects to ensure that
      animations are synchronized with the upcoming vblank event.
      
      On Wayland, every outputs has its own render loop. On X11, per screen
      rendering is not possible, therefore the platform exposes the render
      loop for the overlay window. Ideally, the Scene has to expose the
      RenderLoop, but as the first step towards better compositing scheduling
      it's good as is for the time being.
      
      The RenderLoop tries to minimize the latency by delaying compositing as
      close as possible to the next vblank event. One tricky thing about it is
      that if compositing is too close to the next vblank event, animations
      may become a little bit choppy. However, increasing the latency reduces
      the choppiness.
      
      Given that, there is no any "silver bullet" solution for the choppiness
      issue, a new option has been added in the Compositing KCM to specify the
      amount of latency. By default, it's "Medium," but if a user is not
      satisfied with the upstream default, they can tweak it.
      b8a70e62
  23. 15 Dec, 2020 1 commit
  24. 02 Dec, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Fix crash in eglTerminate() · b94c8765
      Vlad Zahorodnii authored
      At the moment, the gbm_device for the primary device is destroyed before
      the EGLDisplay is destroyed. This results in a crash in Mesa.
      
      In order to fix the crash, this change ensures that the EGLDisplay is
      destroyed before the gbm device.
      b94c8765
  25. 28 Nov, 2020 2 commits
  26. 17 Nov, 2020 1 commit
  27. 29 Oct, 2020 2 commits
  28. 25 Oct, 2020 2 commits
  29. 13 Oct, 2020 1 commit