1. 05 Nov, 2020 2 commits
  2. 04 Nov, 2020 4 commits
  3. 03 Nov, 2020 3 commits
  4. 02 Nov, 2020 2 commits
  5. 31 Oct, 2020 1 commit
  6. 30 Oct, 2020 1 commit
  7. 29 Oct, 2020 2 commits
  8. 28 Oct, 2020 3 commits
  9. 26 Oct, 2020 1 commit
  10. 21 Oct, 2020 2 commits
  11. 20 Oct, 2020 1 commit
    • Adrien Faveraux's avatar
      move keyboard to the new approach and refactor the keyboard_interface · 8a6d17f2
      Adrien Faveraux authored and Bhushan Shah's avatar Bhushan Shah committed
      - Get rid of the KF5 deprecated methods related to keymap,
        kwayland-server is not source compatible with kwayland, so we don't
        need to keep the deprecated methods
      - Move the key repeat, modifiers and keymap handling fully into the
      - Get rid of some of the keyboard related code base from the
      Co-Author: Bhushan Shah <bshah@kde.org>
  12. 19 Oct, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Simplify how infinite input regions are handled · 42246b78
      Vlad Zahorodnii authored
      Some input related code in kwin is mislead by the fact that when the
      input region is infinite, SurfaceInterface::input() is going to return
      an empty QRegion object.
      We cannot really do that because the client could have just set a valid
      empty wl_region object to ignore all input events.
      This change makes SurfaceInterface assign an actually infinite region
      when a NULL input region has been passed to set_input_region().
  13. 16 Oct, 2020 1 commit
    • Bhushan Shah's avatar
      input-method-v1: Fix bug regarding the modifier handling · cd72d896
      Bhushan Shah authored
      modifiers request by the input method is supposed to send the raw
      modifiers based on the keymap of the keyboard grabbed as result of the
      grab_keyboard request. If input method client is not using the keysym
      functionality it can decide to not send out the modifiers_map, since it
      is already known to compositor as part of keymap event sent by it.
      While at it also guard against empty modifiers_map, if this happens
      ideally compositor should handle that information based on the keymap
      sent out using grab_keyboard function, but since currently, we do not
      have the grab_keyboard implemented in here, send out the NoModifier if
      that happens.
  14. 14 Oct, 2020 2 commits
  15. 13 Oct, 2020 1 commit
    • Vlad Zahorodnii's avatar
      Properly handle destruction of XdgOutputV1Interface · 3987c0ae
      Vlad Zahorodnii authored
      The xdg-output spec omits whether the compositor has to destroy all xdg-
      output resources when the associated wl_output global is removed.
      This means that no xdg-output resource should be destroyed unless the
      client has called the destructor request; otherwise the client may panic
      due to protocol errors.
      Starting with Qt 5.15.2, it's okay to destroy generated wrapper objects
      without destroying associated resources. Destructor requests will be
      handled behind the scenes for inert and orphaned resources by code that
      is generated by qtwaylandscanner.
      BUG: 426293
  16. 09 Oct, 2020 1 commit
  17. 08 Oct, 2020 1 commit
  18. 07 Oct, 2020 1 commit
    • Bhushan Shah's avatar
      text-input-v3: track commit counts per resource · 50761ce0
      Bhushan Shah authored
      If we track the commit counts at compositor global, this will fail
      horribly for anything other than the first text-input-v3 client, as for
      new client the serial count will not be what it expects in the done()
      request and it will simply consider events as outdated and will refuse
      to accept those events
  19. 02 Oct, 2020 2 commits
    • Vlad Zahorodnii's avatar
      Use global static variables to store protocol version · c7fe867e
      Vlad Zahorodnii authored
      s_version is used only to initialize a global so there is no point for
      storing protocol version in a static member field and use funky syntax
      in the cpp file to initialize it. This change also simplifies the code.
    • Vlad Zahorodnii's avatar
      Improve readability of code that destroys frame callback resources · 94730634
      Vlad Zahorodnii authored
      If a frame callback resource is destroyed, it will unregister itself
      from corresponding lists in current, pending, and cached state.
      However, this means that we need to be super duper careful when the
      compositor wants to destroy all frame callbacks. We need to make a copy
      of a frameCallbacks list; otherwise a call to removeOne() will
      invalidate iterators and the compositor may crash.
      Currently, that copy is made implicitly. Some people may see that code
      and add qAsConst() without realizing the consequences it will lead to.
      This change improves the readability of that code by making explicit
      copies of frameCallbacks in code that shuts down SurfaceInterface.
  20. 01 Oct, 2020 1 commit
    • David Edmundson's avatar
      Port DataDevice to the new inheritance approach · cd2c13bd
      David Edmundson authored
      This was done mostly because I wanted to get rid of the Resource
      dependency in AbstractDataSource so I can make our xwl bridge direct,
      but this also fixes up some issues with object lifespan present in the
      previous version and keeps all our clipboard code in-line.
  21. 29 Sep, 2020 1 commit
  22. 28 Sep, 2020 1 commit
  23. 23 Sep, 2020 3 commits
  24. 21 Sep, 2020 2 commits
    • Vlad Zahorodnii's avatar
      Keep unreferenced buffers around · fcfdab06
      Vlad Zahorodnii authored
      One problem with delaying destruction of buffer objects is that the
      compositor may create a shadow that references defunct buffers.
      One way to fix that issue is to immediately destroy buffers. However,
      there is other way to address the issue - keep released buffers alive.
      If a buffer is kept alive by the client, then it will most likely be
      used again. It also simplifies buffer management.
      BUG: 425233
    • Vlad Zahorodnii's avatar
      Untangle SurfaceInterface and BufferInterface · 9f814c49
      Vlad Zahorodnii authored
      A wl_buffer object can be bound to multiple surfaces or none at all. So
      the BufferInterface::surface() property makes very little sense.